Как использовать кеш браузера пользователей для ускорения сайта (заголовки Last-Modified, ETag, Expires, Cache-Control)

Здравствуйте, уважаемые читатели блога Goldbusinessnet.com. Продолжаю цикл статей, которые касаются мероприятий по оптимизации, и сегодня настал черед для настройки использования в этих целях кэша браузера со стороны пользователей, что является очередным шагом выполнения рекомендаций Google Page Speed по ускорению сайта.

Каждое действие, позволяющее приблизиться к этой цели, будет плюсом в продвижении веб-ресурса, а потому не поленитесь хотя бы взглянуть на материалы, где я давал описания оптимизации картинок, объединения изображений в спрайты, а также сокращения CSS и скриптов, что, несомненно, вам поможет в реализации общей задачи.

В продолжение я постараюсь предоставить внятные инструкции по настройке кэширования в браузере путем внедрения специального кода в замечательный файл .htaccess. Правда, это не всем и не всегда может помочь, но обо всем чуть ниже.

Рекомендация PageSpeed — используйте кэш браузера

Думаю, каждый из вас представляет себе, что такое кэширование, хотя бы в общих чертах. На всякий случай объясню вкратце. Допустим, читатель открывает в окне браузера страницу вашего ресурса, все составляющие которой (содержание, стили, скрипты и т.п.) загружаются с сервера хостинга, что занимает определенное время.

Предположим, у нас есть возможность запустить механизм, который позволит сохранить копии элементов страниц прямо в web-обозревателе того пользователя, который их посещает. Тогда при каждом следующем обращении все эти элементы будут браться прямо из кеша браузера (что это такое и как его очистить?) посетителя, то есть из специальной папки, которая располагается на жестком диске его компьютера.

Выигрыш в скорости загрузки будет налицо. Вот такой алгоритм мы и будем изучать в настоящей статье. Кстати, в дополнение темы можете почитать о том, как наряду с ускорением сайта можно добиться снижения нагрузки на сервер хостинга, что весьма актуально в наши дни.

Пару-тройку лет назад я рассказывал об оптимизации одного из своих проектов на основании анализа Пейдж Спид, осуществленного посредством расширения (сейчас доступен только онлайн сервис), которое давало более детальную картину.

Тогда после процедуры gzip сжатия файлов CSS, JS, HTML следующим по приоритету советом была как раз необходимость использования кэша браузера:

После того, как мне удалось включить кэширование в браузере пользователей, картина в окне Page Speed стала немного более привлекательной (проблема переместилась из желтой в зеленую зону), хотя и остались в списке некоторые элементы, подгружаемые со сторонних ресурсов (но повлиять на их оптимизацию нет возможности):

У моего теперешнего хостера кэширование включено, поэтому при анализе этого блога в упомянутом чуть выше online сервисе Pagespeed отразились опять же только внешние элементы, которые мне не подвластны (Граватар, контекстная реклама, Яндекс Метрика, Гугл Аналитикс):

Далее мы и разберем уже конкретные практические шаги, нужные для выполнения рекомендации «Используйте кеш браузера», чтобы исправить создавшееся положение. Надеюсь, они дадут вам возможность все же настроить кеширование в браузерах должным образом.

Настройка кеширования в браузере пользователей в целях увеличения скорости сайта

Помните, в начале поста я обмолвился, что предлагаемый вариант не являются стопроцентно универсальным и подойдет не всем? К сожалению, это так. Дело в том, что этот метод годится только для серверов, управляемых ПО Apache (коих, правда, подавляющее большинство).

Более того, описанные ниже телодвижения дадут результат только в том случае, ежели у вас работает Апач в чистом виде. Если используется связка Apache + nginx, то настраивать придется последний, и в этом случае владельцам сайтов на разделенном виртуальном хостинге без помощи не обойтись. Так что придется обратиться к хостеру (впрочем, тоже вариант).

