Как указать срок действия файла

Рубрики Статьи

Настройка кэширования через файл .htaccess

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

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

Для файлов с указанными расширениями в конструкции FilesMatch устанавливается отдаваемый сервером заголовок Cache-Control и переменная max-age , в которой указывается время сохранения файлов в кеше в секундах. Добавьте или удалите расширения файлов, которые для Вас будут уместны в данном случае.

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

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

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

Ниже представлен простой пример использования модуля expires в файле .htaccess:

В этом примере мы включаем модуль, устанавливаем кэширование по умолчанию на 1 месяц, а далее назначаем для файлов с расширением gif и jpg врема хранения в кэше plus 2 months . Время можно указать в годах, месяцах, неделях, днях, часах, минутах, секундах. В том числе можно использовать вариант вида:

В качестве типов файлов можно указывать различные MIME types , вот некоторые из них в качестве примера:

Как указать кэширование для файлов jpg?

PageSpeed Insights пишет про Используйте кеш браузера
для изображений

в списке только jpg файлы, всего приблизительно 80 записей — то есть количество ошибок никак не коррелирует с количеством товаров на сайте
Между тем, в .htaccess кэширование для jpg как мне кажется, включено:

(Дальше редиректы идут, я не стал копировать)

Кэширование HTTP заголовков

Автор MIL2, 27 ноября, 2014 в Проблемы и решения

