Кэширование стилей. Как убрать кэширование css и js файлов. Обновление страницы иногда спасает
Подключая внешние CSS и Javascript, мы хотим снизить до минимума лишние HTTP-запросы.
Для этого.js и.css файлы отдаются с заголовками, обеспечивающими надежное кеширование.
Но что делать, когда какой-то из этих файлов меняется в процессе разработки? У всех пользователей в кеше старый вариант - пока кеш не устарел, придет масса жалоб на сломанную интеграцию серверной и клиентской части.
Правильный способ кеширования и версионности полностью избавляет от этой проблемы и обеспечивает надежную, прозрачную синхронизацию версий стиля/скрипта.
Простое кеширование ETagСамый простой способ кеширования статических ресурсов - использование ETag .
Достаточно включить соответствующую настройку сервера (для Apache включена по умолчанию) - и к каждому файлу в заголовках будет даваться ETag - хеш, который зависит от времени обновления, размера файла и (на inode-based файловых системах) inode.
Браузер кеширует такой файл и при последующих запросах указывет заголовок If-None-Match с ETag кешированного документа. Получив такой заголовок, сервер может ответить кодом 304 - и тогда документ будет взят из кеша.
Выглядит это так:
Первый запрос к серверу (кеш чистый) GET /misc/pack.js HTTP/1.1 Host: сайт
Вообще, браузер обычно добавляет еще пачку заголовоков типа User-Agent, Accept и т.п. Для краткости они порезаны.
Ответ сервера Сервер посылает в ответ документ c кодом 200 и ETag: HTTP/1.x 200 OK Content-Encoding: gzip Content-Type: text/javascript; charset=utf-8 Etag: "3272221997" Accept-Ranges: bytes Content-Length: 23321 Date: Fri, 02 May 2008 17:22:46 GMT Server: lighttpd Следующий запрос браузера При следующем запросе браузер добавляет If-None-Match: (кешированный ETag): GET /misc/pack.js HTTP/1.1 Host: сайт If-None-Match: "453700005" Ответ сервера Сервер смотрит - ага, документ не изменился. Значит можно выдать код 304 и не посылать документ заново. HTTP/1.x 304 Not Modified Content-Encoding: gzip Etag: "453700005" Content-Type: text/javascript; charset=utf-8 Accept-Ranges: bytes Date: Tue, 15 Apr 2008 10:17:11 GMT
Альтернативный вариант - если документ изменился, тогда сервер просто посылает 200 с новым ETag .
Аналогичным образом работает связка Last-Modified + If-Modified-Since:
Эти способы работают стабильно и хорошо, но браузеру в любом случае приходится делать по запросу для каждого скрипта или стиля.
Умное кеширование. ВерсионностьОбщий подход для версионности - в двух словах:
Жесткое кеширование - своего рода кувалда которая полностью прибивает запросы к серверу для кешированных документов.
Для этого достаточно добавить заголовки Expires и Cache-Control: max-age.
Например, чтобы закешировать на 365 дней в PHP:
Header("Expires: ".gmdate("D, d M Y H:i:s", time()+86400*365)." GMT"); header("Cache-Control: max-age="+86400*365);
Или можно закешировать контент надолго, используя mod_header в Apache:
Получив такие заголовки, браузер жестко закеширует документ надолго. Все дальнейшие обращения к документу будут напрямую обслуживаться из кеша браузера, без обращения к серверу.
Большинство браузеров (Opera, Internet Explorer 6+, Safari) НЕ кешируют документы, если в адресе есть вопросительный знак, т.к считают их динамическими.
Именно поэтому мы добавляем версию в имя файла. Конечно, с такими адресами приходится использовать решение типа mod_rewrite, мы это рассмотрим дальше в статье.
P.S А вот Firefox кеширует адреса с вопросительными знаками..
Автоматическое преобразование именРазберем, как автоматически и прозрачно менять версии, не переименовывая при этом сами файлы.
Имя с версией -> ФайлСамое простое - это превратить имя с версией в оригинальное имя файла.
На уровне Apache это можно сделать mod_rewrite:
RewriteEngine on RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 [L]
Такое правило обрабатывает все css/js/gif/png/jpg-файлы, вырезая из имени версию.
Например:
/images/logo.v2.gif -> /images/logo.gif
/css/style.v1.27.css -> /css/style.css
/javascript/script.v6.js -> /javascript/script.js
Но кроме вырезания версии - надо еще добавлять заголовки жесткого кеширования к файлам. Для этого используются директивы mod_header:
Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT" Header add "Cache-Control" "max-age=315360000"
А все вместе реализует вот такой апачевый конфиг:
RewriteEngine on # убирает версию, и заодно ставит переменную что файл версионный RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 # жестко кешируем версионные файлы Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT" env=VERSIONED_FILE Header add "Cache-Control" "max-age=315360000" env=VERSIONED_FILE
Из-за порядка работы модуля mod_rewrite, RewriteRule нужно поставить в основной конфигурационный файл httpd.conf или в подключаемые к нему(include) файлы, но ни в коем случае не в.htaccess , иначе команды Header будут запущены первыми, до того, как установлена переменная VERSIONED_FILE .
Директивы Header могут быть где угодно, даже в.htaccess - без разницы.
Автоматическое добавление версии в имя файла на HTML-страницеКак ставить версию в имя скрипта - зависит от Вашей шаблонной системы и, вообще, способа добавлять скрипты (стили и т.п.).
Например, при использовании даты модификации в качестве версии и шаблонизатора Smarty - ссылки можно ставить так:
Функция version добавляет версию:
Function smarty_version($args){ $stat = stat($GLOBALS["config"]["site_root"].$args["src"]); $version = $stat["mtime"]; echo preg_replace("!\.(+?)$!", ".v$version.\$1", $args["src"]); }
Результат на странице:
Оптимизация
Чтобы избежать лишних вызовов stat , можно хранить массив со списком текущих версий в отдельной переменной
$versions["css"] = array("group.css" => "1.1", "other.css" => "3.0", }
В этом случае в HTML просто подставляется текущая версия из массива.
Можно скрестить оба подхода, и выдавать во время разработки версию по дате модификации - для актуальности, а в продакшн - версию из массива, для производительности.
ПрименимостьТакой способ кеширования работает везде, включая Javascript, CSS, изображения, flash-ролики и т.п.
Он полезен всегда, когда документ изменяется, но в браузере всегда должна быть текущая актуальная версия.
Правильно настроенное кэширование дает огромный выигрыш в производительности, экономит трафик и уменьшает затраты на сервер, однако на многих сайтах кэширование реализовано неудачно, что создает состояние гонки , приводящее к рассинхронизации взаимосвязанных ресурсов.
Подавляющее большинство лучших практик кэширования относится к одному из двух паттернов:
Паттерн №1: неизменяемый контент и долгий max-age кэша Cache-Control: max-age=31536000- Содержимое по URL не меняется, следовательно…
- Браузер или CDN могут без проблем закэшировать ресурс на год
- Закэшированный контент, который младше, чем заданный max-age может использоваться без консультации с сервером
Страница: Эй, мне нужны "/script-v1.js" , "/styles-v1.css" и "/cats-v1.jpg" 10:24
Кэш: У меня пусто, как насчет тебя, Сервер? 10:24
Сервер: ОК, вот они. Кстати, Кэш, их стоит использовать в течение года, не больше. 10:25
Кэш: Спс! 10:25
Страница: Ура! 10:25
Следующий день
Страница: Эй, мне нужны "/script-v2 .js" , "/styles-v2 .css" и "/cats-v1.jpg" 08:14
Кэш: Картинка с котиками есть, остального нет. Сервер? 08:14
Сервер: Легко - вот новые CSS & JS. Еще раз, Кэш: их срок годности не больше года. 08:15
Кэш: Супер! 08:15
Страница: Спасибо! 08:15
Кэш: Хм, я не пользовался "/script-v1.js" & "/styles-v1.css" достаточно долго. Пора их удалять. 12:32
Используя этот паттерн, вы никогда не меняете контент определенного URL, вы меняете сам URL:
В каждом URL есть что-то, меняющееся одновременно с контентом. Это может быть номер версии, модифицированная дата или хэш контента (этот вариант я и выбрал для своего блога).
В большинстве серверных фреймворков есть инструменты, позволяющие с легкостью делать подобные вещи (в Django я использую ManifestStaticFilesStorage); есть также совсем небольшие библиотеки в Node.js, решающие те же задачи, например, gulp-rev .
Однако этот паттерн не подходит для вещей типа статей и записей в блогах. Их URL нельзя версионировать, а их содержимое может измениться. Серьезно, у меня часто бывают грамматические и пунктуационные ошибки, в связи с чем нужна возможность быстрого обновления содержимого.
Паттерн №2: изменяемый контент, всегда проходящий ревалидацию на сервере Cache-Control: no-cache- Содержимое URL изменится, значит…
- Любая локальная закэшированная версия не может использоваться без указания сервера.
Страница: Эй, мне нужно содержимое "/about/" и "/sw.js" 11:32
Кэш: Ничем не могу помочь. Сервер? 11:32
Сервер: Есть такие. Кэш, держи их при себе, но перед использованием спрашивай у меня. 11:33
Кэш: Так точно! 11:33
Страница: Спс! 11:33
На следующий день
Страница: Эй, мне опять нужно содержимое "/about/" и "/sw.js" 09:46
Кэш: Минутку. Сервер, с моими копиями все в порядке? Копия "/about/" лежит с понедельника, а "/sw.js" вчерашняя. 09:46
Сервер: "/sw.js" не менялась… 09:47
Кэш: Круто. Страница, держи "/sw.js" . 09:47
Сервер: …но "/about/" у меня новой версии. Кэш, держи ее, но как и в прошлый раз, не забудь сначала спросить меня. 09:47
Кэш: Понял! 09:47
Страница: Отлично! 09:47
Примечание: no-cache не значит “не кэшировать”, это значит “проверять” (или ревалидировать) закэшированный ресурс у сервера. А не кэшировать совсем браузеру приказывает no-store . Также и must-revalidate означает не обязательную ревалидацию, а то, что закэшированный ресурс используется только, если он младше, чем заданный max-age , и только в ином случае он ревалидируется. Вот так все запущено с ключевыми словами для кэширования.
В этом паттерне мы можете добавить к ответу ETag (идентификатор версии на ваш выбор) или заголовок Last-Modified . При следующем запросе содержимого со стороны клиента, выводится If-None-Match или If-Modified-Since соответственно, позволяя серверу сказать “Используй то, что у тебя есть, твой кэш актуален”, то есть вернуть HTTP 304.
Если отправка ETag / Last-Modified невозможна, сервер всегда отсылает содержимое полностью.
Этот паттерн всегда всегда требует обращений к сети, поэтому он не столь хорош, как первый паттерн, который может обходится без сетевых запросов.
Это не редкость, когда у нас нет инфраструктуры для первого паттерна, но точно также могут возникнуть проблемы с сетевыми запросами в паттерне 2. В итоге используется промежуточный вариант: короткий max-age и изменяемый контент. Это плохой компромисс.
Использование max-age с изменяемым контентом это, как правило, неправильный выборИ, к сожалению, он распространен, в качестве примера можно привести Github pages.
Представьте:
- /article/
- /styles.css
- /script.js
С серверным заголовком:
Cache-Control: must-revalidate, max-age=600
- Содержимое URL меняется
- Если в браузере есть кэшированная версия свежее 10 минут, она используется без консультации с сервером
- Если такого кэша нет, используется запрос к сети, по возможности с If- Modified-Since или If-None-Match
Страница: Эй, мне нужны "/article/" , "/script.js" и "/styles.css" 10:21
Кэш: У меня ничего нет, как у тебя, Сервер? 10:21
Сервер: Без проблем, вот они. Но запомни, Кэш: их можно использовать в течение ближайших 10 минут. 10:22
Кэш: Есть! 10:22
Страница: Спс! 10:22
Страница: Эй, мне опять нужны "/article/" , "/script.js" и "/styles.css" 10:28
Кэш: Упс, я извиняюсь, но я потерял "/styles.css" , но все остальное у меня есть, держи. Сервер, можешь подогнать мне "/styles.css" ? 10:28
Сервер: Легко, он уже изменился с тех пор, как ты в прошлый раз забирал его. Ближайшие 10 минут можешь смело его использовать. 10:29
Кэш: Без проблем. 10:29
Страница: Спасибо! Но, кажется, что-то пошло не так! Все поломалось! Что, вообще, происходит? 10:29
Этот паттерн имеет право на жизнь при тестировании, но ломает все в реальном проекте и его очень сложно отслеживать. В примере выше, сервер обновил HTML, CSS и JS, но выведена страница со старыми HTML и JS из кэша, к которым добавлен обновленный CSS с сервера. Несовпадение версий все портит.
Часто при внесении значительных изменений в HTML, мы меняем и CSS, для правильного отражения новой структуры, и JavaScript, чтобы и он не отставал от контента и стилей. Все эти ресурсы независимы, но заголовки кэширования не могут выразить это. В итоге у пользователей может оказаться последняя версия одного/двух ресурсов и старая версия остальных.
max-age задается относительно времени ответа, поэтому если все ресурсы передаются как часть одного адреса, их срок истечет одновременно, но и здесь сохраняется небольшой шанс рассинхронизации. Если у вас есть страницы, не включающие JavaScript или включающие другие стили, сроки годности их кэша будут рассинхронизированы. И хуже того, браузер постоянно вытаскивает содержимое из кэша, не зная, что HTML, CSS, & JS взаимозависимы, поэтому он с радостью может вытащить что-то одно из списка и забыть про все остальное. Учитывая все эти факторы вместе, вы должны понять, что вероятность появления несовпадающих версий достаточно велика.
Для пользователя результатом может быть сломанная раскладка страницы или иные проблемы. От небольших глюков до совершенно непригодного контента.
К счастью, у пользователей есть запасной выход…
Обновление страницы иногда спасаетЕсли страница загружена путем обновления, браузеры всегда проводят серверную ревалидацию, игнорируя max-age . Поэтому, если у пользователя что-то поломалось вследствие max-age , простое обновление страницы может все исправить. Но, разумеется, после того как ложки найдутся, осадок все равно останется и отношение к вашему сайту будет несколько иным.
Сервис-воркер может продлить жизнь этих баговНапример, у вас есть такой сервис-воркер:
Const version = "2"; self.addEventListener("install", event => { event.waitUntil(caches.open(`static-${version}`) .then(cache => cache.addAll([ "/styles.css", "/script.js" ]))); }); self.addEventListener("activate", event => { // …delete old caches… }); self.addEventListener("fetch", event => { event.respondWith(caches.match(event.request) .then(response => response || fetch(event.request))); });
Этот сервис-воркер:
- кэширует скрипт и стили
- использует кэш при совпадении, иначе обращается к сети
Если мы меняем CSS/JS, мы также увеличиваем номер version , что инициирует обновление. Однако, так как addAll обращается сначала к кэшу, мы можем попасть в состояние гонки из-за max-age и несоответствующих версий CSS & JS.
После того как они закэшированы, у нас будут несовместимые CSS & JS до следующего обновления сервис-воркера - и это если мы опять не попадем при обновлении в состояние гонки.
Вы можете пропустить кэширование в сервис-воркере:
Self.addEventListener("install", event => { event.waitUntil(caches.open(`static-${version}`) .then(cache => cache.addAll([ new Request("/styles.css", { cache: "no-cache" }), new Request("/script.js", { cache: "no-cache" }) ]))); });
К сожалению, опции для кэширования не поддерживаются в Chrome/Opera и только-только добавлены в ночную сборку Firefox , но вы можете сделать это самостоятельно:
Self.addEventListener("install", event => { event.waitUntil(caches.open(`static-${version}`) .then(cache => Promise.all([ "/styles.css", "/script.js" ].map(url => { // cache-bust using a random query string return fetch(`${url}?${Math.random()}`).then(response => { // fail on 404, 500 etc if (!response.ok) throw Error("Not ok"); return cache.put(url, response); }) })))); });
В этом примере, я сбрасываю кэш с помощью случайного числа, но вы можете пойти дальше и добавлять хэш контента при сборке (это похоже на то, что делает sw-precache). Это своего рода реализация первого паттерна с помощью JavaScript, но работающая только с сервис-воркером, а не браузерами и CDN.
Сервис-воркеры и HTTP-кэш отлично работают вместе, не заставляйте их воевать!Как видите, вы можете обойти ошибки с кэшированием в вашем сервис-воркере, но правильней будет решить корень проблемы. Правильная настройка кэширования не только облегчает работу сервис-воркера, но и помогает браузерам, не поддерживающим сервис-воркеры (Safari, IE/Edge), а также позволяет вам извлечь максимум из вашей CDN.
Правильные заголовки кэширования также могут значительно упростить обновление сервис-воркера.
Const version = "23"; self.addEventListener("install", event => { event.waitUntil(caches.open(`static-${version}`) .then(cache => cache.addAll([ "/", "/script-f93bca2c.js", "/styles-a837cb1e.css", "/cats-0e9a2ef4.jpg" ]))); });
Здесь я закэшировал корневую страницу с паттерном №2 (серверная ревалидация) и все остальные ресурсы с паттерном №1 (неизменяемый контент). Каждое обновление сервис-воркера будет вызывать запрос к корневой странице, а все остальные ресурсы будут загружаться только, если их URL изменился. Это хорошо тем, что сохраняет трафик и улучшает производительность, независимо от того, обновляетесь ли вы с предыдущей или очень старой версии.
Здесь есть значительное преимущество над нативной реализацией, когда целый бинарник скачивается даже при небольшом изменении или вызывает комплексное сравнение двоичных файлов. Так мы можем обновить большое веб-приложение при сравнительно небольшой загрузке.
Сервис-воркеры работают лучше в качестве улучшения, а не временного костыля, поэтому работайте с кэшем вместо того, чтобы воевать с ним.
При аккуратном использовании max-age и изменяемый контент могут быть очень хорошиmax-age очень часто бывает неправильным выбором для изменяемого контента, но не всегда. Например, у оригинала статьи max-age составляет три минуты. Состояние гонки не является проблемой, так как на странице нет зависимостей, использующих одинаковый паттерн кэширования (CSS, JS & изображения используют паттерн №1 - неизменяемый контент), все остальное этот паттерн не использует.
Этот паттерн означает, что я спокойно пишу популярную статью, а мой CDN (Cloudflare) может снять нагрузку с сервера, если, конечно, я готов подождать три минуты, пока обновленная статья станет доступной пользователям.
Этот паттерн надо использовать без фанатизма. Если я добавил новый раздел в статью, и поставил на него ссылку с другой статьи, я создал зависимость, которую надо разрешать. Пользователь может кликнуть на ссылку и получить копию статьи без искомого раздела. Если я хочу избежать этого, я должен обновить статью, удалить кэшированный вариант статьи с Cloudflare, подождать три минуты и только после этого добавлять ссылку в другую статью. Да, этот паттерн требует осторожности.
При правильном использовании кэширование дает значительное улучшение производительности и экономию трафика. Передавайте неизменяемый контент, если вы можете легко изменить URL, или используйте серверную ревалидацию. Смешивайте max-age и изменяемый контент, если вы достаточно смелы и уверены, что у вашего контента нет зависимостей, которые могут рассинхронизироваться.
Многие думают, что по умолчанию CSS файлы, подключаемые через link или @import - не кэшируются. Вынужден вас разочаровать. Как раз именно css, вынесенные в отдельный файл кэшируются, причем очень хорошо, я бы сказал отлично. Эта информация достоверно проверено как на 6 и выше и других браузерах. Стоит отметить, что многими любимая кэшируется такие файлы совсем с дикой скоростью, так сказать получает первое место за это дело. Кстати во многом именно этому механизму Opera имеет во многих случаях существенную скорость по сравнению с другими браузерами. Но сразу оговорюсь, что именно эта «супер» кэширование в Opera с ней злую шутки при использовании технологии AJAX. В то время как другие при использовании AJAX вносят изменения чики пуки, Opera берет старое. Но это песня отдельной темы.
Кэширование CSSНО! Бывают все-таки у некоторых горе проблемы в этом направлении. Это связанно, как правило, с неправильным настроенным Apache сервером, который выдает не совсем корректные заголовки. А при помощи заголовком можно управлять кэшированием файлов. По умолчанию, конечно же, кэш включен всегда. Но бывают случаи, когда кэшировать файлы не нужно. Для этого и уже профи начинают танцы с бубнами по поводу HTTP заголовков. Но если вы полностью читаете эту статью, то вам еще очень далеко до управления HTTP заголовками. Уверяю вас, что в ближайшее время вы с такой задачей не столкнетесь. И все же, если вы любопытны до глубины души, то вкратце расскажу как это происходит.
Ну а теперь если не утомил, то немного научной белиберды от некоторого своего рода эксперимента.
Сразу скажу нижний текст новичкам в WEB будет слабо понятен. В основном это полезно будет тем, кто столкнулся все-таки с задачами отключения и включения кэш.
Все эксперименты проводились на реальном, платном. У хорошего так сказать хостера, который позволяет изменять структуру HTTP заголовков, не имея параной, что его по HTTP заголовку взломают:)
Режимы браузеровИтак, у любого браузера есть 2 режима :
1. Режим по умолчанию , возвращаемый заголовок:
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
2. Режим с включенным кешированием , возвращаемый заголовок:
Cache-Control: private, max-age=10800, pre-check=10800
Далее описываю поведение браузеров FireFox 3.5 и вышеВ-первом режиме прочно кэширует внешние JavaScript файлы и даже не проверяет их обновление, если только принудительно не обновить страницу. CSS же проверяется запросом с заголовком.
If-Modified-Since: "текущая дата" GMT If-None-Match: "свой хэш код"
То есть CSS загружается заново, только если он реально обновился.
Во-втором режиме перестает обновлять страницу вообще. То есть, даже если в базе данных мы изменили выводимый на страницу контент - этого не отображает, даже если принудительно обновлять, так как отправляет запрос:
GET / HTTP/1.1 Host: ххх.com If-Modified-Since: текущая дата GMT
и получает ответ:
HTTP/1.1 304 Not Modified
Internet Explorer 8 (IE8)В-первом режиме Internet Explorer отправляет запросы If-Modified-Since & If-None-Match и для JavaScript и для css, то есть грузит JavaScript и CSS только если они реально обновились. То же самое если принудительно обновить страницу.
Во-втором режиме Internet Explorer так же отправляет запросы If-Modified-Since & If-None-Match и для JavaScript и для css. Но при этом он даже не пытается загрузить/обновить саму страницу, то есть, даже не отправляет запрос, то есть, ваши js/css обновятся, а шаблон и контент страницы - нет. Для обновления контента не помогает даже принудительное обновление страницы.
Opera 10 и старшеВ-первом режиме Опере, в первом режиме, обновление js & CSS зависит от того, в какое значение выставлена опция Check images в настройках. Если опция выставлена в значение Always, то опера отправляет запросы с If-Modified-Since & If-None-Match для проверки обновления js & css. Если выставлено значение, например, 5 часов, то соответственно проверяться будет раз в 5 часов, либо по принудительному обновлению страницы.
Во-втором режиме, Опера не проверяет обновление js & CSS (не делает GET-запросов), а так же не делает GET запрос на саму страницу, то есть, ни обновление js & css, ни обновление контента мы не увидим, как в прочем и в других браузерах. А вот с принудительным обновлением у Оперы лучше. В отличие от IE & FF, Опера явно запрашивает содержимое страницы без If-Modified-Since & If-None-Match. Запросы на обновление js & CSS при принудительном обновлении идут уже с If-Modified-Since & If-None-Match.
ВыводыУдачи вам и прибыльных сайтов.
Коэффициент демпфирования (Damping Factor)
Возможности и ограничения социальной сети вконтакте
Что за вирус атаковал компании по всему миру и что делать, если ваш компьютер заражён