Итак, производить настройку выдачи страниц из кеша мы будем путем указания специальных директив, которые прописываются в файле .htaccess, являющемся ничем иным как средством удаленного администрирования сервером, где расположен ваш проект.

Все действия по редактированию на сервере должны быть контролируемыми с вашей стороны, поэтому обязательно делайте копии подлежащих изменению файлов с тем, чтобы при возможной ошибке вернуть исходное состояние сайта.

Находится .htaccess обычно в корневой директории (папке public_html или htdocs) вашего сайта. Для начала проверьте его наличие, подсоединившись к удаленному серверу, где хостится ваш проект, посредством ФТП-соединения (тут у меня разобран по косточкам менеджер Файлзилла). Если вы файла .htaccess в корне не наблюдаете, то попробуйте из верхнего меню FileZilla выбрать «Сервер» — «Принудительно отображать скрытые файлы»:

Если и в этом случае он не появится (что, впрочем, маловероятно), примените замечательный редактор Нотепад плюс плюс и создайте в нем такой файл:

Далее необходимо, воспользовавшись все тем же Notepad++, вписать в .htaccess последующий ниже код, который содержит директивы для управления сайтом применительно к возможности кеширования его статических элементов в браузерах посетителей.

Начиная с этого места я решил немного углубиться в суть вопроса. Те, кто теоретически уже подкованы в достаточной мере, могут просто пропустить несколько последующих абзацев и сразу скопировать нужные коды, которые последуют ниже.

Если говорить конкретно, то посредством конфигурационного файла .htaccess мы должны дать команду браузерам пользователей при следующих посещениях ими сайта подгружать статические элементы страниц уже из папки кэша, расположенной на компьютере, а не напрямую с сервера, что и даст так нужный нам выигрыш в скорости загрузки.

В целях решения этой задачи нужно включить в ответ сервера соответствующие HTTP заголовки, в которых будет содержаться необходимая информация. Поговорим об этом подробнее.

Во-первых, необходимо обеспечить своевременное обновление веб-обозревателями кэшируемых объектов в интересах пользователей, которые будут получать в этом случае актуальный контент. Это можно сделать, используя заголовки Last-Modified и ETag (одновременно их оба нет нужды выводить, об этом недвусмысленно говорит сам Гугл).

На практике это означает, что при отправке браузером GET запроса (в данной статье вы найдете подробности о взаимодействии сервера и клиентских приложений) он получит HTTP ответ с кодом состояния 304 (без загрузки оттуда контента), если запрашиваемый ресурс не был изменен. Этот ответ означает, что можно загрузить контент из кеша.

И только в случае изменения содержание объекта будет отправлено для его отображения с сервера в составе ответа 200 (ОК). Подобная схема гарантирует максимальную экономию времени загрузки и одновременно актуальность отображаемой информации.

Во-вторых, нужно обязательно указать, на протяжении какого периода браузер должен хранить в кеше те или иные ресурсы. С этой целью можно использовать Expires либо Cache-Control с параметром max-age. Вывод этих заголовков инициируется с помощью модулей соответственно mod_expires и mod_headers, которые в том числе содержат названия объектов, к которым и будет применены правила хранения их в кеше.

Вопрос в том, какие из файлов и на какое время следует кешировать в том или ином случае. Главное, добиться взвешенного результата, заключающегося в том, чтобы максимально увеличить скорость сайта за счет кеширования при условии получения юзерами актуальной информации.

В первую очередь, это весьма распространенные статические объекты, подлежащие хранению в кеше (скрипты, файлы стилей CSS, изображения с расширениями .png, .jpg, .gif и другие).

Эти вводные, а также тот факт, что мы в качестве инструмента используем .htaccess, работающий на огромном множестве серверов Апач, позволит составить директиву, содержащую необходимый минимум правил, подходящий многим ресурсам, работающим на разных CMS.