Рекомендуемые сообщения

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Как использовать кеш браузера пользователей для ускорения сайта (заголовки 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 мы должны дать команду браузерам пользователей при следующих посещениях ими сайта подгружать статические элементы страниц уже из папки кэша, расположенной на компьютере, а не напрямую с сервера, что и даст так нужный нам выигрыш в скорости загрузки.

Читайте так же:  Федеральный закон от 23112009 г 261-фз

В целях решения этой задачи нужно включить в ответ сервера соответствующие 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 пару строк:

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

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

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

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

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

Точкой отсчета срока годности кэша в случае использования заголовка 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 из состава ответа сервера:

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

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

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

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

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

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

Здесь использован комплекс с минимумом типов задействованных объектов, но зато наиболее востребованных (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 будет здесь бесполезен. В таком случае, как я уже отмечал, придется задействовать помощь службы поддержки, если, конечно, ваш тариф хостинга и недостаточные знания не позволят самостоятельно решить вопрос.

Читайте так же:  Экспертиза по онкологии

Далее советую для закрепления материала обратиться к видео и посмотреть последовательно 6 уроков (один из которых посвящен настройке кеширования в браузерах), в которых подробно рассмотрены все наиболее важные аспекты ускорения сайта WP:

Умное Кеширование и Версионность в Javascript/CSS

Подключая внешние CSS и Javascript, мы хотим снизить до минимума лишние HTTP-запросы.

Для этого .js и .css файлы отдаются с заголовками, обеспечивающими надежное кеширование.

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

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

Простое кеширование ETag

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

Достаточно включить соответствующую настройку сервера (для Apache включена по умолчанию) — и к каждому файлу в заголовках будет даваться ETag — хеш, который зависит от времени обновления, размера файла и (на inode-based файловых системах) inode.

Браузер кеширует такой файл и при последующих запросах указывет заголовок If-None-Match с ETag кешированного документа. Получив такой заголовок, сервер может ответить кодом 304 — и тогда документ будет взят из кеша.

Выглядит это так:

Первый запрос к серверу (кеш чистый)

Вообще, браузер обычно добавляет еще пачку заголовоков типа User-Agent, Accept и т.п. Для краткости они порезаны.

Ответ сервера Сервер посылает в ответ документ c кодом 200 и ETag:

Следующий запрос браузера При следующем запросе браузер добавляет If-None-Match : (кешированный ETag ):

Ответ сервера Сервер смотрит — ага, документ не изменился. Значит можно выдать код 304 и не посылать документ заново.

Альтернативный вариант — если документ изменился, тогда сервер просто посылает 200 с новым ETag .

Аналогичным образом работает связка Last-Modified + If-Modified-Since :

  1. сервер посылает дату последней модификации в заголовке Last-Modified (вместо ETag )
  2. браузер кеширует документ, и при следующем запросе того же документа посылает дату закешированной версии в заголовке If-Modified-Since (вместо If-None-Match )
  3. сервер сверяет даты, и если документ не изменился — высылает только код 304, без содержимого.

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

Умное кеширование. Версионность

Общий подход для версионности — в двух словах:

  1. Во все скрипты добавляется версия (или дата модификации). Например, http://javascript.ru/my.js превратится в http://javascript.ru/my.v1.2.js
  2. Все скрипты жестко кешируются браузером
  3. При обновлении скрипта версия меняется на новую: http://javascript.ru/my.v2.0.js
  4. Адрес изменился, поэтому браузер запросит и закеширует файл заново
  5. Старая версия 1.2 постепенно выпадет из кеша

Дальше мы разберем, как сделать этот процесс автоматическим и прозрачным.

Жесткое кеширование

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

Для этого достаточно добавить заголовки Expires и Cache-Control: max-age.

Например, чтобы закешировать на 365 дней в PHP:

Или можно закешировать контент надолго, используя mod_header в Apache:

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

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

P.S А вот Firefox кеширует адреса с вопросительными знаками..

Автоматическое преобразование имен

Разберем, как автоматически и прозрачно менять версии, не переименовывая при этом сами файлы.

Имя с версией -> Файл

Самое простое — это превратить имя с версией в оригинальное имя файла.

На уровне Apache это можно сделать mod_rewrite:

Такое правило обрабатывает все css/js/gif/png/jpg-файлы, вырезая из имени версию.

/images/logo.v2.gif -> /images/logo.gif
/css/style.v1.27.css -> /css/style.css
/javascript/script.v6.js -> /javascript/script.js

Но кроме вырезания версии — надо еще добавлять заголовки жесткого кеширования к файлам. Для этого используются директивы mod_header:

А все вместе реализует вот такой апачевый конфиг:

Директивы Header могут быть где угодно, даже в .htaccess — без разницы.

Автоматическое добавление версии в имя файла на HTML-странице

Как ставить версию в имя скрипта — зависит от Вашей шаблонной системы и, вообще, способа добавлять скрипты (стили и т.п.).

Например, при использовании даты модификации в качестве версии и шаблонизатора Smarty — ссылки можно ставить так:

Функция version добавляет версию:

Результат на странице:

Чтобы избежать лишних вызовов stat , можно хранить массив со списком текущих версий в отдельной переменной

В этом случае в HTML просто подставляется текущая версия из массива.

Можно скрестить оба подхода, и выдавать во время разработки версию по дате модификации — для актуальности, а в продакшн — версию из массива, для производительности.

Такой способ кеширования работает везде, включая Javascript, CSS, изображения, flash-ролики и т.п.

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

HTTP-кеширование

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

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

Когда сервер возвращает запрос, он также отправляет набор HTTP-заголовков, описывающих тип контента, длину, команды для работы с кешем, маркер подтверждения и т. д. Например, в примере выше сервер возвращает запрос размером 1024 Б, отдает команду клиенту кешировать его на 120 секунд и отправляет маркер подтверждения (x234dff). Он используется, чтобы проверить, не изменился ли ресурс, после того как срок действия ответа истек.

Подтверждение кешированных ответов с помощью ETags

  • Сервер отправляет маркер подтверждения в HTTP-заголовке ETag.
  • С помощью маркера подтверждения можно проверить, изменился ли ресурс.

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

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

В примере выше клиент автоматически отправляет маркер ETag в HTTP-заголовке If-None-Match. Сервер проверяет совпадение маркера с нужным ресурсом, и если тот не изменился, отправляет ответ 304 Not Modified. Это значит, что кешированный ответ остался прежним, и его можно снова использовать в течение следующих 120 секунд. Обратите внимание, что скачивать ресурс ещё раз не нужно. Это уменьшает время загрузки страницы и экономит пропускную способность канала.

Чем полезна проверка актуальности для разработчика? Браузер сделает все автоматически: проверит, был ли указан маркер подтверждения ранее, добавит его в исходящий запрос и обновит временные отметки на основе ответа от сервера. Все, что нам нужно сделать, — проверить, действительно ли сервер отправляет нужные маркеры ETag. Чтобы узнать, какие параметры следует установить, ознакомьтесь с документацией к серверу.

Note: Совет. В проекте HTML5 Boilerplate размещены примеры файлов конфигурации для самых популярных серверов с подробными комментариями для всех параметров и настроек. Найдите в списке нужный сервер, выберите подходящие настройки и убедитесь, что они установлены на вашем сервере.

  • Правила кеширования ресурса можно указать с помощью HTTP-заголовка Cache-Control.
  • Директивы Cache-Control определяют, где, как и на какое время может быть кеширован ресурс.

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

Читайте так же:  Приказ на утверждение формы образец

no-cache и no-store

Директива no-cache означает, что при повторном запросе к тому же URL ответ можно использовать только после проверки изменений. Таким образом, если указан соответствующий маркер подтверждения (ETag), будет выполнена повторная проверка. Однако при отсутствии изменений данные не будут скачиваться ещё раз.

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

public и private

Если в ответе содержится директива public, его можно кешировать, даже если с ним связана HTTP-аутентификация и код статуса ответа обычно нельзя сохранять. Эта директива требуется редко, потому что другая информация, заданная для кеширования, (например, max-age) показывает, что ответ можно сохранить.

Директива private, наоборот, используется для ответов, которые можно сохранить в кеше браузера, но не в промежуточных кешах. Это происходит из-за того, что подобная информация предназначается для одного пользователя. Например, HTML-страницу с личными данными пользователя можно кешировать в браузере, но не в сетях доставки контента.

Эта директива указывает период времени в секундах, в течение которого скачанный ответ может быть повторно использован. Отсчет начинается с момента запроса. Например, max-age=60 означает, что ответ может быть кеширован и использован в течение 60 секунд.

Выбор правил Cache-Control

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

По данным HTTP Archive, на 300 000 самых популярных сайтов по рейтингу Alexa около половины скачанных запросов можно сохранить в кеше браузера. Это помогло бы сэкономить огромные объемы данных при повторном посещении страниц. Однако это не означает, что в вашем приложении обязательно есть 50% ресурсов, которые можно сжать. Некоторые сайты сохраняются в кеше более чем на 90%, а на других размещено много личной или меняющейся со временем информации, которую кешировать невозможно.

Проверьте ваши страницы, определите, какие ресурсы можно кешировать, и убедитесь, что они возвращают правильные заголовки Cache-Control и ETag.

Аннулирование и обновление кешированных ответов

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

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

Предположим, мы задали команду кешировать таблицу стилей CSS в течение 24 часов (max-age=86400), но чуть позже обновили дизайн сайта и хотим, чтобы это увидели все пользователи. Как сообщить им, что нужно обновить устаревшую копию CSS в кеше? Это непросто, потому что нам потребуется изменить URL ресурса.

Кешированный ответ сохраняется в браузере до тех пор, пока не истечет срок его действия или пока он не будет удален, например при очистке кеша браузера. Таким образом, во время изменения страницы не все пользователи работают с одинаковыми версиями файла: те, кто загрузил ресурс недавно, видят новую версию, а те, кто кешировал предыдущую (но ещё действительную) копию, — старую.

Как совместить кеширование ресурсов и обновления сайта? Можно просто отредактировать URL файла, чтобы пользователь скачивал новый ответ каждый раз, когда его контент меняется. Для этого добавьте в имя файла идентификационную метку или номер версии, например style.x234dff.css.

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

  • Для HTML указана директива no-cache, поэтому браузер будет проверять актуальность документа при каждом запросе и при изменениях скачивать последнюю версию ресурса. Кроме того, мы изменили HTML-разметку, добавив идентификационные метки в URL CSS- и JavaScript-ресурсов. Если эти файлы изменятся, HTML тоже обновится, и браузер скачает новую копию HTML-ответа.
  • Браузерам и промежуточным кешам (например, сетям доставки контента) разрешено сохранять CSS. Срок его действия заканчивается через 1 год. Обратите внимание, что мы можем установить такой длинный период, потому что мы добавили идентификационную метку в название файла. Поэтому если CSS обновится, то URL тоже изменится.
  • Срок действия для JavaScript тоже истекает через 1 год. Однако ресурс отмечен директивой private, потому что в нем содержатся личные данные пользователи, которые нельзя сохранять в кеше сетей доставки контента.
  • У кешированного изображения нет версии или уникальной идентификационной метки, и срок его действия заканчивается через 1 день.

Таким образом, с помощью ETag, Cache-Control и уникальных URL мы можем достичь нужных нам результатов: долгих сроков действия, контроля над кешированием ресурса и обновлений в любой момент.

Список методов оптимизации

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

Помните о некоторых советах и техниках, которые помогут вам выбрать стратегию кеширования:

  1. Используйте одинаковые URL для одного ресурса. В противном случае контент каждый раз будет скачиваться заново. Помните, что в URL регистр букв имеет значение!
  2. Убедитесь, что сервер отправляет маркер подтверждения (ETag). Если ресурс на сервере не изменился, то благодаря этому маркеру те же байты не будут передаваться повторно.
  3. Определите, какие ресурсы можно сохранить в промежуточных кешах. Чаще всего это ответы, которые одинаковы для всех пользователей.
  4. Определите подходящий срок действия для каждого ресурса. У данных могут быть разные требования к частоте обновления информации. Учитывая это, выберите подходящее значение max-age для каждого ресурса.
  5. Установите подходящую иерархию кешей для вашего сайта. Используйте URL ресурсов с идентификационными отметками контента и короткие сроки действия (или директиву no-cache) для HTML-документов. С их помощью вы можете указать, когда кешированные версии данных будут обновлены.
  6. Уменьшите пересылку данных. Если часть ресурса, например функции JavaScript или наборы CSS-стилей, обновляется часто, отправляйте ее код в отдельном файле. Тогда та часть контента, которая меняется редко, например коды библиотек, может быть загружена из кеша. Это уменьшит количество скачиваемых данных при обновлении ресурса.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates.