Настройка правил эффективного использования кеша для статических объектов

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

Меня уже давно смущал  один пункт в этом  гугловском инструменте, который постоянно просил оптимизации. А конкретно это пункт:  «Настройка правил эффективного использования кеша для статических объектов.»  Настроить нормально работать кеш не так сложно, нужно всего лишь выставить продолжительность жизни для статичных элементов на сайте. Сделать это можно с помощью различных плагинов или напрямую в настройках сервера. Самый простой и правильный (на мой взгляд) вариант правильно составить файлик .htaccess для вашего сайта. Суть в том чтобы заставить все статичные элементы, типа картинок и редко обновляемых скриптов сохраняться в кеш пользователю. Тем самым при следующем заходе на сайт эти элементы будут уже не скачиваться опять с нашего сервера, а грузиться локально с диска.

Как правильно настроить .htaccess

Тут уже каждый решает сам и всё зависит конкретно от вашего сайта. у меня например есть такие правила:

<FilesMatch ".(woff|flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$">
Header set Cache-Control "max-age=25920000"
</FilesMatch>
ServerSignature Off
# Fonts
# Add correct content-type for fonts
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-ttf .ttf
AddType application/x-font-opentype .otf
AddType application/x-font-woff .woff
AddType application/x-font-woff .woff2
AddType image/svg+xml .svg
# Compress compressible fonts
# only uncomment if you dont have compression turned on already. Otherwise it will cause all other filestypes n
ot to get compressed
# AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-opentype image/svg+xml
ExpiresActive on
# Add a far future Expires header for fonts
ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
ExpiresByType application/x-font-ttf "access plus 1 year"
ExpiresByType application/x-font-opentype "access plus 1 year"
ExpiresByType application/x-font-woff "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"

Видно, что я не сильно заморачивался и просто кеширую всю статику по максимуму. Особое внимание лишь уделил шрифтам.  После такого отчёт в  PageSpeed Insights будет выглядеть примерно так

 

И тут нас ждёт самое интересное. Вся статика закеширована, но всё равно ошибки. Ошибки и ругань на скрипты которые грузятся вообще не с нашего сервера. Это скрипты аналитики Яндекс метрики и Google Analitics. Вот такие дела Гугл с Яндексом ругаются на свои же собственные скрипты. Закешировать их мы никак не можем.

metrika tag.js грузит сайт, что делаать?

Если начать гуглить по этой проблеме, то найдётся целая куча гневных комментов и статей от различных разработчиков в сторону Яндекса и Гугла.  Но нам это всё не интересно, нас нужен способ решить проблему. И самый правильный выход из этой ситуации это просто удалить все эти метрики. Но что же делать если они нужны? В действительности это полезные и нужные инструменты и есть ещё пару интересных способов решить эту проблеме.

1 способ

Просто смириться, ждать и надеяться что в скором времени Яндекс подправит свои скрипты и хоть как-то их оптимизирует.

2 способ

Интересный способ, который предлагают некоторые разработчики. Это хранить локально эти скрипты. То есть сохранить у себя на сайте в папке эти js скрипты, а в том месте где они вызываются заменить путь запуска на локальный файл.
Выглядеть это будет примерно так:

//В куске кода, который отвечает за подключение метрики, обычно это где то в футере темы.

//(window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym");

//заменить на

(window, document, "script", "local_patch/metrika/tag.js", "ym");

А скрипты на нашем сайте мы естественно можем уже и кешировать и делать всё что угодно.

Но при таком подходе возникают свои сложности. И самое главное что нам нужно следить за актуальностью этих скриптов, чтобы метрики продолжали работать. Если мы забудем про это, то в один прекрасный момент эти скрипты могут перестать работать. Придётся ставить какую-то задачу на cron и автоматически раз в день\неделю обновлять эти скрипты у себя на сайте.

Я лично попробовал такой способ. Он действительно работает и PageSpeed реально перестаёт считать это за ошибку, но всё же это не совсем правильный подход. И чисто на глаз разницы в работе сайта никакой не заметно.

3 способ

Это примерно то же самое что и 2 способ, но гораздо проще и более надёжно. И главное быстрее. Необходимо использовать сторонние CDN сервера с этими библиотеками.

На практике это будет выглядеть вот так:

//Заменяем в коде вызова Я.Метрики этот запрос:
https://mc.yandex.ru/metrika/tag.js
//на такой (например):
https://cdn.jsdelivr.net/npm/yandex-metrica-watch/tag.js

Конкретный CDN сервер можете подобрать по своим предпочтениям. С таким подходом нужды обновлять эти файлики локально не будет. А доступность CDN серверов всё же выше чем нашего домашнего сервачка.

На этом способе я остановился, и он неплохо работает.