читать оглавление
- 1. Основное понимание кэширования браузера
- 4. Применение сильного кеша
- 5. Принцип согласования кэша
- 6. Согласуйте управление кешем
- 7. Влияние поведения браузера на кеширование
Кэш браузера — это клиентский кеш.Это большой инструмент, оптимизированный для оптимизации веб-производительности.Это также серьезная проблема, с которой сталкиваются бесчисленные веб-разработчики в рабочем процессе, поэтому мы всегда хотим измерять их при разработке продукта.Избегайте создания кеша. , в то время как в выпуске продукта вы хотите управлять скоростью доступа к веб-странице, когда хотите управлять кешем. Понимание принципов попадания в кеш браузера является основой для разработки веб-приложений, сосредоточения внимания на этом, изучения знаний, связанных с кешем браузера, обобщения методов предотвращения кеша и управления кешем, объединения конкретных сценариев для проблем, связанных с кешем. Я надеюсь помочь нуждающимся.
1. Базовое понимание кэширования браузера
Он делится на сильный кеш и кеш согласования: 1) Когда браузер загружает ресурс, он сначала оценивает, попадает ли он в сильный кеш, по некоторым http-заголовкам ресурса.Если сильный кеш попадает, браузер напрямую считывает ресурс из собственный кеш. Запрос на сервер отправляться не будет. Например, для файла css, если конфигурация кеша файла css попадает в сильный кеш, когда браузер загружает веб-страницу, на которой он находится, браузер напрямую загружает css из кеша, и даже запрос не будет отправляется на сервер, где находится веб-страница;
2) Когда сильный кеш не попадает, браузер обязательно отправит запрос на сервер, и сервер проверит, попадает ли ресурс в согласованный кеш в соответствии с другими HTTP-заголовками ресурса. вернет запрос, но не вернет данные этого ресурса, а сообщит клиенту, что ресурс можно загрузить прямо из кеша, поэтому браузер загрузит ресурс из своего кеша;
3) Общим моментом между сильным кешем и кешем согласования является то, что при попадании ресурс загружается из клиентского кеша вместо данных ресурса с сервера, отличие состоит в том, что сильный кеш не отправляет запросы на сервер, а кэш согласования будет отправлять запросы на сервер.
4) Когда согласованный кеш не срабатывает, браузер загружает данные ресурсов непосредственно с сервера.
2. Принцип сильного кеша
Когда запрос браузера на ресурс попадает в сильный кеш, возвращаемый статус http равен 200, а размер будет отображаться как из кеша в сети инструментов разработчика Chrome.Например, на домашней странице Jingdong есть много конфигураций статических ресурсов. Сильный кеш, откройте его несколько раз с помощью хрома, а затем используйте f12 для просмотра сети, вы можете видеть, что многие запросы загружаются из кеша:
Сильное кэширование реализовано с использованием двух заголовков ответа HTTP, Expires или Cache-Control, которые оба используются для указания срока действия ресурсов, кэшированных на стороне клиента.
Expires – это заголовок, предложенный http1.0 и представляющий время истечения срока действия ресурсов. Он описывает абсолютное время, возвращаемое сервером, и представляется в виде строки в формате GMT, например: Expires:Thu, 31 Dec 2037 23:55: 55 GMT, его принцип кэширования:
1) Браузер запрашивает ресурс у сервера в первый раз, когда сервер возвращает ресурс, он добавляет заголовок Expires к заголовку ответа, например:
2) После того, как браузер получит ресурс, он будет кэшировать ресурс вместе со всеми заголовками ответа (поэтому заголовок, возвращаемый запросом на попадание в кеш, исходит не от сервера, а из ранее кэшированного заголовка);
3) Когда браузер снова запрашивает ресурс, он сначала будет искать из кеша.Найдя ресурс, вынуть его Expires и сравнить его с текущим временем запроса.Если время запроса раньше времени, указанного Expires, он может попал в кеш, иначе попадет в кеш.
4) Если кеш не попал, когда браузер загружает ресурс напрямую с сервера, заголовок Expires будет обновляться при перезагрузке.
Expires — это старый заголовок управления кешем. Поскольку это абсолютное время, возвращаемое сервером, когда время сервера и время клиента сильно различаются, управление кешем подвержено проблемам. Например, если время клиента произвольно изменено. , это может повлиять на кэш результата попадания. Поэтому в http1.1 был предложен новый заголовок, который Cache-Control.Это относительное время.При настройке кеша оно выражается в секундах и числовыми значениями, такими как: Cache-Control:max-age= 315360000, его принцип кэширования:
1) Браузер впервые запрашивает ресурс у сервера, когда сервер возвращает ресурс, он добавляет в заголовок ответа заголовок Cache-Control, например:
2) После того, как браузер получит ресурс, он кэширует ресурс вместе со всеми заголовками ответа;
3. Время истечения срока. По сравнению с текущим временем запроса, если время запроса до истечения срока действия, кэш может быть ударен, в противном случае он не будет работать.
4) При промахе кеша браузер загружается из ресурсов сервера, Cache-Control Header обновляется прямо при перезагрузке.
Вышеизложенный принцип сильного кэширования.В практических приложениях мы столкнемся со сценариями, требующими сильного кэширования, и сценариями, не требующими сильного кэширования.Обычно есть два способа установить, следует ли включать сильное кэширование:
1) Добавить Expires и Cache-Control Header в ответ, возвращаемый веб-сервером, с помощью кода;
2) Настроив веб-сервер, позвольте веб-серверу единообразно добавлять Expires и Cache-Control Header при ответе на ресурсы.
Например, в javaweb мы можем использовать следующий код для настройки надежного кэширования:
java.util.Date date = new java.util.Date();
response.setDateHeader("Expires",date.getTime()+20000); //Expires:过时期限值
response.setHeader("Cache-Control", "public"); //Cache-Control来控制页面的缓存与否,public:浏览器和缓存服务器都可以缓存页面信息；
response.setHeader("Pragma", "Pragma"); //Pragma:设置页面是否缓存，为Pragma则缓存，no-cache则不缓存Вы также можете отключить строгое кэширование, установив код Java следующим образом:
response.setHeader( "Pragma", "no-cache" );
response.setDateHeader("Expires", 0);
response.addHeader( "Cache-Control", "no-cache" );//浏览器和缓存服务器都不应该缓存页面信息Tomcat также предоставляет ExpiresFilter, специально используемый для настройки надежного кэширования.Подробности см. в официальной документации tomcat:tomcat.apache.org/tomcat-7.0-…
Как профессиональные веб-серверы, nginx и apache имеют специальные файлы конфигурации, которые могут настроить истечение срока действия и контроль кеша.Для получения этих знаний, если вы заинтересованы в эксплуатации и обслуживании, вы можете выполнить поиск «nginx set expires cache-control» на Baidu "или «Настройка apache истекает с контролем кеша» можно найти во многих связанных статьях.
Поскольку сильное кэширование специально не настраивается при разработке, а браузер по умолчанию кэширует статические ресурсы, такие как картинки, css и js, в среде разработки ресурсы часто не обновляются вовремя из-за сильного кэширования, и последние эффекты не видны ., есть много способов решить эту проблему, наиболее часто используемые из них следующие:
1) Прямой ctrl+f5, этот метод может решить проблему обновления ресурсов, на которые непосредственно ссылается страница;
2) Используйте режим конфиденциальности браузера для разработки;
3) Если вы используете хром, вы можете отключить кэш в сети с помощью f12 (это очень эффективный метод):
4) На этапе разработки добавьте к ресурсу динамический параметр, такой как css/index.css?v=0.0001, потому что каждая модификация ресурса должна обновлять ссылочное местоположение и изменять значение параметра, поэтому это не очень просто Удобно, если вы не разрабатываете динамические страницы, такие как jsp, вы можете использовать серверные переменные для решения (v=${sysRnd}) или вы можете использовать некоторые инструменты внешнего интерфейса для решения этой проблемы изменения параметров;
5) Если страница, на которую ссылается ресурс, встроена в iframe, вы можете щелкнуть правой кнопкой мыши в области iframe, чтобы перезагрузить страницу, взяв в качестве примера хром:
6) Если проблема с кешем возникает в ajax-запросе, наиболее эффективным решением является добавление случайного числа к адресу ajax-запроса;
7) Другая ситуация заключается в том, что когда src для iframe устанавливается динамически, последний эффект может быть не виден из-за проблемы с кешем.В это время добавление случайного числа после устанавливаемого src также может решить проблему;
8) Если вы используете интерфейсную разработку Grunt и Glp, запустите статический сервер через свой плагин, такие как Grunt-Connect, полностью не нужно беспокоиться о проблеме обновления ресурсов в этапе разработки, Поскольку под этим статическим сервером в отдовом заголовок, возвращаемом всеми ресурсами, Cache-Control всегда устанавливается не кэш:
4. Применение сильного кеша
Cache strong front-end оптимизация производительности является самым мощным инструментом, а не одним из них, для большого количества статических веб-ресурсов, обязательно воспользуйтесь преимуществами сильного кэширования для повышения скорости отклика. Обычной практикой для всех этих статических ресурсов является конфигурация с длительным временем ожидания Expires или Cache-Control, так что, когда пользователи обращаются к веб-странице, запрашивают только статические ресурсы с сервера при первой загрузке, в других случаях до тех пор, пока буфер не выходит из строя и будет в условиях, когда пользователь не принудительно обновляет загрузку из собственного кеша, такого как ранее упомянутый домашний кэшированный ресурс Jingdong, срок действия его кеша установлен на 2026:
Однако такой способ настройки кеша приведет к новой проблеме, а именно к проблеме обновления ресурсов при публикации.Например, определенное изображение было кэшировано на компьютере пользователя, когда пользователь обращается к первой версии.Когда веб-сайт публикует новую версию , когда это изображение заменяется, пользователи, получившие доступ к первой версии, не будут запрашивать последние ресурсы изображения с сервера по умолчанию из-за настроек кеша, если они не очистят или не отключат кеш или принудительно обновят, в противном случае см. Не последнее изображение эффект.
Уже есть зрелые решения этой проблемы, подробнее читайте в этой статье на Zhihu:
Вещи, упомянутые в статье, являются теоретическими решениями, но теперь есть много интерфейсных инструментов, которые могут действительно решить эту проблему. Поскольку каждый инструмент включает в себя много деталей, эта статья не имеет способа представить их один за другим. Если вы заинтересованы, вы можете узнать о инструментах Grunt Gulp Webpack FIS и EDP. Эти инструменты могут решить эту проблему, особенно FIS и EDP - это передние платформы разработки, запущенные Baidu. Есть готовые документы для справки:
FI да Baidu .com / FI 3 / API / в ...
Сильные буфеты все еще должны отметить, что обычно используется для статического ресурса, динамические ресурсы должны быть осторожны, в дополнение к странице сервера можно рассматривать как динамические ресурсы, те HTMLS, которые ссылаются на статические ресурсы, также можно рассматривать как динамические ресурсы, если Этот HTML также кэшируется. После этих обновлений HTML нет механизмов уведомления о браузере, что эти HTMLS обновляются, особенно передние задние отделения, страница представляет собой Pure Page HTML, каждый адрес доступа может быть прямым доступом HTML-страница, которая обычно не улучшает кэш, чтобы убедиться, что браузер всегда запросил последние ресурсы, которые будут запрошены, когда браузер имеет доступ к этим страницам.
5. Принцип согласования кэша
Когда запрос браузера о ресурсе не попадает в сильный кеш, он отправляет запрос на сервер, чтобы проверить, попал ли кеш согласования. Будет отображаться измененная строка. Например, если вы откроете домашнюю страницу JD.com, нажмите F12, чтобы открыть инструменты разработчика, затем нажмите F5, чтобы обновить страницу, и проверьте сеть, вы увидите, что многие запросы попадают в кеш согласования. :
Глядя на заголовок ответа одного запроса, вы также можете увидеть код состояния 304 и строку Not Modified. Пока вы видите это, это означает, что ресурс попадает в согласованный кеш и загружается из кеша клиента, а не последний сервер.ресурс:
Кэш согласования управляется двумя парами заголовков [Last-Modified, If-Modified-Since] и [ETag, If-None-Match].
Принцип управления кэшем [Last-Modified, If-Modified-Since]:
1) Браузер впервые запрашивает ресурс у сервера, когда сервер возвращает ресурс, он добавляет в заголовок ответа заголовок Last-Modified, который указывает время последней модификации ресурса на сервере:
2) Когда браузер снова запрашивает этот ресурс с сервера, он добавляет в заголовок запроса заголовок If-Modified-Since, значением этого заголовка является значение Last-Modified, возвращенное в предыдущем запросе:
3) Когда сервер снова получит запрос ресурса, он оценит, изменился ли ресурс в соответствии с If-Modified-Since, отправленным браузером, и временем последней модификации ресурса на сервере.Если изменений нет, 304 Не изменено будет возвращено, но содержимое ресурса не будет возвращено; если есть изменение, вернуть содержимое ресурса в обычном режиме. Когда сервер возвращает ответ 304 Not Modified, заголовок Last-Modified не будет добавлен к заголовку ответа, потому что, поскольку ресурс не изменился, Last-Modified не изменится.Это заголовок ответа, когда сервер возвращает 304. :
4) После того, как браузер получил ответ 304, он загружает ресурс из кеша.
5) Если кеш согласования не попал, когда браузер загружает ресурс непосредственно с сервера, заголовок Last-Modified будет обновлен при перезагрузке, а If-Modified-Since включит последнее возвращенное значение Last-Modified в следующий запрос.
Корпус [Последнее модифицированное, если для возврата сервера, поскольку Header] основаны на сервере времени для возврата, в целом нет времени настроить сервер и кэш клиентского кэша вмешательства, а вместе два заголовка является очень надежным консультациями управления кэшем, но Иногда есть ресурсы на сервере фактически изменится, но последнее изменение времени не изменило ситуацию, и эта проблема была нелегко размещена, а когда это произойдет, это повлияет на надежность кэша переговоров. Таким образом, будет другая пара консультации по управлению кешем заголовка, что является заголовочным заголовком [Etag, если-не совпадает]. Их подход для управления кэшем:
1) Браузер впервые запрашивает ресурс у сервера.Когда сервер возвращает ресурс, он добавляет заголовок ETag к заголовку ответа.Этот заголовок представляет собой уникальный идентификатор, сгенерированный сервером на основе текущего запрошенного ресурса. уникальный идентификатор - это строка, поскольку ресурс изменяется, строка отличается и не имеет ничего общего со временем последней модификации, поэтому она может очень хорошо дополнить проблему Last-Modified:
2) Когда браузер снова запросит ресурс с сервера, он добавляет заголовок IF-None-Match на заголовок запроса. Значение этого заголовка - это значение Etag, возвращаемое в предыдущем запросе:
3) Когда сервер снова получит запрос ресурса, он сгенерирует новый ETag в соответствии с If-None-Match и ресурсом в соответствии с браузером.Если эти два значения совпадают, это означает, что ресурс не изменено, иначе будет изменение; если нет Если есть изменение, будет возвращено 304 Not Modified, но содержимое ресурса не будет возвращено; если есть изменение, содержимое ресурса будет возвращено в обычном режиме. В отличие от Last-Modified, когда сервер возвращает ответ 304 Not Modified, поскольку ETag был перегенерирован, ETag будет возвращен в заголовке ответа, даже если ETag не изменился по сравнению с предыдущим:
4) После того, как браузер получил ответ 304, он загружает ресурс из кеша.
6. Согласуйте управление кешем
Кэш согласования отличается от сильного кеша.Сильный кеш не отправляет запросы на сервер, поэтому иногда браузер не знает, обновлен ли ресурс, но кеш согласования отправляет запрос на сервер, поэтому сервер должен знать, обновляется ли ресурс. Большинство веб-серверов включают кеш согласования по умолчанию и одновременно включают [Last-Modified, If-Modified-Since] и [ETag, If-None-Match], например apache:
Если кеш не согласован, каждый запрос к серверу должен возвращать содержимое ресурса, поэтому производительность сервера будет крайне низкой.
[Last-Modified, If-Modified-Since] и [ETag, If-None-Match] обычно включаются одновременно, это связано с ненадежностью Last-Modified. Есть один сценарий, о котором следует знать:
Last-Modified файлов между несколькими машинами в распределенной системе должен быть согласованным, чтобы избежать балансировки нагрузки на разные машины и привести к сбою сравнения;
Распределенная система должна попытаться закрыть ETag (ETag, генерируемый каждой машиной, будет разным);
Для запроса ресурса страницы Jingdong возвращенный заголовок repsones имеет значение Last-Modified и отсутствует ETag:
Кэш согласования нужно использовать вместе с сильным кешем.Как видно на предыдущем снимке экрана, помимо заголовка Last-Modified, есть еще заголовки, относящиеся к сильному кешу, потому что если сильный кеш не включен , кеш согласования вообще бессмысленный.
7. Влияние поведения браузера на кеширование
Если ресурс был закэширован браузером, до того, как кеш станет недействительным, при повторном запросе он проверит, не попал ли в сильный кеш по умолчанию. не попал, запрос будет отправлен на сервер, чтобы проверить, попал ли он. Согласовать кеш. Если согласованный кеш попадает, сообщите браузеру, что он все еще может читать из кеша, иначе с сервера будет возвращен последний ресурс . Это обработка по умолчанию, которая может быть изменена поведением браузера:
1) Когда ctrl+f5 принудительно обновляет веб-страницу, она загружается напрямую с сервера, минуя сильный кеш и кеш согласования;
2) Когда f5 обновляет веб-страницу, сильный кеш пропускается, но проверяется согласованный кеш;
Спасибо за чтение :) Надеюсь, что содержимое этой статьи может помочь вам ~
Если вы считаете, что эта статья полезна для вас, пожалуйста, поставьте мне палец вверх, или сделайте мне комплимент в комментариях.Маленькие достижения - это мотивация продолжать писать качественные статьи для всех в будущем.Спасибо! Вы можете продолжать следить за моим блогом :) Автор:Лююн ЧжугэИсточник:www.cnblogs.com/lyzg/Все права защищены, пожалуйста, сохраните исходную ссылку для перепечатки :)