Стиснення увімкнено, а PageSpeed досі попереджає: як виправити
Ви увімкнули Gzip або Brotli, можливо, навіть бачили, що воно працює, а PageSpeed Insights досі просить стиснення тексту. Залежно від версії він показує це або як Enable text compression зі списком усіх текстових файлів, отриманих без стиснення, або в розділі Document request latency, який дивиться на саму HTML-сторінку. PageSpeed не помиляється: він оцінює саме ті відповіді, які отримав, а ви, найімовірніше, перевірили одну сторінку в одному браузері, і десь між цими двома поглядами файл іде без стиснення. Перевірка на цій сторінці завантажує будь-яку адресу з тим самим заголовком Accept-Encoding, що й браузер, і показує, яке кодування повернув сервер, тож позначені файли можна пройти по одному.
Перевірте свій сайт
-
Прочитайте, що саме позначив PageSpeed
Розгорніть попередження і скопіюйте адреси під ним. Зверніть увагу, які з них на вашому домені, а які на чужих: шрифти, аналітика, чат-віджети, карти й рекламні скрипти йдуть із власних серверів, і жодне налаштування вашого хостингу не може їх стиснути. Якщо в списку лише сторонні файли, рішення - прибрати чи замінити такий скрипт, а не змінювати сервер.
-
Перевірте кожен свій файл
Вставте повну адресу позначеного файлу, наприклад https://ваш-сайт.com/wp-content/themes/x/style.css, у перевірку на цій сторінці. Якщо в результаті стиснення стоїть gzip або br, цей файл тепер стискається. Якщо там «вимкнене», сервер віддав його без стиснення, і наступні кроки пояснюють чому. Так само перевірте HTML-сторінку, використовуючи саме ту адресу, яку тестував PageSpeed, з тим самим https і www.
-
Додайте типи файлів, які пропускає ваше правило
Стиснення на сервері налаштовується за MIME-типами, а списки в багатьох скопійованих фрагментах застарілі: вони охоплюють text/html і text/css, але пропускають application/javascript чи text/javascript, application/json, image/svg+xml, application/xml або старіші формати шрифтів на кшталт font/ttf та application/vnd.ms-fontobject. Додайте відсутні типи в AddOutputFilterByType у .htaccess (Apache mod_deflate) або в gzip_types у nginx, де text/html стискається завжди, а решту треба перелічити. Шрифти WOFF2, зображення й відео вже стиснуті, і в списку їм не місце.
-
Зʼясуйте, хто насправді віддає файл
Налаштування стиснення в плагіні WordPress чи в PHP охоплює лише сторінки, які генерує PHP, тож статичні CSS і JS, які віддає веб-сервер напряму, лишаються нестиснутими. На деяких конфігураціях nginx віддає статику перед Apache і взагалі не читає .htaccess. Увімкніть стиснення на рівні веб-сервера або попросіть про це хостинг, а не покладайтеся на плагін.
-
Очистіть кеші зі старими копіями
CDN чи кешувальний проксі міг зберегти нестиснуту копію ще до того, як ви увімкнули стиснення, і віддавати її далі. Переконайтеся, що відповіді містять Vary: Accept-Encoding, щоб кеші тримали стиснуту й звичайну версії окремо, а потім очистіть кеш CDN і плагіна кешування. У Cloudflare стиснення для відвідувачів відбувається на його серверах, але файл, закешований у поганому стані, все одно треба очистити.
-
Не зважайте на надто малі файли
PageSpeed показує лише файли, де стиснення дало б відчутну економію, приблизно від 1,4 КБ і 10% розміру, а сервери зазвичай навмисно не стискають крихітні відповіді. Якщо файл на кілобайт-два в нашій перевірці без стиснення, це нормально, і PageSpeed скаржиться не на нього.
Як перевірити результат
Знову запустіть перевірку на цій сторінці для кожного файлу зі списку PageSpeed і для самої сторінки: усі ваші текстові файли тепер мають показувати gzip або br. Потім повторіть PageSpeed Insights. Він завантажує свіжі копії, але якщо перед сайтом CDN, зачекайте кілька хвилин після очищення кешу. Якщо попередження лишилося лише для сторонніх адрес, свою частину ви зробили.
Порада: Не вмикайте кілька рівнів стиснення одночасно. Стиснення в плагіні, у PHP (zlib.output_compression) і у веб-сервері водночас може дати подвійно закодовані відповіді, які браузер показує як сміття або як ERR_CONTENT_DECODING_FAILED. Виберіть одне місце, краще веб-сервер чи CDN, а решту вимкніть.