Что важно, в большинстве своем предложенный ниже код вполне достаточен для того, чтобы создать условия, при которых Pagespeed больше не будет предъявлять претензий, а, значит, он обеспечит ускорение загрузки страниц в необходимом объеме.

Итак, на основании выше сказанного нам нужно обеспечить вывод одного из заголовков Last-Modified и ETag, а также одного из пары Expires либо Cache-Control: max-age. Для наглядности и расширения диапазона рассмотрим различные варианты.

Вариации кодов для управления кешем с использованием заголовков Last-Modified, Expires и Cache-Control

Если на вашем хостинге уже настроен вывод того же Last-Modified, то пол-дела сделано (к слову, проверить наличие этого важного заголовка можно с помощью онлайн сервисов, включая в их список инструмент для проверки ответа сервера от Яндекса). Если же нет, то сделать это весьма несложно, прописав в том же незаменимом .htaccess пару строк:

RewriteRule .* - [E=HTTP_IF_MODIFIED_SINCE:%{HTTP:If-Modified-Since}]
RewriteRule .* - [E=HTTP_IF_NONE_MATCH:%{HTTP:If-None-Match}]

Правда, работать этот метод будет опять же при условии наличия "чистого Апача" (но ведь как раз этот случай мы и рассматриваем). Будем считать, что заголовок Last-Modified, в качестве значения которого, кстати, будет выводится дата последнего изменения, настроен.

Теперь настала очередь Cache-Control с параметром max-age, в качестве значения которого будет прописан срок хранения в кеше каждого конкретного статического объекта. На сцену выходит модуль mod headers, код которого и следует вставить в .htaccess:

<ifModule mod_headers.c>
    #кэшировать HTML и HTM файлы на один день
    <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "max-age=43200"
    </FilesMatch>
    #кэшировать CSS, JavaScript и текстовые файлы на одну неделю
    <FilesMatch "\.(js|css|txt)$">
        Header set Cache-Control "max-age=604800"
    </FilesMatch>
    #кэшировать флэш и изображения на месяц
    <FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
        Header set Cache-Control "max-age=2592000"
    </FilesMatch>
    #отключить кэширование
    <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
        Header unset Cache-Control
    </FilesMatch>
</IfModule>

Нужно отметить, что посредством контейнера ifModul на сервере осуществляется проверка наличия этого модуля. При его отсутствии директива выполняться не будет, поэтому ее использование в любом случае не должно привести к ошибкам.

Время сохранения кеша определяется с помощью параметра max-age, его значение выставляется в секундах. Благодаря комментариям (которые, к слову, вы можете спокойно удалить), стоящим после символа решетки «#», основа этой конструкции, думаю, понятна.

Однако, вместо mod headers вполне можно воспользоваться модулем mod expires, выводящим заголовок Expires (который, по мнению самого Гугла является предпочтительнее, поскольку имеет более широкую поддержку). При этом фрагмент кода для его включения будет таким:

<ifModule mod_expires.c>
    ExpiresActive On
    #по умолчанию кеш на 5 секунд
    ExpiresDefault "access plus 5 seconds"
    #кэшируем флэш и изображения на месяц
    ExpiresByType image/x-icon "access plus 1 month"
    ExpiresByType image/jpeg "access plus 4 weeks"
    ExpiresByType image/png "access plus 30 days"
    ExpiresByType image/gif "access plus 43829 minutes"
    ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
    #кэшируем CSS, JavaScript и текстовые файлы на одну неделю
    ExpiresByType text/css "access plus 604800 seconds"
    ExpiresByType text/javascript "access plus 604800 seconds"
    ExpiresByType application/javascript "access plus 604800 seconds"
    ExpiresByType application/x-javascript "access plus 604800 seconds"
    #кэшируем HTML и HTM файлы на один день
    ExpiresByType text/html "access plus 43200 seconds"
    #кэшируем XML файлы на десять минут
    ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>

