Не работает кеш на стороне пользователя

Посмотрите в пейджспид, что именно не кешируется. Пейджспид достаточно тупорылый инструмент. Настоятельно не рекомендую использовать его как библию. Он подходит чисто, чтобы грубо оценить, что реально нужно оптимизировать. Если у Вас картинки можно ужать на 5 мб. то это надо сделать, а если надо сжать какой-то css, что сэкономит 900 байт то нужно забить.

Вот что pagespeed выдает:

Скорее всего требуется внести изменения в nginx.conf

Если у Вас VPS, посмотрите наличие записи в файле nginx.conf (для location) - expires 360d; (как пример).

Можно прописать вместо 360d - max или установить свое количество дней и т.д.

Так же можно использовать Cache-Control

Нет там вообще такого!

---------- Добавлено 27.08.2016 в 01:49 ----------

А можно подробнее?

Как на этом сайте: http://www.sysmasters.net/kb/ispolzovanie-kesha-na-storone-brauzera-nginx/ ?

Забыл упомянуть, у меня связка ngnix+Apache

А ниже что? Может он пишет про скрипт метрики или Адсенса.

Зачем вам левые сервисы(пусть даже и гуглёвские), которые показывают хрен знает что?

Смотрите в консоли браузера, присылает ваш сервер заголовки Expires или нет. Если присылает, и они правильные - браузер будет кэшировать на стороне пользователя.

Может статиту стоит отдавать nginx-ом напрямую (и оно у Вас скорее так и есть)?

Пропишите что-то вроде:

location ~ \.(css|js|png|gif|ico|jpeg|jpg|bmp|htm|html|doc|swf|xls|zip|wml|wmlc|wmls|wmlsc|wbmp|avi|fla|flv|mpg|mpeg|mp3|pdf|woff|eot|otf|svg|ttf)$ {
expires    30d;
}

Прописываете примерно следующее:

Cache-Control "max-age=31536000, public"; 

Заголовки ответов Cache-Control включают:

• max-age=[секунды] - описывает максимальный период времени, в течение которого контент остается свежим. Аналогично Expires, эта директива указывает время, относительное моменту запроса, а не абсолютную величину. [секунды] - количество секунд от момента запроса, в течение которых вы хотите, чтобы контент трактовался как свежий.
• s-maxage=[секунды] - подобен max-age, отличаясь тем, что применяется только к общему кэша (т.е. прокси).
• public - помечает авторизованные запросы, как кэшируемые; это нормально, если требуется HTTP-аутентификация, ответы автоматически становятся приватными.
• private - позволяет кэшу, который действует для определенного пользователя (т.е. в браузере) хранить ответ; общему кэшу (т.е. прокси) - нет.
• no-cache - принуждает кэш отправлять запрос на исходный сервер каждый раз для валидации, прежде чем выдать кэшированную копию. Это полезно, когда необходимо гарантировать, что аутентификация принята во внимание (в сочетании с public) или для поддержания жесткой свежести без потери преимуществ кэширования.
• no-store - указывает кэшу не сохранять копию контента, ни при каких условиях.
• must-revalidate - сообщает кэшу, что он должен подчиниться любой свежей информации, что вы ему предоставляете о контенте. HTTP позволяет кэшу хранить устаревший контент при определенных условиях; упомянув этот заголовок, вы сообщаете кэшу, что вы хотите, чтобы он строго следовал вашим правилам.
• proxy-revalidate - подобен must-revalidate, кроме того, что применяется только к прокси.

Если на Вашем VPS установлена панель VestaCP

то путь к файлу будет таким:

vi /home/имя_пользователя/conf/web/nginx.conf

Надеюсь, что подробно описал. Если будут вопросы, обращайтесь! 🍿

Или приходите к нам, все настроим: vps сервер

Samail, Вот что пишет:

Ladycharm, Подскажи пожалуйста как можно посмотреть?

livetv, expires - такого слова даже нет в конфиге, искал нотепадом ++

eiweb, Тяжко будет это все делать. Пока времени нет, позже попробую, что-нибудь сделать. Правда еще все зависит от ответа Ladycharm, может действительно кеш уже идет...

Парни спасибо вам большое за ваши ответы!

P.S. у меня дедик)

Это внешние ресурсы. Пусть их вк кеширует