Как сделать кэш для сайта

Добавил пользователь Morpheus
Обновлено: 04.10.2024

Различные виды кеширования

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

Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надёжности, производительности и масштабируемости веб-сайтов и веб-приложений.

Приватный (private) кеш браузера

Общий (shared) прокси-кеш

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

Цели кеширования

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

Ответы на запросы отличные от GET , если есть что-либо, подходящее для использования в качестве ключа кеша.

Управление кеш ированием

Заголовок Cache-control

Полное отсутствие кеширования

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

Кешировать, но проверять актуальность

Перед тем, как выдать копию, кеш запрашивает исходный сервер на предмет актуальности ресурса.

Приватные (private) и общие (public) кеши

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

Срок действия (Expiration)

Самой важной здесь является директива "max-age= " — максимальное время, в течение которого ресурс считается "свежим". В отличие от директивы Expires , она привязана к моменту запроса. К неизменяющимся файлам приложения обычно можно применять "агрессивное" кеширование. Примером таких статических файлов могут быть изображения, файлы стилей (CSS) или скриптов (JavaScript).

Подробнее об этом рассказывается в разделе Свежесть ресурса.

Проверка актуальности

При использовании директивы "must-revalidate" кеш обязан проверять статус ресурсов с истёкшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе Валидация кеша.

Заголовок Pragma

Свежесть сохранённой копии

Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:

Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок "Cache-control: max-age=N", то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок Expires , и, если он есть, то срок действия берётся равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified. Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.
Время устаревания (expirationTime) вычисляется следующим образом:

где responseTime — это время получения ответа по часам браузера, а currentAge — текущий возраст кеша.

Обновление статических ресурсов (Revved resources)

Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их "срок годности" имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование даёт больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.

Этот метод имеет дополнительное достоинство: одновременное обновление двух кешированных ресурсов не приводит к ситуации, при которой устаревшая версия одного ресурса используется вместе с новой версией другого. Это очень важно для сайтов с взаимосвязанными файлами стилей CSS или JS-скриптов — связь может возникнуть, например, из-за ссылок на одни и те же элементы HTML-страницы.

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

Валидация кеша

Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок "Cache-control: must-revalidate". Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.

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

Заголовки ETag

Заголовок ответа ETag является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет её значение. Если в ответе присутствует заголовок ETag , клиент может транслировать его значение через заголовок If-None-Match (en-US) будущих запросов для валидации кешированного ресурса.

Заголовок ответа Last-Modified можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок Last-Modified , то для валидации кешированного документа клиент может выводить в запросах заголовок If-Modified-Since .

При запросе на валидацию сервер может либо проигнорировать валидацию и послать стандартный ответ 200 OK , либо вернуть ответ 304 Not Modified (с пустым телом), тем самым указывая браузеру взять копию из кеша. В последнем случае в ответ могут входить также заголовки для обновления срока действия кешированного ресурса.

Изменяющиеся ответы

Если кеш получает запрос, который можно удовлетворить сохранённым в кеше ответом с заголовком Vary , то использовать этот ответ можно только при совпадении всех указанных в Vary полей заголовка исходного (сохранённого в кеше) запроса и нового запроса.

Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка Vary: User-Agent кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).

Поскольку значение заголовка User-Agent различается ("varies") у мобильных и десктопных клиентов, закешированный мобильный контент не будет по ошибке отсылаться пользователям десктопов и наоборот.

Цитатник веб-разработчиков В тексте курса вы встретите цитаты, высказанные в разное время разработчиками системы и разработчиками проектов на базе Bitrix Framework. Надеемся, что такие неформальные замечания внесут некоторое разнообразие в процесс изучения. Заодно опытные специалисты поделятся и своим опытом.

Имена авторов цитат даются в том написании, в каком авторы зарегистрировали себя на сайте "1С-Битрикс". .

Курс для разработчиков - продолжение линейки учебных курсов по Bitrix Framework. Получение сертификата по курсу рекомендуется после успешной сдачи тестов по всей линейке курсов, так как без понятия о работе Контент-менеджера и Администратора создание успешных сайтов будет затруднено.

Чтобы научиться программировать в Bitrix Framework, нет необходимости изучать всю линейку курсов. Но есть моменты, которые необходимо знать разработчикам о системе, они раскрыты в начальных курсах:

Интерфейс программы - в главе Элементы управления курса Контент-менеджер.
Компоненты 2.0 (начальные сведения) в главе Компоненты 2.0 (начальные сведения) курса Контент-менеджер.
Информационные блоки - в главе Информационные блоки (начальные сведения) курса Контент-менеджер.
Управление доступом к файлам, элементам контента, модулям и другие права доступа в главе Управление доступом курса Администратор. Базовый.
Работа с инструментами системы - в главе Работа с инструментами курса Администратор. Базовый.
Модуль Поиск - в главе Поиск курса Администратор. Базовый.

