Что такое код asp cachecontrolmaxage

Содержание

IIS7 Cache-Control

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

Я попробовал шаг дальше http://www.galcho.com/Blog/post/2008/02/27/IIS7-How-to-set-cache-control-for-static-content.aspx но безрезультатно. Я все еще получаю запросы, идущие на сервер с возвращением 304s.

есть ли у кого-нибудь способ сделать это? У меня есть графически интенсивный сайт и мои пользователи забиваются (так же как и мой сервер) каждый раз, когда они запрашивают страницу. Странно, что изображения, похоже,имеют «Cache-Control private, max-age=3600», отображаемые в Firebug, но браузер все еще запрашивает их, когда я нажимаю F5.

6 ответов:

Если вы хотите установить заголовок Cache-Control, нет ничего в интерфейсе IIS7, чтобы сделать это, к сожалению.

вы можете, однако, отказаться от этой сети.config в корне папки или сайта, где вы хотите установить его:

это сообщит клиенту кэшировать содержимое в течение 7 дней в этой папке и во всех подпапках.

вы также можете сделать это, отредактировав метабазу IIS7 через appcmd.exe , например:

Это неправда Джефф.

вам просто нужно выбрать папку в вашем интерфейсе диспетчера IIS 7 (например, изображения или событие в папке веб-приложения по умолчанию), а затем нажмите «заголовки ответов HTTP». Затем вы должны нажать на кнопку » Установить общий заголовок..»в правой панели и выберите» истечение срока действия веб-контента». Там вы можете легко настроить максимальный возраст 24 часов, выбрав » после:», введя» 24 «в текстовом поле и выберите» часы » в выпадающем списке.

ваш первый абзац что касается интернета.запись конфигурации является правильным. Я бы добавил атрибут cacheControlCustom, чтобы установить заголовок управления кэшем в «public» или что-то еще, что нужно в этом случае.

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

Edit: удалено запутанное предложение:)

Я использую этот

кэшировать статическое содержимое в течение 500 дней с помощью заголовка public cache-control.

обновление F5 имеет семантику «пожалуйста, перезагрузите текущий HTML и его прямые зависимости». Следовательно, вы должны ожидать, что любой ресурс imgs, css и js, на который непосредственно ссылается HTML, также будет перефокусирован. Конечно, 304 является приемлемым ответом на это, но обновление F5 подразумевает, что браузер будет делать запрос, а не полагаться на свежий контент кэша.

вместо этого попробуйте просто перейти в другое место, а затем перейти спина.

вы можете принудительно обновить, мимо 304, удерживая ctrl при нажатии f5 в большинстве браузеров.

дополняя ответ Элмера, поскольку мое редактирование было откатано.

кэшировать статическое содержимое в течение 365 дней с заголовком public cache-control, IIS можно настроить следующим образом

это будет переводиться в заголовок, как это:

обратите внимание, что max-age-Это Дельта в секундах, выраженная положительным 32-битным целым числом, как указано в RFC 2616 разделы 14.9.3 и 14.9.4. Этот представляет собой максимальное значение 2^31 или 2,147,483,648 секунд (более 68 лет). Однако для обеспечения лучшей совместимости между клиентами и серверами рекомендуется использовать не более 365 дней (один год).

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

есть простой способ: 1. использование веб-сайта.конфиг 2. в разделе» staticContent » удалите определенное fileExtension и добавьте mimeMap 3. добавить «clientCache»

Оптимизация сети

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

Включение HTTP-заголовков кеширования

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

Настройка заголовков кеширования для статического содержимого

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

ETag

В этот HTTP-заголовок сервер IIS записывает хеш, вычисленный на основе даты последнего изменения содержимого. Для статического содержимого, такого как файлы изображений и CSS, в заголовке ETag сервер IIS возвращает дату последнего изменения файла. В последующем, когда на сервер будут поступать запросы с ранее вычисленным значением ETag, IIS вычислит ETag для запрошенного файла и, если оно не совпадет с клиентским значением ETag, обратно будет отправлен запрошенный файл, а если совпадет, клиенту будет отправлен ответ HTTP 304 (Not Modified). Значение ETag, сохраненное клиентом, передается серверу в HTTP-заголовке If-None-Match запроса.

Last-Modified

