Исправления, которые реально двигают PageSpeed

Три сайта: логопедический сад на Joomla на общем хостинге, клиника на той же Joomla с чужими виджетами и видео, самописный PHP-блог на VPS. Все три были «жёлтыми» или хуже. Ниже — приёмы, которые дали результат, почему они работали и сколько стоили. Без историй успеха: только числа, порядок работ и грабли.

01Правило нулевое: сначала замер

Открытый API Google PageSpeed без ключа отвечает 429 Quota exceeded, интерфейс pagespeed.web.dev рисуется скриптами и текстом не вытаскивается, а локальный Lighthouse расходится с отчётом Google в разы. Поэтому:

• Мерило — отчёт владельца. Просить раскрытые пункты: там файлы, их вес и вклад в миллисекундах. Без раскрытия правки идут наугад.
• Свой замер — чтобы найти причину и увидеть «до/после», а не чтобы объявить правильный балл: вес всех ресурсов по HTTP, время запросов, размер картинки на экране против отданных пикселей, коды 4xx, ошибки консоли, CLS.
• Искать в живой странице, а не в шаблоне. Классы, картинки и старый синтаксис часто лежат в тексте блоков в базе CMS.

# вес всех ресурсов страницы без браузера: HTML + img/link/script
python weight.py https://site/
#   HTML 53.0 КБ, ресурсов 59, всего 1.53 МБ
#     160.0 КБ  /assets/dist/css/bootstrap.min.css
#      83.6 КБ  /map/js/jquery.min.js
#      76.3 КБ  /assets/dist/js/bootstrap.bundle.min.js

02Картинки: главный вес страницы

Самая большая статья расхода на всех трёх сайтах — и самая неблагодарная: урезание даёт меньше всего баллов, но без него остальное не работает.

Итог по весу: садик 11,3 → 2,9 МБ, клиника 12,86 → 0,83 МБ, блог 3,70 → 0,52 МБ.

03Дубли библиотек: причина в разметке

У садика в шапке грузились сразу два Bootstrap: 5.1.3 (в нём же Popper) и 4.1.0 со своим Popper, плюс две копии jQuery — 2.2.1 для карты и 3.6.3 «под четвёрку». Около 160 КБ кода, которого страница не использует.

Причина оказалась не в библиотеках, а в разметке: кнопка «Меню» на телефоне написана на новом синтаксисе data-bs-toggle="collapse", а выпадающие пункты — на старом data-toggle="dropdown", которого пятёрка не понимает. Ради трёх пунктов ехали BS4, Popper и вторая jQuery.

04Стили: один файл вместо двух

В шапке остались два блокирующих файла: полный Bootstrap (24,1 КБ сжатыми) и all.css (7,8 КБ) — 31,3 КБ и два запроса в критическом пути.

Что сделали: собрали список ВСЕХ имён классов и id со всех 34 страниц карты сайта, из содержимого правленых блоков и из шаблона, добавили те классы, которые Bootstrap навешивает из скрипта (show, collapsing, modal-open, dropdown-menu, was-validated…), и выкинули правила, чьих имён на сайте нет. Затем слили урезанный Bootstrap со стилями сайта в один файл.

# было: два блокирующих файла
#   bootstrap.min.css  24,1 КБ сжатыми
#   all.css             7,8 КБ сжатыми
#                            ---------
#                            31,3 КБ, два запроса в критическом пути

# стало: один файл
#   main-critical.css              13,7 КБ сжатыми
#   bootstrap внутри: 163,8 КБ -> 28,0 КБ (селекторов 2050 -> 304)

05Шрифты: 278 КБ → 58 КБ и честная цена

У садика на каждое начертание грузились старые файлы: woff 139 КБ и ttf 322 КБ. Причём в @font-face первыми стояли несуществующие файлы, а живые — ниже. Заменили на woff2 с нарезкой по языкам (кириллица 10,7 КБ + латиница 18,3 КБ) и unicode-range, объявив их под теми же именами семейств — вид текста остался прежним, вес упал в разы.

Отдельно и важнее: у шрифтов не было срока хранения вовсе. Правило ExpiresByType font/woff в .htaccess закрыло пункт отчёта на 271 КБ.

06Чужие виджеты и скрытые iframe

У клиники 1110 КБ неиспользуемого JS оказались чужими на все сто процентов. Главное открытие: спрятанный iframe грузится всё равно. Викторина лежала в окне display:none, которое показывается через минуту, — и её 650 КБ приезжали при каждом заходе.

Фасад для видео — приём, который стоит копировать. Вместо чёрного плеера: картинка-обложка width:100%;height:100%;object-fit:cover в контейнере с aspect-ratio, круглая кнопка по центру, обработчики click и keydown (Enter/пробел), role="button" и aria-label.

<!-- проверка фасада числами, ДО и ПОСЛЕ нажатия -->
ДО:    плеер display:none, запросов к чужому хосту — 0, размер блока 877×493
ПОСЛЕ: плеер display:block, запросов 48, размер блока тот же 877×493
       (вёрстка не прыгает — это и есть доказательство, что приём безопасен)

Файл ролика при этом не трогали: 1920×1080, поток 10 Мбит/с, вес 189 МБ. Фасад снимает проблему при заходе, но нажавший «играть» всё равно ждёт — пересжатие ролика это уже замена содержимого и отдельное решение владельца.

Счётчики: отложить, а не удалять

Просьба «удали лишние скрипты типа метрики, пусть грузятся через 5 секунд» решается отсрочкой: помощник запускает счётчик через 5 секунд ИЛИ при первом действии посетителя (прокрутка, клик, клавиша, касание) — что раньше. До этого момента к чужим хостам нет ни одного запроса.

07Кэш: где хостинг мешает

Пункт «выбирайте эффективный период хранения кеша» — самый крупный почти всегда. На shared-хостинге правило Expires в .htaccess покрывает картинки, но не css/js/svg: их отдаёт nginx напрямую, мимо Apache. Проверять надо каждый файл из раскрытого списка отдельным HEAD-запросом, а не «по расширениям на глаз».

curl -sI https://site/assets/dist/css/all.css | grep -i "cache-control\|expires"
#  было: (пусто)  ->  стало: Cache-Control: max-age=2592000

• Обратный случай — .webp: его nginx в списке типов не держит, файл отдаёт Apache — значит правило в .htaccess работает и закрывает пункт сразу.
• Шрифты часто не покрыты ничем: правило ExpiresByType font/woff2 сняло 271 КБ у садика.
• Свой nginx, два подводных камня: add_header Cache-Control "public" не добавляет заголовок, а ЗАМЕНЯЕТ его — max-age пропадает, и хранилище считается нулевым; писать сразу public, max-age=31536000, immutable. И проверять, что .webp/.avif есть в location ~ \.(js|css|png|jpg|…)$.

08LCP: виновника ищут замером

Отчёт называет только цифру («LCP 4,5 с»). Кто именно её держит — видно в данных Lighthouse, но не там, где ищешь по памяти: элемент и разбивка лежат в lcp-breakdown-insight (timeToFirstByte / resourceLoadDelay / resourceLoadDuration плюс узел с селектором), а проверки — в lcp-discovery-insight.

У клиники LCP держал первый слайд баннерной картинки. Картинка была объявлена фоном (background-image) внутри <style> посреди тела страницы — Chrome узнавал о ней только после шапки и половины разметки: запрос стартовал на 2,9 с при отрисовке текста на 1,1 с.

<?php if ($isHomepage): ?>
  <link rel="preload" as="image" href="/images/banners/banner-mobile.webp"
        media="(max-width:768px)" fetchpriority="high">
  <link rel="preload" as="image" href="/images/banners/banner.webp"
        media="(min-width:769px)" fetchpriority="high">
