Компания Facebook подвела итоги (https://code.facebook.com/posts/557147474482256) инициативы по увеличению эффективности локального кэширования на стороне web-браузеров, проведённой совместно с разработчиками Chrome и Firefox. Инженеры Facebook обратили внимание на то, что ощутимая часть запросов связана с получением сведений об актуальности прокэшированного статического контента (в основном изображения, CSS- и JavaScript-файлы), в процессе повторной загрузки страниц или запроса идентичных ресурсов при открытии новой страницы. Внесённые разработчиками Firefox (https://hacks.mozilla.org/2017/01/using-immutable-caching-to.../) и Chrome (https://blog.chromium.org/2017/01/reload-reloaded-faster-and...) изменения позволили на 60% сократить число запросов статических ресурсов, что привело не только к снижению нагрузки на серверную инфраструктуру, но и значительно увеличило скорость загрузки страниц.В частности, за счёт сокращения отправки лишних сетевых запросов для проверки актуальности прокэшированных браузером ресурсов, скорость повторной загрузки страниц Facebook возросла на 28%. При этом изменения не специфичных для Facebook и аналогичным образом повышают эффективность работы с любыми другими сайтами. Например, разработчики Chrome провели более глобальное измерение, в котором выяснили, что после внесения оптимизаций время загрузки всех сайтов, на которых 90% ресурсов загружаются повторно, сократилось на 1.6 сек. при использовании 3G-соединения.
Инициатива по повышению эффективности кэширования была предпринята после изучения в Facebook особенностей повторного запроса ресурсов в условиях изначально заданного большого времени жизни. Для максимального использования кэширования на стороне браузера в Facebook URL каждого статического ресурса включает уникальный хэш от его содержимого, что позволяет выставлять изначально большое время жизни записей (заголовок "cache-control: max-age=" установлен в год), не заботясь о вопросе сброса кэша после изменения файла (если файл изменится, изменится хэш и URL, что приведёт к загрузке файла независимо от времени жизни элемента к кэше).
Проблема оказалась в том, что несмотря на большое время жизни браузеры продолжают достаточно интенсивно отправлять проверочные запросы, оценивая время модификации файла. В частности, при перезагрузке пользователем ранее открытой страницы перепроверка актуальности всех ресурсов, в том числе внешних, выполняется независимо от того истекло время жизни записи в браузерном кэше или нет. В результате, несмотря на выставление времени жизни статических ресурсов в год, в 2014 году около 60% всех запросов приводило к выводу ответа с кодом 304 (файл не изменился). При этом, в обращениях пользователей Chrome проверочных запросов было 63%, Firefox - 13%, IE - 14%, Safari - 22%.
Как видно из статистики, основной вклад во внеочередные проверки вносил браузер Chrome. Анализ кода показал (https://chromium.googlesource.com/chromium/src/+/540d0cca0eb...), что Chrome всегда отправляет проверочный запрос, если обращение произведено с использованием метода POST. Разработчики аргументировали такое условие тем, что часто POST-запрос приводит к изменению страницы и необходимо всегда обеспечить показ самого актуального варианта. С другой стороны, операция авторизации в Facebook также проводится с отправкой данных методов POST, что приводило к перепроверке всех ресурсов при каждом входе пользователя в Facebook, игнорируя состояние кэша. Исправление данной особенности привело к тому, что число проверочных запросов от Chrome сократилось с 63% до 24%.
Продолжив анализ особенностей работы Chrome стало ясно, что Chrome считает перезагрузкой страницы ситуацию повторного открытия через элементы навигации (например, когда пользователь возвращается к прошлой странице через кнопку назад), что другие браузеры не трактуют как перезагрузка. Исправление данной особенности существенно не повлияло на статистику и стало ясно, что причина в поведении браузера при нажатии кнопки "перезагрузить страницу". В ходе длительных дебатов был достигнут компромисс - не проводить повторную проверку для уже давно не изменявшихся ресурсов, но как и раньше проверять ресурсы, которые были изменены недавно. Изменения были приняты в Chrome 54 и привели к существенному ускорению повторной загрузки.
Что касается Firefox, то его разработчики не согласились (https://bugzilla.mozilla.org/show_bug.cgi?id=1267474) менять давно устоявшееся поведение кнопки "перезагрузить страницу", но реализовали заголовок "cache-control: immutable (https://bitsup.blogspot.ru/2016/05/cache-control-immutable.html)", предоставив администраторам сайтов возможность управлять поведением при перезагрузке. При наличии данного заголовка браузер считает, что текущая страница никогда не меняется и не выполняет повторные проверки. Изменение было принято в Firefox 49. Кроме того, для увеличения скорости загрузки страниц в Firefox 44 был реализован метод сжатия Brotli (https://www.opennet.ru/opennews/art.shtml?num=43006), который по сравнению с gzip позволяет сократить размер отдаваемого содержимого на 20%.
URL: https://blog.chromium.org/2017/01/reload-reloaded-faster-and...
Новость: http://www.opennet.ru/opennews/art.shtml?num=45934