В этот HTTP-заголовок сервер IIS записывает дату последнего изменения запрошенного файла. Это — дополнительный заголовок кеширования, который может использоваться как запасной вариант, когда поддержка заголовка ETag отключена, когда на сервер будут поступать запросы, содержащие дату последнего изменения, IIS сравнит ее с датой последнего изменения файла и решит, отправить ли содержимое файла (если время последнего изменения файла изменилось) или послать ответ HTTP 304. Дата последнего изменения файла, сохраненная клиентом, передается серверу в HTTP-заголовке If-Modified-Since Запроса.

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

Этого можно добиться с помощью HTTP-заголовка Cache-Control с атрибутом max-age или HTTP-заголовка Expires. Разница между атрибутом max-age и заголовком Expires в том, что max-age определяет срок хранения, а заголовок Expires позволяет указать фиксированную дату и время, когда истекает срок хранения содержимого.

Например, если установить в атрибуте max-age значение 3600, браузер будет хранить содержимое в кеше один час (3600 секунд = 60 минут = 1 час) и автоматически использовать его, не посылая запросы серверу. Как только срок хранения содержимого истечет (независимо от использовавшегося заголовка кеширования), оно будет помечено как устаревшее. Когда в следующий раз браузер обнаружит, что содержимое устарело, он отправит на сервер запрос на получение более нового содержимого.

Убедиться в отсутствии запросов на получение кешированного содержимого можно с помощью инструментов мониторинга HTTP-трафика, таких как Fiddler, и узнать, какие запросы, посылаются серверу. Если обнаружится запрос на содержимое, которое по вашему мнению должно кешироваться, проверьте наличие заголовков max-age/Expires в ответе на этот запрос.

Использование max-age/Expires совместно с ETag/Last-Modified гарантирует, что на запрос, отправленный после того, как истечет срок хранения содержимого, будет возвращен ответ HTTP 304, если запрошенное содержимое на сервере в действительности не изменилось. Ответ в этом случае будет содержать новый HTTP-заголовок max-age/Expires.

В большинстве браузеров щелчок на кнопке Refresh (Обновить) (или нажатие клавиши F5) заставит браузер обновить кеш, проигнорировав заголовок max-age/Expires, и отправить запрос на получение кешированного содержимого, даже если срок его хранения еще не истек. Запросы все еще будут содержать заголовки If-Modified-Since/If-None-Match, если они применимы, чтобы сервер мог вернуть ответ HTTP 304, если содержимое не изменилось.

Чтобы включить поддержку заголовка max-age, добавьте следующие настройки в файл web.config:

Фрагмент с настройками выше гарантирует, что в ответ на все запросы, отправленные для получения статического содержимого, будут возвращаться ответы с HTTP-заголовком cache-control, содержащим атрибут max-age со значением 600 секунд.

Чтобы задействовать заголовок Expires, измените элемент clientCache, как показано ниже:

Фрагмент с настройками выше сообщает, что срок хранения статического содержимого выше истечет 11 июля 2015 года в 6 часов утра.

Если потребуется указать разные сроки хранения для разного содержимого, например, для файлов JavaScript — фиксированную дату, а для изображений 100-дневный срок хранения, можно добавить разделитель location и указать разные настройки для разных компонентов приложения, как показано ниже:

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

Настройка заголовков кеширования для динамического содержимого

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

С другой стороны, если изучить содержимое динамической страницы, можно найти способ выразить дату последнего ее изменения или даже рассчитать значение ETag для нее. Например, если в ответ на запрос информация о продукте извлекается из базы данных, таблица со списком продуктов могла бы хранить поле с датой последнего изменения, которую в свою очередь можно было бы использовать для установки заголовка Last-Modified. В случае отсутствия такого поля в таблице, можно попробовать вычислить контрольную сумму MD5 полей и отправлять результат в заголовке ETag. При получении последующих запросов сервер мог бы вычислять контрольную сумму MD5 заново и при совпадении ее со значением ETag возвращать ответ HTTP 304.

Например, следующий код устанавливает заголовок Last-Modified для динамической страницы с описанием продукта:

В отсутствие даты последнего изменения, можно возвращать в заголовке ETag контрольную сумму MD5, как показано ниже:

По умолчанию поддержка заголовка ETag в ASP.NET выключена. Чтобы включить ее, необходимо изменить режим кеширования в ServerAndPrivate, разрешив кеширование содержимого на стороне сервера и на стороне клиента, но не на промежуточных компьютерах, таких как прокси-серверы.

Получив запрос с заголовком ETag, вы можете сравнить вычисленное значение ETag с полученным от браузера и, если они совпадают, послать ответ HTTP 304, как показано ниже:

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

Для той же цели можно использовать атрибут max-age в заголовке Cache-Control:

Вместо установки сроков кеширования в коде, их можно устанавливать в файлах .aspx, в директивах кеширования. Например, если информация о продукте, отображаемая на странице, может храниться в кеше в течение 10 минут (600 секунд) на стороне клиента, в страницу можно добавить следующую директиву:

Илон Маск рекомендует:  Что такое код cgi

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

Включение сжатия в IIS

Кроме мультимедийных файлов (аудио- и видеороликов, изображений) и двоичных файлов, таких как компоненты Silverlight и Flash, большая часть содержимого (страницы HTML, таблицы стилей CSS, сценарии JavaScript, данные в формате XML и JSON) передается веб-сервером в текстовом виде. Используя поддержку сжатия, имеющуюся в IIS, эти текстовые данные можно сжимать в размерах, что позволит уменьшить объем передаваемых данных и время его передачи. Поддержка сжатия в IIS позволяет уменьшать размеры ответов до 50-60 процентов от их оригинального размера, а иногда и больше.

Сервер IIS поддерживает два типа сжатия, статическое и динамическое. Прежде чем использовать сжатие, убедитесь сначала в наличии компонентов статического и динамического сжатия.

Статическое сжатие

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

Статическое сжатие может пригодиться для файлов, которые обычно не изменяются (то есть, являются «статическими»), таких как файлы CSS и JavaScript. Но даже если оригинальный файл изменится, IIS обнаружит это и повторно сожмет его.

Имейте в виду, что наибольшего эффекта можно получить при сжатии текстовых файлов (*.htm, *.txt, *.css) и некоторых двоичных, таких как файлы документов Microsoft Office (*.doc, *.xsl). Но при применении к уже сжатым файлам, таким как файлы изображений (*.jpg, *.png) и сжатым файлам документов Microsoft Office (.docx, *.xslx) может получиться даже обратный эффект.

Динамическое сжатие

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

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

Настройка сжатия

Первое, что следует сделать для использования сжатия, — включить динамическое или статическое сжатие, или оба сразу. Чтобы включить сжатие в IIS, откройте приложение IIS Manager, выберите свой компьютер, щелкните на пункте Compression (Сжатие) и выберите параметры сжатия, как показано на рисунке ниже:

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

После выбора типа сжатия можно пойти еще дальше и определить, какие типы MIME должны сжиматься статически, а какие динамически. К сожалению, IIS не поддерживает возможность выполнения этих настроек из приложения IIS Manager, поэтому вам придется изменить их вручную, в конфигурационном файле IIS — applicationHost.config, находящийся в папке %windir%\System32\inetsrv\config folder.

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

После добавления в список новых типов MIME проверьте, действительно ли сжатие выполняется, с помощью инструментов перехвата HTTP-трафика, таких как Fiddler. Сжатые ответы должны иметь заголовок Content-Encoding со значением gzip или deflate.

Сжатие и клиентские приложения

Чтобы сервер IIS мог сжимать исходящие ответы, он должен быть уверен, что клиентское приложение способно распаковывать сжатое содержимое. Поэтому, когда клиентское приложение посылает запрос серверу, оно должно добавить HTTP-заголовок Accept-Encoding со значением gzip или deflate.

Большинство известных браузеров автоматически добавляют этот заголовок, поэтому при работе с веб-приложением или с приложением Silverlight посредством браузера, IIS будет возвращать сжатое содержимое. Однако, если вы посылаете HTTP-запросы из своего приложения для .NET, используя для этого тип HttpWebRequest, заголовок Accept-Encoding не добавляется автоматически, поэтому вам необходимо добавить его вручную. Кроме того, HttpWebRequest не распаковывает сжатые ответы, если не настроить его специально.

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

Другие объекты, обладающие возможностью обмена по протоколу HTTP, такие как прокси-объект веб-службы ASMX или объект WebClient, также поддерживают сжатие, но требуют ручной настройки для отправки заголовка и распаковывания сжатого содержимого. Службы WCF на основе протокола HTTP, до версии WCF 4, не поддерживали сжатие в клиентах .NET, использующих ссылки на службы или фабрику каналов. Начиная с версии WCF 4, сжатие поддерживается автоматически (отправка заголовков и распаковывание сжатого содержимого).

Минификация и объединение

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

Количество запросов, которые браузер должен отправить и на которые должен получить ответы. Чем больше запросов приходится отправлять, тем больше времени будет тратиться на отправку всех запросов, потому что браузеры могут одновременно открывать лишь ограниченное количество соединений к единственному серверу (например, IE 9 может одновременно послать одному и тому же серверу не более 6 запросов).

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

Чтобы решить эти проблемы, необходимо средство, позволяющее уменьшать размеры ответов и сокращать количество запросов (и ответов, соответственно). В ASP.NET MVC 4 и ASP.NET 4.5 это средство встроено в фреймворк и называется «Bundling and minification» (Объединение и минификация).

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

Применение приема минификации совместно со сжатием может значительно уменьшить размеры ответов. Например, оригинальный файла библиотеки jQuery 1.6.2 имеет размер 240 Кбайт. После сжатия он уменьшается примерно до 68 Кбайт. Минифицированная версия оригинального файла имеет размер 93 Кбайт, чуть больше сжатой версии, а после сжатия минифицированной версии, размер файла уменьшается до 33 Кбайт, что составляет примерно 14 процентов от первоначального размера.

Подробно процесс минификации файлов с помощью пакета Microsoft.AspNet.Web.Optimization обсуждается в статье «Сжатие кода JavaScript и CSS».

Использование сетей доставки содержимого (CDN)

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

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

Здесь нам на помощь могут прийти . Сеть доставки содержимого — это множество веб-серверов, размещенных в разных уголках Земли и обеспечивающих географическую близость вашего веб-приложения к конечному пользователю. При использовании CDN, вы фактически используете единый адрес сети CDN, где бы ни находились, а местный сервер имен DNS будет преобразовывать этот адрес в фактический адрес ближайшего сервера CDN. Различные Интернет-компании, такие как Microsoft, Amazon и Google, имеют собственные сети CDN, которыми можно пользоваться.

Ниже описывается типичная последовательность действий по настройке сети CDN:

В настройках сети CDN вы указываете, где находится оригинальное содержимое.

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

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

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

На первом шаге вам следует выбрать поставщика услуг CDN и настроить доставку своего содержимого, как описывается в инструкции поставщика. Когда у вас появится адрес CDN, просто замените ссылки на статическое содержимое (изображения, стили, сценарии) так, чтобы они ссылались на адрес CDN. Например:

IIS7 cacheControlMaxAge атрибут не работает

November 2020

5.4k раз

В IIS 7.5 я поставил cacheControlMaxAge быть один год, как так

Тем не менее, этот инструмент Google PageSpeed ​​все еще говорят о том, что файлы не кэшируются:

Почему говорят «истечения срока действия не указано»?

Весь WebApp подается через протокол HTTPS, что фактор?

2 ответы

Я решил эту проблему, изменив указанный путь от Content/Images просто Content

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

Я нашел Google PageSpeed ​​в некоторых случаях занимает немного времени, чтобы «догнать» с последними изменениями, которые вы сделали. Убедитесь, что вы сделали полное обновление страницы и нажмите кнопку обновления в самом PageSpeed. В противном случае, с помощью Firebug на Firefox всегда кажется, дает точные результаты на вкладке сети. Нажмите на значок плюса рядом с файлом и изучить заголовки ответа.

Что такое код asp cachecontrolmaxage

Я попробовал шаг на http://www.galcho.com/Blog/post/2008/02/27/IIS7-How-to-set-cache-control-for-static-content.aspx, но безрезультатно. Я все еще получаю запросы на сервер с возвращаемыми 304.

У кого-нибудь есть способ сделать это? У меня есть сайт с интенсивной графикой, и моих пользователей (как и мой сервер) забивают каждый раз, когда они запрашивают страницу. Как ни странно, на изображениях в Firebug отображается «Cache-Control private, max-age = 3600», но браузер все еще запрашивает их, когда я нажимаю F5.

Однако вы можете поместить этот файл web.config в корень папки или сайта, где вы хотите его установить:

Это сообщит клиенту о необходимости кэширования содержимого в течение 7 дней в этой папке и во всех подпапках.

Как настроить кеширование статических файлов в asp.net?

Добрый день! Ранее с asp не работал, встала задача настроить кеширование css файлов. Нашел вот такую инструкцию:
metanit.com/sharp/mvc5/20.5.php

Делаю, как там написано, в web.config вставил

В итоге выдается ошибка 500. Подскажите, как правильно настроить кеш?

  • Вопрос задан более трёх лет назад
  • 379 просмотров

strify_25: В структуре веб-приложения должна быть папка App_Start и в ней BundleConfig. Если вы создавали проект не пустым — там что-то даже есть. К примеру такой вот код —

Это значит что на нужной view вы можете написать Styles.Render(«

/Styles/Vendors»). И это все развернется в следующую структуру — 1) если вы работаете под отладкой — вам залинкуются все css в первозданном виде для отладки.
2) в боевом режиме все css в рамках бандла объединятся и минифицируются и получится ссылка вроде Styles/Vendors? >

Основы клиентского кэширования понятными словами и на примерах. Last-modified, Etag, Expires, Cache-control: max-age и другие заголовки

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

Илон Маск рекомендует:  Что такое код xml_set_end_namespace_decl_handler

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

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

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

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

Http заголовки для управления клиентским кэшированием

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

Без кэша (при отсутствии кэширующих http-заголовков)

Как мы видим, каждый раз при отображении картинки cat.png браузер будет снова загружать ее с сервера. Думаю, не нужно объяснять, что это медленно и неэффективно.

Заголовок ответа Last-modified и заголовок запроса if-Modified-Since .

Идея заключается в том, что сервер добавляет заголовок Last-modified к файлу (ответу), который он отдает браузеру.

Теперь браузер знает, что файл был создан (или изменен) 1 декабря 2014. В следующий раз, когда браузеру понадобится тот же файл, он отправит запрос с заголовком if-Modified-Since .

Если файл не изменялся, сервер отправляет браузеру пустой ответ со статусом 304 (Not Modified) . В этом случае, браузер знает, что файл не обновлялся и может отобразить копию, которую он сохранил в прошлый раз.

Таким образом, используя Last-modified мы экономим на загрузке большого файла, отделываясь пустым быстрым ответом от сервера.

Заголовок ответа Etag и заголовок запроса If-None-Match .

Принцип работы Etag очень схож с Last-modified , но, в отличии от него, не привязан ко времени. Время – вещь относительная.

Идея заключается в том, что при создании и каждом изменении сервер помечает файл особой меткой, называемой ETag , а также добавляет заголовок к файлу (ответу), который он отдает браузеру:

Теперь браузер знает, что файл актуальной версии имеет ETag равный “686897696a7c876b7e”. В следующий раз, когда брузеру понадобится тот же файл, он отправит запрос с заголовком If-None-Match: «686897696a7c876b7e» .

Сервер может сравнить метки и, в случае, если файл не изменялся, отправить браузеру пустой ответ со статусом 304 (Not Modified) . Как и в случае с Last-modified браузер выяснит, что файл не обновлялся и сможет отобразить копию из кэша.

Подробнее о ETag можно почитать здесь.

Заголовок Expired

Принцип работы этого заголовка отличается от вышеописанных Etag и Last-modified . При помощи Expired определяется “срок годности” (“срок акуальности”) файла. Т.е. при первой загрузке сервер дает браузеру знать, что он не планирует изменять файл до наступления даты, указанной в Expired :

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

Такой вид кэша особенно актуален для иллюстраций к статьям, иконкам, фавиконкам, некоторых css и js файлов и тп.

Заголовок Cache-control с директивой max-age .

Принцип работы Cache-control: max-age очень схож с Expired . Здесь тоже определяется “срок годности” файла, но он задается в секундах и не привязан к конкретному времени, что намного удобнее в большинстве случаев.

  • 1 день = 86400 секунд
  • 1 неделя = 604800 секунд
  • 1 месяц = 2629000 секунд
  • 1 год = 31536000 секунд

У заголовка Cache-control , кроме max-age , есть и другие директивы. Давайте коротко рассмотрим наиболее популярные:

public
Дело в том, что кэшировать запросы может не только конечный клиент пользователя (браузер), но и различные промежуточные прокси, CDN-сети и тп. Так вот, директива public позволяет абсолютно любым прокси-серверам осуществлять кэширование наравне с браузером.

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

no-cache
Позволяет указать, что клиент должен делать запрос на сервер каждый раз. Иногда используется с заголовком Etag , описанным выше.

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