<?php endif; ?>

Две строки — и LCP 4,5 → 1,6–2,2 с. Условие «это главная» обязательно: без него все страницы сайта начнут качать картинку, которой у них нет.

09Доступность без изменения вида

Доступность набирается тремя-четырьмя правками, которых посетитель не видит. У блога было 0,83 → стало 1,0 на главной и 0,96 → 1,0 на статьях; у клиники 84 → 97; у садика 84 → правим сейчас, и там главной причиной были элементы без имени.

10Агентный просмотр: файлы для ИИ

В отчёте Google появилась категория без балла — доля пройденных проверок («1/3»). Считаются три: прыжки вёрстки, имена и роли интерактивных элементов (agent-accessibility-tree) и llms.txt. У всех трёх сайтов было 1/3.

Заодно появляются файлы, которые читают агенты, а не люди:

• /llms.txt — короткая карта сайта со ссылками (6,2 КБ у садика);
• /llms-full.txt — расширенное описание и полный список страниц (до 150 КБ у блога — это файл для машин);
• /agent.md — инструкция: что за сайт, как читать, можно ли цитировать, где цены, почему нельзя заполнять формы за человека. Отдаётся как text/markdown.

11Сводка по трём сайтам

12Что не вышло и что осталось

Не вышло

• Поднять версию PHP файлами. Проверил пять вариантов обработчика в .htaccess (AddHandler application/x-httpd-php84, …php8.4, …php8_4, AddType, …alt-php84___lsphp) — хостинг игнорирует все, версия осталась прежней. Меняется только в панели, и у каждого домёна своя.
• Замерить локальным Lighthouse как у Google. 36–38 против 82 в отчёте владельца на одном и том же коде. Пришлось строить свой стенд и мерить вес, запросы и LCP им.
• Убрать аналитику совсем. Владелец просил «удали лишние скрипты» — удалять нельзя, её ведут нарочно. Сделали отсрочку и честно сказали, кого не досчитаются.

Осталось и ждёт решения

• Контраст в блоке с розово-жёлтым градиентом у садика: заголовок #3d3c92 и текст #1d1d36 на градиенте #d6569b → #D8E61C. Это видимый вид — менять только с согласия.
• 16 фото галереи в JPEG по 27–37 КБ — в WebP будут в 2–3 раза легче, вид не изменится.
• jQuery 83,6 КБ из папки карты грузится на всех страницах, хотя нужен для одного блока в контактах.
• Срок хранения css/js/svg/woff2 на shared-хостинге — только заявкой в поддержку: .htaccess их не закрывает, отдаёт nginx.
• Три счётчика Метрики у клиники, чат и виджеты отзывов — свести и решить, что оставить.
• Ролик 189 МБ — фасад снимает проблему захода, но не ожидание после нажатия. Пересжатие — замена содержимого.

13Чек-лист, если делать у себя

• Получить раскрытые пункты отчёта: файлы, их вес и вклад в миллисекундах.
• Замерить вес страницы самому: HTML + все img/link/script.
• Сжать картинки до размера контейнера; width/height — только с height:auto.
• Мелкие копии для превью в списках: два размера, автогенерация, оригинал остаётся.
• Найти дубли библиотек; сперва переписать разметку на нужный синтаксис, потом снимать файлы.
• Спрятанные iframe и видео: about:blank + data-атрибут, фасад с кнопкой.
• Проверить, что у шрифтов и статики есть срок хранения — HEAD-запросом по каждому типу.
• Найти виновника LCP в данных отчёта и предзагрузить картинку первого экрана под условием «главная».
• Проставить имена всем интерактивным элементам, проверить контраст расчётом, а не на глаз.
• Сделать llms.txt со ссылками, agent.md и llms-full.txt.
• После каждой правки — замер «до/после» и откат под рукой.
• Проверять вид геометрией элементов, а не снимком: анимации дают ложные различия.