Точкой отсчета срока годности кэша в случае использования заголовка Expires является дата первой загрузки. Причем, в отличие от Cache-Control, где временной период определяется только в секундах, здесь он может указываться в любом временном формате, включая year (год).

Для того, чтобы убедиться в этом, посмотрите на участок кода, касающийся изображений. Там я специально указал время в различных единицах исчисления: 1 month (месяц), 4 weeks (недели), 30 days (дни), 43829 minutes (минуты), 2592000 seconds (секунды).

Понятно, что в месяце и в году может быть различное количество дней, недель, минут и секунд, но это не принципиально, поскольку используются средние значения. Кстати, для JS, файлов CSS и изображений рекомендуется ставить временной период не менее недели, но не более года. При этом по факту в качестве значения заголовка Expires в ответе сервера будет указана дата предполагаемого срока завершения периода кеширования данной версии объекта.

В дополнение к упомянутым модулям полезно задействовать еще и mod setenvif. Дело в том, что веб-обозреватели семейства Microsoft Internet Explorer и некоторые версии Мазилы корректно не воспринимают в ответе сервера HTTP заголовок Vary, который также вносит свою важную лепту в управление кэшированием. Этот модуль как раз позволяет решить эту проблему, исключая Vary из состава ответа сервера:

<IfModule mod_setenvif.c>
  BrowserMatch "MSIE" force-no-vary
  BrowserMatch "Mozilla/4.[0-9]{2}" force-no-vary
</IfModule>

В итоге мы получаем два конечных варианта настройки кеширования, которые вы можете проверить, вставив поочередно в .htaccess (оба одновременно использовать не рекомендую):

1.

<ifModule mod_headers.c>
    #кэшировать HTML и HTM файлы на один день
    <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "max-age=43200"
    </FilesMatch>
    #кэшировать CSS, JavaScript и текстовые файлы на одну неделю
    <FilesMatch "\.(js|css|txt)$">
        Header set Cache-Control "max-age=604800"
    </FilesMatch>
    #кэшировать флэш и изображения на месяц
    <FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">
        Header set Cache-Control "max-age=2592000"
    </FilesMatch>
    #отключить кэширование
    <FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
        Header unset Cache-Control
    </FilesMatch>
</IfModule>

<IfModule mod_setenvif.c>
  BrowserMatch "MSIE" force-no-vary
  BrowserMatch "Mozilla/4.[0-9]{2}" force-no-vary
</IfModule>

2.

<ifModule mod_expires.c>
    ExpiresActive On
    #по умолчанию кеш на 5 секунд
    ExpiresDefault "access plus 5 seconds"
    #кэшируем флэш и изображения на месяц
    ExpiresByType image/x-icon "access plus 1 month"
    ExpiresByType image/jpeg "access plus 4 weeks"
    ExpiresByType image/png "access plus 30 days"
    ExpiresByType image/gif "access plus 43829 minutes"
    ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
    #кэшируем CSS, JavaScript и текстовые файлы на одну неделю
    ExpiresByType text/css "access plus 604800 seconds"
    ExpiresByType text/javascript "access plus 604800 seconds"
    ExpiresByType application/javascript "access plus 604800 seconds"
    ExpiresByType application/x-javascript "access plus 604800 seconds"
    #кэшируем HTML и HTM файлы на один день
    ExpiresByType text/html "access plus 43200 seconds"
    #кэшируем XML файлы на десять минут
    ExpiresByType application/xhtml+xml "access plus 600 seconds"
</ifModule>

<IfModule mod_setenvif.c>
  BrowserMatch "MSIE" force-no-vary
  BrowserMatch "Mozilla/4.[0-9]{2}" force-no-vary
</IfModule>

Еще раз напоминаю, что несмотря на наличие контейнера IfModule, который обеспечивает безопасность редактирования, не лишним будет каждый раз при изменении .htaccess делать резервную копию исходного варианта файла (можно просто скопировать его содержание и сохранить на компьютере), чтобы вас не застиг врасплох форс-мажор в той или иной вариации.

Код формирования заголовков Etag и Expires для настройки кэша

На случай, ежели предложенные выше директивы вдруг не сработают (даже если на вашем хостинге установлен "чистый" Апач), разберем другой случай, а именно, когда в качестве инструментов управления кэшированием выступает пара входящих в разряд обязательных заголовков Etag и Expires. Как вы помните, оба отвечает за своевременность выдачи файлов из кеша, инициируя проверку на актуальность текущей версии.

Но если в качестве значения Expires отображается дата последнего изменения, то в ETag используется тот или иной уникальный идентификатор ресурса (чаще в этой роли выступает версия файла). Для активации ETag требуется лишь ввести в тот же .htaccess одну строчку:

FileETag MTime Size

Ну а затем применить уже известный нам модуль mod expires. Можно добавить и mod setenvif, который, как я уже сказал выше, запрещает формирование заголовков Vary для определенной группы веб-браузеров, чтобы гарантировать образование кеша с их стороны:

FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch ".(jpg|jpeg|gif|png|ico|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>

<IfModule mod_setenvif.c>
BrowserMatch "MSIE" force-no-vary
BrowserMatch "Mozilla/4.[0-9]{2}" force-no-vary
</IfModule>

Здесь использован комплекс с минимумом типов задействованных объектов, но зато наиболее востребованных (CSS, JavaScript и изображения), который также должен быть достаточным, чтобы обеспечить максимальную эффективность в ускорении сайта. При желании к комплекту «jpg|jpeg|gif|png|ico|css|js» можно добавить другие виды файлов.

Кроме того, в приведенном выше примере кода для всех файлов действует один и тот же период "жизни" кеша, равный одному году ("access plus 1 year"), который является рекомендуемым со стороны Гугла. Но можно для каждой группы объектов указать свой временной отрезок по примеру содержания модулей mod_expires и mod_headers из предыдущего раздела статьи.

Проверка наличия нужных заголовков в ответе сервера

После того, как вы вставите код в файл .htaccess, можно проверить, находятся ли необходимые заголовки в составе ответа сервера. Для этой цели можно воспользоваться каким-нибудь онлайн сервисом, например, Checkmy.ru, где в качестве клиента (User Agent), посылающего HTTP-запрос на сервер, выбираем любой браузер, а также вводим URL ресурса (для примера я взял путь до изображения, используемого в одной из статей блога):

После нажатия кнопки «Отправить запрос», через несколько секунд появится результат:

Как видите, в моем случае присутствуют все четыре заголовка. Я говорил, что обязательно должны выводится по одному из пар «Last-Modified — ETag» и «Expires — Cache-Control», остальные излишни. При этом полный комплект, насколько можно судить, не причинит вреда.

Кстати, ежели вы осуществите тестирование перед началом настройки кеширования, то сразу сможете определить, насколько продуктивными будут ваши действия.

Ведь если в ответе сервера будет присутствовать nginx, то настраивать нужно будет именно его (у меня это сделал провайдер), а файл конфигурации .htaccess будет здесь бесполезен. В таком случае, как я уже отмечал, придется задействовать помощь службы поддержки, если, конечно, ваш тариф хостинга и недостаточные знания не позволят самостоятельно решить вопрос.

Еще статьи по данной теме:
Самые интересные публикации из рубрики: SEO и SEM продвижение сайта