must-revalidate
Эта директива предписывает браузеру делать обязательный запрос на сервер для ре-валидации контента (например, если вы используете eTag). Дело в том, что http в определенной конфигурации позволяет кэшу хранить контент, который уже устарел. must-revalidate обязывает браузер при любых условиях делать проверку свежести контента путем запроса к серверу.

proxy-revalidate
Это то же, что и must-revalidate , но касается только кэширующих прокси серверов.

s-maxage
Практически не отличается от мах-age , за исключением того, что эта директива учитывается только кэшем резличных прокси, но не самим браузером пользователя. Буква “s-” исходит из слова “shared” (например, CDN). Эта директива предназначена специально для CDN-ов и других посреднических кэшей. Ее указание отменяет значения директивы max-age и заголовка Expired . Впрочем, если вы не строите CDN-сети, то s-maxage вам вряд ли когда-либо понадобится.

Как посмотреть, какие заголовки используются на сайте?

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

То-же самое можно увидеть в любом уважающем себя браузере или http-сниффере.

Настройка кэшировения в Аpache и Nginx

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

Пример конфигурации Apache для контроля Expires

Выставляем различный “срок годности” для различных типов файлов. Один год для изображений, один месяц для скриптов, стилей, pdf и иконок. Для всего остального – 2 дня.

Пример конфигурации Nginx для контроля Expires

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

Пример конфигурации Apache для Cache-control (max-age и public/private/no-cache)

Пример конфигурации Nginx для Cache-control статических файлов

В заключение

“Кэшировать все то, что можно кэшировать” – хороший девиз для веб-разработчика. Иногда можно потратить всего несколько часов на конфигурацию и при этом значительно улучшить восприятие вашего сайта пользователем, значительно сократить нагрузку на сервер и сэкономить на трафике. Главное – не переусердствовать и настроить все правильно с учетом особенностей Вашего ресурса.

Будем благодарны за рекомендации и поправки в комментариях и не забудьте поделиться статьей с друзьями, если она Вам понравилась ;)

cache-control

коротко: Я новичок, но я стараюсь лучшее, чтобы спросить прямо вперед, но, пожалуйста, постарайтесь быть прощающим со мной �� Некоторое…

im пытается сориентировать мой код, чтобы использовать кэш как можно эффективнее, используя data oriented design, its my first time thinking…

Фон: IIS 7 AspNet 3.5 веб-приложение Chrome dev tools перечисляет 98 запросов на домашнюю страницу веб-приложения (aspx + js +…

Я пытаюсь установить разумный срок действия кэша для моих файлов JS во время разработки. У меня есть стандартная настройка, где…

Я попробовал swapoff и swapon на java, но я не вижу никаких изменений с top. Вот мой код: String[] commands=…

Мне нужно отключить заголовок Etag в ответ, чтобы я мог установить Cache-control на большое значение для статического контента для веб-приложения,…

Я настроил сервер glassfish для изучения этого. После настройки и настройки в зависимости от краткого руководства, я смог запустить сервер…

Следующий код создает объект Http с включенным кэшированием: http = httplib2.Http(‘cache’) r, b = http.request(‘http://google.com’) Следующий код создает объект Http…

Мне было интересно, есть ли способ проверить, включен ли веб-сайт Cache-Controlдля типа файла и его срока действия пример для http://foo.com/foo.css…

Я уже включил заголовки, используя командуa2enmod headers, я хочу, чтобы vim это редактировало кэш-контроль позволил http no_cache, просто не знаю.htaccess,…

У меня есть href в моей странице, как: My Section когда я нажимаю на него, Chrome делает…

Я пишу веб-сервис Java для целей обучения веб-оптимизации. Мои веб-службы отправляют ответ, срок действия которого истекает через 365 дней @Path(«cache2»)…

Html-страница выглядит следующим образом: Cache-Control:no-store Connection:keep-alive Content-Encoding:gzip Content-Type:text/html Date:Tue, 04 Feb 2014 14:51:46 GMT Server:nginx/1.4.4 Transfer-Encoding:chunked

cache-control

коротко: Я новичок, но я стараюсь лучшее, чтобы спросить прямо вперед, но, пожалуйста, постарайтесь быть прощающим со мной �� Некоторое…

im пытается сориентировать мой код, чтобы использовать кэш как можно эффективнее, используя data oriented design, its my first time thinking…

Фон: IIS 7 AspNet 3.5 веб-приложение Chrome dev tools перечисляет 98 запросов на домашнюю страницу веб-приложения (aspx + js +…

Я пытаюсь установить разумный срок действия кэша для моих файлов JS во время разработки. У меня есть стандартная настройка, где…

Я попробовал swapoff и swapon на java, но я не вижу никаких изменений с top. Вот мой код: String[] commands=…

Мне нужно отключить заголовок Etag в ответ, чтобы я мог установить Cache-control на большое значение для статического контента для веб-приложения,…

Я настроил сервер glassfish для изучения этого. После настройки и настройки в зависимости от краткого руководства, я смог запустить сервер…

Следующий код создает объект Http с включенным кэшированием: http = httplib2.Http(‘cache’) r, b = http.request(‘http://google.com’) Следующий код создает объект Http…

Мне было интересно, есть ли способ проверить, включен ли веб-сайт Cache-Controlдля типа файла и его срока действия пример для http://foo.com/foo.css…

Я уже включил заголовки, используя командуa2enmod headers, я хочу, чтобы vim это редактировало кэш-контроль позволил http no_cache, просто не знаю.htaccess,…

У меня есть href в моей странице, как: My Section когда я нажимаю на него, Chrome делает…

Я пишу веб-сервис Java для целей обучения веб-оптимизации. Мои веб-службы отправляют ответ, срок действия которого истекает через 365 дней @Path(«cache2»)…

Html-страница выглядит следующим образом: Cache-Control:no-store Connection:keep-alive Content-Encoding:gzip Content-Type:text/html Date:Tue, 04 Feb 2014 14:51:46 GMT Server:nginx/1.4.4 Transfer-Encoding:chunked

Что такое код asp cachecontrolmaxage

Обновлен: Ноябрь 2007

Одним из преимуществ использования ASP.NET для размещения нескольких веб-узлов является поддержка в общеязыковой среде выполнения (CLR) управления доступом для кода в целях защиты серверных приложений. Код соотносится с классификацией по зонам безопасности на основе данных о происхождении кода, таких как строгое имя для сборки или URL-адрес исходного кода.

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

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

ASP.NET позволяет присвоить каждому приложению настраиваемый уровень доверия, который соотносится с предопределенным набором разрешений. По умолчанию приложениям назначается уровень доверия в зависимости от предоставленного ими свидетельства. Если требуется запустить веб-приложение с меньшим набором разрешений, чем Full , необходимо применять политику частичного доверия, воспользовавшись одним из предопределенных уровней доверия, заданных в файлах Уровни доверия и файлы политик ASP.NET .

Илон Маск рекомендует:  Описание HTML, DHTML, CSS, WML,...

Чтобы переопределить поведение по умолчанию и связать приложение с определенной политикой безопасности, можно использовать следующие параметры конфигурации в файле Web.config приложения:

Элемент конфигурации trust можно применять на уровне компьютера (тогда все приложения ASP.NET будут работать на этом уровне доверия) или на уровне корневого каталога какого-либо приложения в иерархии (тогда данный уровень доверия будет относиться к конкретным приложениям ASP.NET). Если требуется установить политику безопасности для всего узла, то можно сделать это путем редактирования файла Web.config корневого приложения веб-узла и указания корневого каталога веб-узла в качестве пути расположения, как в следующем примере:

Для надежных узлов рекомендуется установить атрибут level элемента конфигурации trust в значение High . Для ненадежных узлов, таких как веб-сервер, на котором размещены узлы, запускающие код от внешнего клиента, рекомендуется установить атрибут level элемента конфигурации trust в значение Medium . Подробное описание выполнения приложений ASP.NET ср средним (medium) уровнем доверия см. в разделе «Инструкции: использование среднего уровня доверия в ASP.NET 2.0» руководства Шаблоны и рекомендации по обеспечению безопасности приложений.

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

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

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

Cache-Control

  • Правила кеширования ресурса можно указать с помощью 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

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

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

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

Директивы Cache-Control Значение
max-age=86400 Ответ можно сохранить в браузере и промежуточных кешах (для него указана директива»public») на 1 день (60 секунд x 60 минут x 24 часа)
private, max-age=600 Браузер может кешировать ответ на 10 минут (60 секунд x 10 минут)
no-store Ответ нельзя кешировать. При повторном запросе нужно скачать его заново.

По данным 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 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL