Ещё одна хорошая статья от calendar.perfplanet.com. В этот раз Джозеф Скот написал про плюсы и минусы хостинга сторонних скриптов на своём домене — "Self-hosting third-party resources: the good, the bad and the ugly".

Селф-хостинг хорош тогда, когда в проекте используются такие ресурсы, которые находятся на критическом пути рендеринга. Иначе говоря, контент сайта в случае селф-хостинга будет отображаться быстрее, так как браузеру не надо будет тратить время на установку дополнительного соединения с внешним ресурсом/CDN. Более того, селф-хостинг решает проблему кеширования в Safari, так как он повторно загружает ресурсы (например, JavaScript-файлы с googleapis), даже если они были ранее закешированы на другом сайте. Это происходит из-за того, что в Safari включена защита от трекинга пользователей. Кроме плюсов есть и минусы. Самый большой минус — это риск того, что с сайта будут утекать куки на сторонний ресурс.

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

#performance #cdn #cache

https://calendar.perfplanet.com/2019/self-hosting-third-party-resources-the-good-the-bad-and-the-ugly/

Бенг Ю и Джонатан Империоси из Google рассказали, как добавление http-заголовка stale-while-revalidate повлияло на бизнес-метрики — "How Google improved ads performance with stale-while-revalidate".

Google Ad Manager для показа рекламы использует скрипт gpt.js. Этот скрипт находится в кеше браузера не более 15 минут. Как только проходит 15 минут запись в кеше устаревает и браузер делает синхронный запрос для получения свежей версиии gpt.js. В Chrome 75 появилась поддержка stale-while-revalidate. Команда разработки Ad Manager добавила к gpt.js http-заголовок

cache-control: private, max-age=900, stale-while-revalidate=3600

Он говорит о том, что если файл запрашивается между 15 и 60 минутами, после того как он попал в кеш, тогда будет использоваться устаревшая версия файла, но в фоне скрипт будет обновлён и закеширован для использования в будущем. Добавление заголовка ускорило начальную загрузку скрипта на 2% и на 0.5% увеличилио доход от показанной рекламы.

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

#performance #cache

https://web.dev/ads-case-study-stale-while-revalidate/

Недавно в Firefox была обнаружена проблема с кешированием данных в Twitter. Любой пользователь с физическим доступом к компьютеру теоретически мог прочитать чужие личные сообщения. Мартин Томсон из команды разработки Firefox рассказал, почему это произошло, в статье "Twitter Direct Message Caching and Firefox".

Чтобы предотвратить кеширование контента в браузерах, сайт должен отправить в ответе http-заголовок Cache-Control: no-store. В любом другом случае в Firefox начинает работать механизм эвристического кеширования. Этот механизм используется для предсказания, какой контент может быть закеширован и на какое время. Контент без Cache-Control: no-store сохраняется в кэше на семь дней. Как вы наверное уже догадались Twitter не отправлял этот заголовок в ответе из-за чего в Firefox включался механизм кеширования. Вместо него Twitter отправлял заголовок Content-Disposition, который используется для добавления метаинформации (например, имени файла) к загружаемым файлам. В статье говорится, что в "other browser" (как я понимаю Chrome) наличие этого заголовка отключает кеширование, но это поведение не является частью стандарта.

Какие можно сделать выводы из этой истории? Нужно проверять работу сайта в разных браузерах (Chrome, Firefox, Safari) и не стоит полагаться на поведение браузера, которое не соответствует стандартам.

#firefox #cache #http

https://hacks.mozilla.org/2020/04/twitter-direct-message-caching-and-firefox/

Прочитал пост Пауло Кальвано про эвристическое кеширование в браузерах — "HTTP Heuristic Caching (Missing Cache-Control and Expires Headers) Explained".

Для установки времени жизни контента в кэше браузера веб-серверы отправляют http-заголовки Cache-Control и Expires. Если установлены оба заголовка то приоритет получает Cache-Control. Есть ошибочное мнение, что если не отдавать эти заголовки, то браузеры не будут кэшировать контент, но на самом деле браузеры всё равно будут его сохранять. Время жизни обычно составляет 10% от промежутка времени между датой последнего изменения файла Last-Modified и текущей датой. Этот нюанс может принести много проблем, поэтому не рекомендуется удалять заголовки Cache-Conrol и Expires. Для отключения кэширования лучше всего использовать Cache-Control: no-store или Cache-Control: max-age=0.

Очень полезная статья. Рекомендую почитать.

#http #cache

https://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/

Тим Кадлек разобрался в причинах странного поведения prefetch на Netlify и рассказал про свои находки в статье "Prefetching? At This Age?".

Тим подключил к своему сайту библиотеку Instant.Page. Она помогает подгружать страницы в фоновом режиме с помощью prefetch, отслеживая наведение курсора мыши на ссылки и тапы пользователя. Но при хостинге сайта на Netlify подгруженные страницы при переходе по ссылкам не бралась из кэша, а загружалась повторно.

Оказалось, что Netlify (и любые другие CDN) отправляет заголовок Age, когда его значение превышает max-age браузер начинает повторно загружать ресурс. В Chromium, правда, логика немного сложнее — ресурс, загруженный с помощью prefetch, хранится в кэше пять минут вне зависимости от заголовка Cache-Control, но по каким-то причинам этот период учитывал Age. Баг в Chromium уже поправили. В Firefox баг заведён, но пока ещё открыт.

Очень интересная статья. Рекомендую почитать всем, кто интересуется темой производительности работы сайтов.

#performance #cache

https://timkadlec.com/remembers/2020-06-17-prefetching-at-this-age/

Пол Кальвано — специалист в области web-производительности из Akamai — написал статью про Back/Forward кэш и его влияние на производительность — "Browser Back/Forward Caches and their Benefit to Web Performance".

В Firefox и Safari используется Back/Forward Cache (BF Cache). В нём сохраняется состояние страниц, которые пользователь посещал ранее, благодаря чему браузеру не нужно повторно строить DOM при навигации по истории с помощью кнопок Back/Forward. Если страница находится в BF Cache, то она загружается очень быстро.

В Chrome 86 BF Cache будет включён по умолчанию для всех пользователей. Это значит, что если вы собираете пользовательские метрики, то стоит ожидать падение количества загрузок сайта, так как инструменты мониторинга не отправляют статистику для страниц, полученных из BF Cache. Также стоит ожидать небольшое повышение времени загрузки, так как некоторые переходы по истории больше учитываться не будут.

#performance #cache #chrome

https://paulcalvano.com/2020-08-03-browser-backforward-caches-and-their-benefit-to-web-performance/

В Chrome 86 HTTP-кэш становится изолированным. Что это означает рассказал Еиджи Китамура в статье "Gaining security and privacy by partitioning the cache".

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

Chrome 86 начал использовать для имени ключа кэша "Network Isolation Key", который состоит из имени сайта и сайта текущего фрейма (если фрейма нет, то будет использоваться имя сайта второй раз). У изолированного кэша есть небольшой недостаток — он может повлиять на метрики производительности сайта.

На данный момент изоляция кэша включена в Chrome и Safari. В Firefox она тоже поддерживается, но выключена по умолчанию (её можно включить с помощью флага privacy.firstparty.isolate в about:config ).

#chrome #cache

https://developers.google.com/web/updates/2020/10/http-cache-partitioning

На прошедшем Chrome Dev Summit Сэм Сороугуд рассказал про оптимальный подход кэширования ресурсов — "Love your cache".

В качестве дефолтного поведения Сэм предлагает использовать кэширование с ревалидацией: Cache-Control: max-age=0,must-revalidate,public. Этот подход используется в современных CDN, например, Netlify. Но стоит учитывать, что при ревалидации браузер отправляет дополнительный запрос на сервер.

Для ресурсов, которые обновляются редко, предлагается использовать хэши в именах файлов и длинное время жизни кэша: Cache-Control: max-age=31536000,immutable. Использования одной директивы max-age в Firefox и Safari не гарантирует, что будет использоваться кэш. Для того чтобы все браузеры всегда использовали кэш, нужно добавлять директиву immutable.

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

#performance #cache

https://www.youtube.com/watch?v=tprJYFkv4LU
https://web.dev/love-your-cache/ (расшифровка основного материала доклада)

В Firefox 85 для всех пользователей включён изолированный кэш для борьбы с супер-куками — "Firefox 85 Cracks Down on Supercookies".

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

В Firefox 85 была включена изоляции для разных видов кэшей: HTTP-кэша, кэша изображений, кэша для favicon, HSTS, OCSP, CSS и т.п. Изоляция может незначительно влиять на производительность — время загрузки сайта для самого наихудшего случая увеличилось на 1.32%.

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

#firefox #cache #performance

https://blog.mozilla.org/security/2021/01/26/supercookie-protections/

Новые возможности управления кешом в HTTP

Тим Пэрри написал статью про новые HTTP-заголовки для управления кешом и упрощения отладки проблем кеширования — "New HTTP standards for caching on the modern web".

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

Для более тонкого управления кешом в стандарт был добавлен Targeted Cache-Control. По сути это обычный Cache-Control, который можно использовать для точечного управления кешами. Akamai и Cloudflare уже поддерживают CDN-Cache-Control, Akamai-Cache-Control и Cloudflare-CDN-Cache-Control. В будущем возможно появление Client-Cache-Control и других подобных заголовков.

Тим пишет, что Cache-Status и Targeted Cache-Control находятся на стадии черновика, но спецификации уже не будут меняться кардинально.

#http #cache #spec

https://httptoolkit.tech/blog/status-targeted-caching-headers/