60 отзывов

  1. Денис

    Очень полезный способ для увеличения удобства нахождения на сайте. Ведь оптимизируя скорость загрузки Вы тем самым экономите время посетителя, и за это они будут благодарны заходя снова и снова на Ваш сайт. Что напрямую повлияет на доходы сайта положительным образом.

  2. Игорь

    Абсолютно верно, Денис. В продвижении сайта все взаимосвязано.

  3. Marazzi

    Ниче не поняла, браузер вобщето сам помоему запоминает сайты на которых была в кукис, Если куки подтиреть. СОГЛАСНО ВАШЕМУ МЕТОДУ то и ваша схема перестанет работать, вернее ятак понялда что это о чем идет разговор расчитано на постоянного посетителя который не подчищает историю7 ПОДПИСАЛАСЬ, ЖДУ ОТВЕТА1

  4. Сергей Дмитриевич

    Весьма полезная информация. Мне пригодилась. Спасибо.

  5. Игорь

    Marazzi, во первых куки и кэш разные вещи. Куки - особые файлы с набором данных, которые позволяют идентифицировать пользователя, если он посещает вебресурс. А cache (в переводе с англ.-склад, тайник) браузера - это своеобразное укромное место для хранения копий документов (например, вебстраниц сайта), которые при необходимости отображаются в браузере. Именно со стороне сервера происходит команда использовать кэш на стороне браузера пользователя, причем создается папка с кэшем именно на компьютере пользователя. Со своей стороны пользователь может регулировать частоту создания кэшированных копий страниц сайта, очищая папку с кэшем. Или вообще запретить кэширование, настройки современных браузеров это позволяют. Чем чаще вы чистите кэш, тем более новую версию страницы получаете.

  6. Николай

    Супер,и здесь всё ОК!!!

  7. marazzi

    Ну об этом я и говорила.

  8. Александр

    Спасибо за рекомендации! Мне пригодились!

  9. Николай

    Спасибо за статью. Правда не совсем понятно как потом чистить этот кэш в случае, например, если на сайте появится новая рубрика или раздел, наоборот исчезнет. Я конечно утрирую сильно, но смысл тот же. Временами кэш нужно чистить, как это реализовано в этом коде?

  10. Ирина

    ОК! Спасибо!
    Этот код помог, теперь 80 из 100

    FileETag MTime Size
    
    ExpiresActive on
    ExpiresDefault «access plus 1 year»
  11. Игорь

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

  12. Андрей

    Спасибо. А если мне нужно, чтобы кэшировались только определенные, например, логотип и флаги стран в footer, то как быть?

  13. Игорь

    Андрей, а зачем Вам отделять изображения, одни кэшировать, другие нет? Обычно картинки не меняются с калейдоскопической быстротой.

  14. Андрей

    Ну да, с картинками Вы правы. А определенную страницу не кэшировать(например, из админки). Такое возможно?

  15. Игорь

    Конечно, возможно. Если Вы пользуетесь плагином кэширования, например Hyper Cache, то в его настройках есть уйма разнообразных опций, в том числе можно исключить страницы, которые не подлежат кэшированию.

  16. Ярослав

    Очень полезная, статья, давно хотел настроить кеширование, вот только раньше везде находил первый представленный способ и он не делал ровным счетом ничего.
    Зато благодаря вкторому способу все работает на ура!! PS 91

  17. Игорь

    Хороший результат, Ярослав.

  18. stan

    не работает ни один способ

  19. Игорь

    Stan, вполне может быть, это во многом зависит от хостера.

  20. Илья

    Слов нету сколько я искал статью как включить время кеширование браузера просто надо было вставить самый верхний код. Спасибо за статью.

  21. Игорь

    Пожалуйста, Илья.

  22. Серый

    Спасибо, работает!

  23. Сергей

    так же не работает ни один способ
    хостер адекватный

    видимо им писать в саппорт придётся

  24. Игорь Горнов

    Да, Сергей, пожалуй. Сами видите, у многих получается реализовать.

  25. Александр Пузатых

    Спасибо. Информация классная. Сейчас буду исправлять у себя на сайте. А то pgespeed выдает красную метку.

  26. Юрий

    все сделал как описано, но скорость загрузки PageSpeed Insights не изменилась (74%). В чем может быть причина?

  27. Юрий

    Вот мой htaccess
    # BEGIN WordPress

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ — [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]

    # END WordPress
    добавляю ваш код и ничего не меняется
    PageSpeed Insights как было 74% так и осталось.
    Скажите в чем может быть проблема???

  28. Игорь Горнов

    В особенностях конфигурации сервера Вашего хостинга, где расположен сайт. По моему, в статье и комментариях я уже отмечал, что этот метод не всем подходит.

  29. Валерий

    Игорь, хорошая статья. Давно хотел это сделать, но не знал как. Теперь понятно. У меня один вопрос: "В какое место файла .htaccess нужно вставить код?".

  30. Игорь Горнов

    Валерий, если у Вас уже есть какие-то фрагменты кода в .htaccess, то там должна быть такая строчка:

    # END WordPress

    В этом случае не только данный, но и любой код следует поместить выше этой строчки. Остальное не имеет значения.

  31. vokacan

    Информация полезная, но разобраться новичку довольно сложно, на мой взгляд.

  32. Aely

    Странно у меня то же не сработало, а что нужно делать, вернее что нужно у хостера спрашивать?

  33. Игорь Горнов

    У хостера нужно спросить следующее: есть ли возможность включить кэширование на сервере для всех возможных файлов. Возможно, у них уже есть готовый алгоритм, отличный от предложенного мною.

  34. Aely

    Спасибо, сейчас написал.

  35. Aely

    Вот прикол, они(хостер) сказали что у них всё включено, а я им, а гуглспидтест - показывает "используйте кеш браузера", а они мне - это вопросы к гуглспидтест. Не могу понять кому верить ?:)

  36. Игорь Горнов

    Aely, такое отношение к клиенту со стороны хостера, по меньшей мере, странно. По идее, они должны бы объяснить и дать возможный алгоритм для внесения его в файл .htaccess, чтобы активировать функцию, даже если она у них включена. Интересно, а Вы не в первый раз обращались к службе поддержки, как она проявляла себя в других ситуациях?

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

  37. Aely

    А есть ещё варианты, кроме гуглспид, проверить включен ли хеш?

  38. Игорь Горнов

    Aely, насколько я знаю, Google PageSpeed не ошибается.

  39. Яна

    Мне вообще написали: "Кеширование подлежит настройке через административную панель сайта в зависимости от установленной на сайт CMS.

    С инструкцией по настройке кеширования Вы можете ознакомиться, обратившись к документации используемой Вами системе управления сайтом". Ничего не понятно

  40. Светлана

    Снова, все получилось! Но снова, не с первого раза))).
    Первоначальный код сработал, только нужно было удалить все что ранее было в файле .htaccess.
    Урррраа!!!!!!!!!!!!

  41. Игорь Горнов

    Светлана, поздравляю Вас с маленькой победой. 🙂

  42. Денис

    Попробовал оба варианта на движке OCstore. Работают оба с одинаковым результатом. Спасибо за помощь.

  43. Игорь Горнов

    Денис, а как работает сам движок?

  44. Оксана

    Написала своему хостеру "thehost" и мне помогли.
    Их ответ: "Включили кэширование для вашего сайта на стороне nginx. Подобное в .htaccess работать не будет, поскольку на хостинге стоит связка apache+nginx."

    Поэтому обратитесь к своему провайдеру и они вам помогут

  45. Дмитрий

    Спасибо за инструкцию, картина в "Page Speed" стала более привлекательной;)

  46. Алексей

    Мой хостер рассказывает что на серверах виртуального хостинга сжатие статических файлов включено по умолчанию. Статические файлы обрабатываются веб-сервером Nginx, доступа к настройке которого нет.
    Проверить наличие сжатия можно при помощи ресурса вотсмайайпи.орг
    Настройка кэширования и/или сжатия статических файлов в файле .htaccess на виртуальном хостинге невозможна.
    Вы можете настроить кэширование средствами CMS или плагинов.
    Если вам критична настройка gzip и expires, рекомендуем приобрести VPS сервер.

  47. ринат

    Не удалось сделать самому, так как при вставке кода сайт перестает работать. Пришлось написать хостеру, на что он мне ответил: Такое кеширование используется самим браузером и не зависит от настроек технической площадки, если только те не содержат специальных запретов на такое кеширование. У нас ограничений на кеширование бразуером нет.
    Так не понятно тогда, зачем вставлять код? Или я чего-то не понимаю?

  48. Игорь Горнов

    Ринат, если специалисты Вашего хостинга ответили, что запрета нет, значит, все нормально. В остальных случаях этот код необходим, и об этом недвусмысленно говорит PageSpeed.

  49. Сергей

    Автор, а почему у вас гугловская скоростемерка показывает всего лишь 54/100 и 66/100?

  50. Игорь Горнов

    А потому, Сергей, что я заменил тему и добавил некоторые сторонние ресурсы, которые сильно влияют на эффективность загрузки страниц. Конечно, постепенно все приведу в норму.

  51. Юрий

    Спасибо Игорь!!! Ваш код единственный который заработал из всех которые я перепробовал. А их блин было не мало..

  52. Игорь Горнов

    Юрий, я рад, что Вы нашли то, что искали.

  53. Елена

    мне легче залезть в болото с крокодилами нежели в код:) потому поставила плагин суперкэш, но он не дает кэш на стороне пользовательских браузеров. Обращалась к хостеру - стандартная отписка, что с их стороны все норм. Что делать прям не знаю...

  54. Игорь Горнов

    Здравствуйте, Елена. Вы молодец, что обеспокоены оптимизацией скорости загрузки. Безусловно, это важный момент. Хотя не всегда удается вовремя сосредоточить свое внимание на этом аспекте. Мой блог сейчас тоже не идеален в этом плане. После замены темы пока не успел еще восстановить статус-кво.

    К тому же не всегда удается достичь максимальной эффективности и не всегда виноват в этом хостер, хотя от него тоже многое зависит. Я проверил главную страницу Вашего сайта через PageSpeed. К сожалению, все ресурсы, для которых Гугл рекомендует указать срок действия, относятся к внешним сайтам (кнопки социальных сетей, Яндекс Метрика и т.д.), поэтому повлиять Вы на них никак не сможете.

    Тут Ваш хостинг провайдер прав, с его стороны, видимо, все в норме. Но Вы не расстраивайтесь сильно, остальные вебсайты тоже пользуются услугами подобных сервисов, так что здесь мы все в равных условиях.

  55. Дмитрий

    Игорь Здравствуйте! Поменяйте логин и пароль в админке! XSS атаки проходят в ваше папку wp-includes.

  56. Игорь Горнов

    Дмитрий, огромное спасибо за подсказку. Проблема действительно имеет место быть.

  57. Денис

    Спасибо! Первый способ помог

  58. Игорь Горнов

    Пожалуйста, Денис.

  59. interserge

    Ничего не помогает загнать в кэш запчасти от поиска Яндекс для сайта, Гугл ругается на:

     https://site.yandex.net/v2.0/i/search.png (не указан срок действия)
    https://site.yandex.net/v2.0/js/opensearch.js (не указан срок действия)
    https://site.yandex.net/v2.0/js/suggest.js (не указан срок действия)
    http://site.yandex.net/v2.0/js/all.js (6 часов)

    Попробовал все ваши конструкции - не помогло.
    Вынести этот блок в отдельный PHP и кешировать сам PHP - тоже не работает
    Все внутренние элементы кешируются без проблем (т.е. дело не в хостинге)

  60. Игорь Горнов

    На внешние элементы мы воздействовать не в силах. К сожалению.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Чтобы ввести любой код, вставьте его между [php] и [/php]. Ссылка (URL), помещенная в текст комментария, не будет активной. C целью ее выделения и более удобного копирования можно заключить ее между тегами <pre> и </pre>.