Вся информация по администрированию модулей размещена в курсах:

"1С-Битрикс: Управление сайтом"

"1С-Битрикс: Корпоративный портал"

Как построен курс

Общепринятая градация квалификации разработчиков в рамках курса обозначает что:

Junior сможет создавать простые сайты работая со штатными компонентами и модифицируя их шаблоны.
Middle разработчик может работать с API Bitrix Framework.
Senior умеет работать над производительностью и безопасностью сайтов, создавать свои модули и компоненты.

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

Начальные требования к подготовке

Для успешного изучения курса и овладения мастерством разработки сайтов на Bitrix Framework необходимо владеть (хотя бы на начальном уровне):

основами PHP, баз данных;
основами HTML, CSS.

У нас часто спрашивают, сколько нужно заплатить

Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов - ничего из этого оплачивать не нужно.

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

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

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат - это если общее число набранных Вами баллов отличается от максимального на 1-2%.

Тесты

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

Комментарии к статьям

Что дальше?

Одновременно с изучением курса Разработчик Bitrix Framework вам придётся обращаться к информации о других технологиях Bitrix Framework. Эта информация размещена в следующих курсах:

Для преподавания оффлайн

Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 5 дней (40 академических часов).

Если нет интернета

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса.

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.

Итак, мы узнали, как упаковать группу страниц и ресурсов в виде автономного приложения. Мы научились создавать файл манифеста, обновлять его и обеспечивать исполнение созданного автономного приложения в браузерах. Хотя этих знаний достаточно для создания простых автономных приложений, более сложные веб-сайты иногда требуют дополнительной работы. Например, мы можем хранить определенное содержимое онлайн, заменять определенные страницы в автономном режиме или определять (программным способом), подключен ли компьютер к интернету. Далее мы научимся реализовывать все эти задачи посредством более продвинутых манифестов и применением кода JavaScript.

Доступ к онлайновым файлам

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

Допустим, например, что на нашей автономной странице используются два изображения:

Но манифест кэширует только одно из этих изображений:

Размышляя логически, можно предположить, что браузер возьмет изображение bear.jpg из своего кэша, а изображение logo.jpg запросит у веб-сервера (при условии, что компьютер подключен к интернету). Ведь так происходит при работе с обычными сайтами, когда браузер обращается с кэшированной страницы к странице, которая еще не была сохранена в кэше. Но в действительности в этом отношении автономные приложения работают по-другому. Браузер берет изображение bear.jpg из кэша, но игнорирует изображение logo.jpg, отображая вместо него либо специальный значок отсутствующего изображения, либо просто пустое место, в зависимости от браузера.

Эта проблема решается добавлением в манифест нового раздела. Он начинается с заголовка NETWORK:, а за ним следует список файлов, которые нужно получать с веб-сервера:

Теперь, когда компьютер подключен к интернету, браузер будет пытаться получить файл logo.jpg с веб-сервера, но при отсутствии подключения предпринимать такую попытку не будет.

Здесь у вас, наверное, возникает вопрос: зачем утруждать себя созданием явного списка файлов, которые мы не хотим кэшировать? Одна из причин — из-за возможностей хранилища, например, мы игнорируем файлы большого объема, чтобы наше приложение могло сохраниться в кэше браузеров, разрешающих максимум 5 Мбайт кэша для каждого автономного приложения.

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

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

Добавление резервных решений

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

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

Браузер загружает резервный файл (в данном случае это файл MyPage_offline.html) и кэширует его. Но браузер использует этот файл только в том случае, если компьютер не подключен к интернету, а при наличии подключения браузер запрашивает первый файл (т.е. в данном случае MyPage.html).

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

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

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

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

Кроме этого, можно указать резервные ресурсы, совпадающие со всеми файлами в указанной папке:

Или же ресурсы, совпадающие с определенными типами файлов:

К сожалению, другие браузеры не понимают этот логичный синтаксис, по крайней мере, пока еще не понимают.

Проверка подключения

Раздел указания резервных файлов можно использовать в удобном JavaScript-методе для определения, находится ли браузер в режиме онлайн или нет. Опытные разработчики JavaScript, наверное, помнят свойство navigator.online, предоставляющее слегка ненадежный способ проверки, находится ли браузер в настоящее время в онлайн. Но проблема с этим методом состоит в том, что свойство online в действительности отображает состояние параметра браузера "Работать автономно", а не собственно наличие или отсутствие подключения к интернету.

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

Эта проблема решается с помощью резервного решения, которое загружает разные версии одной и той же функции JavaScript в зависимости от того, находится ли приложение онлайн или оффлайн. Раздел FALLBACK: манифеста будет таким:

Первоначальная версия веб-страницы ссылается на JavaScript-файл online.js. Он содержит эту очень простую функцию:

Но если файл online.js недоступен, браузер использует вместо него файл offline.js, который содержит ту же функцию, но с другим результатом:

В исходной странице, когда нужно узнать, находится ли приложение в режиме онлайн, выполняем эту проверку с помощью функции isSiteOnline():

Информирование об обновлениях с помощью JavaScript

С автономным приложением можно взаимодействовать посредством сравнительно ограниченного интерфейса на основе JavaScript-объекта applicationCache.

Свойство status объекта applicationCache указывает, какую операцию браузер выполняет в настоящее время — проверяет наличие обновленного манифеста, загружает новые файлы и т.п. Значение этого свойства часто обновляется, и оно почти такое же полезное, как и взаимодействующие события, которые срабатывают при изменении статуса объекта applicationCache:

События кэширования

Событие	Описание
onChecking	Когда браузер обнаруживает в веб-странице атрибут manifest, он активирует это событие и проверяет наличие соответствующего файла манифеста на веб-сервере
onNoUpdate	Если браузер уже загрузил файл манифеста и этот файл не был изменен, он активирует это событие и не предпринимает никаких дальнейших действий
onDownloading	Браузер активирует это событие, прежде чем начинать загрузку манифеста (и указанных в манифесте файлов). Это происходит при первой загрузке файлов манифеста и при обновлениях
onProgress	Браузер периодически активирует это событие при загрузке файлов, чтобы информировать о ходе загрузки
onCached	Событие указывает на завершение первоначальной загрузки для нового автономного приложения. После этого больше не происходит никаких событий
onUpdateReady	Событие указывает на завершение загрузки обновленного содержимого. На этом этапе новое содержимое готово к использованию, но не отображается в окне браузера до тех пор, пока страница не будет перезагружена. После этого больше не происходит никаких событий
onError	Где-то произошла ошибка. Возможно, недоступен веб-сервер (в таком случае страница переключается в автономный режим), возможно, в манифесте использован неправильный синтаксис или недоступен кэшированный ресурс. После этого события не происходит больше никаких других событий
onObsolete	В процессе проверки на наличие обновлений браузер обнаружил отсутствие манифеста, после чего он очищает кэш. При следующей загрузке страницы браузер загрузит ее с веб-сервера

Объект applicationCache также предоставляет два метода для более специализированных сценариев. Первый метод, update(), проверяет наличие нового манифеста. В случае его существования метод начинает загрузку в фоновом режиме. Иначе не предпринимается никаких дальнейших действий.

Хотя браузеры проверяют наличие обновлений автоматически, если есть основания полагать, что манифест изменился после первой загрузки страницы, метод update() можно вызвать вручную. Этот метод может быть полезным в приложениях с продолжительным временем работы, например, когда пользователь работает на одной и той же странице в течение всего дня.

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

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

Для тех кто оптимизировал сайт по рекомендациям инструмента от Google PageSpeed Insights, сталкивались в проблемой невозможности закешировать js скрипты сторонних сайтов.

По сути это не столь важный показатель для оптимизации, это как переносить из шапки сайта в футер CSS и JS элементы, хотя у самого Google с этим пунктом проблемы 🙂

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

О чем сегодня поговорим:

Кеш браузера своих элементов

AddOutputFilterByType DEFLATE text / html text / plain text / xml application / xml application / xhtml + xml text / css text / javascript application / javascript application /x-javascript

После этого можете выполнить проверку своего сайта в инструменте Page Speed и если все хорошо, там должны остаться ссылки на яндекс.метрику, аналитику, социальные сети и т.д.

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

Примеры сторонних скриптов

Если в первом шаге, все сделали верно, должны увидеть примерно такой список:

Используйте кеш браузера для следующих ресурсов

Правда может быть всего несколько URL на метрику и аналитику например, но это не столь важно, рецепт исправления для всех один и тот же.

Кеш сторонних элементов

Изначально хотел статью написать только с этим пунктом, но чувствую будет много вопросов, а теперь к сути.

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

Давайте теперь по порядку!

Шаг 1. Копируете список всех скриптов, которые показывает Google PageSpeed в блокнот или можно прямо с браузера.

Шаг 2. Создаем файл на хостинге с расширением php и вставляем в него следующий код:

Читайте также: