Руководство по повышению качества сайта на Astro, продолжение - финальные настройки для 100 баллов по всем категориям PageSpeed Insights

Введение

В предыдущем Руководстве по повышению качества сайта на Astro я собрал воедино крупный набор улучшений, применённых к обновлённому сайту Acecore. Эта статья является его прямым продолжением.

Эта статья закрывает небольшие задачи, которые остались после публикации предыдущего материала, и доводит сайт до состояния, где все четыре категории PageSpeed Insights показывают 100 и на мобильных, и на десктопе. Работа не ограничилась подгонкой баллов: также были выведены из первоначальной загрузки GA4 и поиск, упорядочены breadcrumbs и правила индексации в Search Console, стабилизирован рендеринг иконок и явно обозначено, где дальнейшая оптимизация уже не стоит усилий.

Результат: 100 баллов по всем категориям PageSpeed Insights

По состоянию на 29 марта 2026 года главная страница Acecore показывала следующие результаты.

Ниже собраны реальные скриншоты PageSpeed Insights и URL отчётов. На предыдущем этапе я считал, что «mobile 99 / всё остальное 100» — это реалистичный потолок. На этот раз за счёт удаления ненужных сторонних beacon и внимательного разбора смысла оставшихся диагностик удалось выйти на 100.

URL отчётов

Чтобы вместе со скриншотами оставить и доказательство, которое можно позже открыть заново, я также добавляю прямые URL отчётов, использованных в этом измерении.

• Мобильный отчёт
• Десктопный отчёт

Нажмите на изображение, чтобы сразу открыть соответствующий отчёт PageSpeed Insights.

Мобильные Десктоп

Насколько значимы 100 баллов

Когда слышишь о 100 баллах, легко подумать, что Performance всегда будет расти, если и дальше убирать функции, упрощать интерфейс и срезать внешние элементы. Отчасти это правда: статический сайт действительно часто ускоряется по мере того, как из него убирают лишнее.

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

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

Финальные доработки на пути к 100 баллам

1. Отключение Cloudflare Web Analytics и переупорядочивание ролей измерения

Cloudflare Web Analytics полезен как privacy-first и лёгкий RUM-инструмент, но на стороне Acecore GA4 уже был широко настроен для измерения кликов по CTA, поиска, контактных действий, генерации лидов и других событий.

После повторной оценки ролей я пришёл к выводу, что со стороны Cloudflare цена дальнейшего внедрения ненужного beacon в PageSpeed уже стала выше его полезности. Я отключил RUM в панели и подтвердил, что static.cloudflareinsights.com/beacon.min.js исчез из production HTML.

Однако это не означало отказ от измерения в целом. CTA, внешние ссылки, поиск и контактные конверсии всё ещё должны были измеряться, поэтому следующим шагом стало сохранение GA4 при изменении момента его загрузки.

2. Сохранить GA4, но убрать его из первоначальной загрузки

Ключевая развилка здесь была не только между «оставить GA4» и «убрать его», а между «оставить» и «загружать с самого начала».

На практике точка входа gtag остаётся доступной сразу, чтобы события могли приниматься, но реальный скрипт gtag/js переносится на requestIdleCallback и пользовательские взаимодействия. Дополнительно для разных типов страниц оставлены разные fallback-задержки, чтобы analytics всё равно в итоге загрузился даже без мгновенной активности пользователя.

Это позволило сохранить измерение CTA, внешних ссылок, поиска и контактов, не проталкивая выполнение стороннего скрипта в самую раннюю фазу рендера. Иначе говоря, 100 баллов были достигнуты не только за счёт удаления Cloudflare beacon, но и благодаря более умной загрузке GA4.

3. Перевести поиск и Pagefind на загрузку по требованию

Поиск — ещё одна функция, которая способна незаметно утяжелять первоначальную загрузку, даже если пользователь не открывает её сразу. Acecore использует Pagefind для полнотекстового поиска, и в этой итерации я применил ту же дисциплину: оставить функциональность, но перестать платить за неё авансом.

Теперь модальное окно поиска загружает pagefind-ui.js и соответствующий CSS только в момент реального открытия поиска. Promise кэшируется, чтобы избежать повторной загрузки, а горячие клавиши и открытие через query string продолжают работать как раньше.

Это полезно не только для оценки Lighthouse. Обычный первый рендер сайта тоже становится легче. Поиск остаётся на месте, но больше не лежит на критическом пути каждого просмотра страницы.

4. Разбор оставшихся диагностик PageSpeed

Даже после достижения 100 баллов в PageSpeed могут продолжать отображаться такие диагностические пункты, как Network dependency tree и render-blocking resources. Если воспринимать их как предупреждения, которые обязательно нужно полностью устранить, легко уйти в оптимизации с низкой отдачей.

Критическая цепочка в этом случае выглядела примерно так:

1. /en/
2. ClientRouter.js
3. BaseLayout.css
4. BaseLayout.js

Из этих элементов реально render-blocking оставался только BaseLayout.css. Однако его размер уже достаточно мал, а мобильные 100 баллов сохраняются, поэтому пока я классифицировал его как «оставшуюся, но допустимую диагностику». Само по себе чёткое формулирование этого решения стало важным результатом, потому что даёт явное правило остановки для будущей оптимизации.

5. Упорядочивание breadcrumbs и правил индексации в Search Console

После того как PageSpeed стабилизировался на 100, я ещё раз посмотрел на сайт уже со стороны поиска. И именно там оставалось реальное несоответствие: Search Console всё ещё показывал невалидные breadcrumbs, хотя FAQ-разметка уже была в порядке.

Чтобы это исправить, вывод BreadcrumbList на страницах-списках был переделан так, чтобы принимать явные breadcrumb-элементы, а не слишком свободно выводиться из URL. Одновременно была выровнена обработка завершающих слешей, чтобы canonical, hreflang и breadcrumb URL больше не расходились.

Также была явно определена роль индексации для страниц тегов, архивов, авторов и пагинации. Эти страницы полезны как навигация, но легко превращаются в тонкие или дублирующие цели индексации. Поэтому для них был выбран режим noindex, follow, а сами они исключены из sitemap. Это не обнуляет моментально все отчёты «обнаружена, но не индексирована», но означает, что желаемая политика индексации теперь прямо выражена в коде.

6. Унификация рендеринга иконок через общий SVG-компонент

Во время этой волны улучшений проект уже переходил от icon utility в UnoCSS к общему SVG-компоненту Icon. В процессе перехода динамические icon class, оставшиеся в ProcessFigure и StatBar, не были полностью убраны, из-за чего в некоторых статьях отображались только пустые кружки.

Я унифицировал рендеринг на стороне компонентов через Icon, а также добавил alias, который поглощает legacy-имя check-circle в circle-check.

Это дало три практических преимущества:

• Иконки гораздо реже пропадают из-за пропущенного динамического class
• Атрибуты доступности вроде aria-hidden можно унифицировать на стороне SVG
• Эксплуатация становится стабильнее, потому что рендеринг больше не зависит от статического анализа UnoCSS

Параллельно парсинг и отображение дат в блоге были выровнены по JST. Это не основная тема статьи, но помогает стабилизировать порядок постов одного дня и повышает точность временных значений в структурированных данных.

7. Что проверялось, но не было принято

После появления 100 баллов естественно хочется добить и все оставшиеся диагностики, пока на экране ничего не останется. Я сравнил несколько таких направлений, но не принял следующие.

• Дробить BaseLayout.css ещё сильнее: диагностика могла бы выглядеть чуть чище, но мобильные 100 уже стабильны, а практическая выгода не оправдывала дополнительную сложность.
• Считать целью само исчезновение отображения network dependency tree: видимая диагностика не равна автоматически реальной проблеме для пользователей.
• Сокращать third-party ещё дальше, вплоть до GA4: страница, возможно, стала бы немного легче, но цена в виде потери важных бизнес-измерений оказалась бы выше.

Именно это сравнение оказалось важным. Финальная настройка была завершена не потому, что убрали всё возможное, а потому, что оставшиеся компромиссы теперь можно чётко и обоснованно объяснить.

Практические выводы из финальной настройки

Главный результат финальной настройки заключался не просто в том, чтобы получить 100 баллов. Важнее было прийти к состоянию, где я могу объяснить, что нужно убрать, а что допустимо оставить.

Например, Cloudflare Web Analytics стоит убрать, если он остался только по инерции, тогда как GA4 нужно оставить, потому что он является ядром измерения бизнес-событий. Но если GA4 остаётся, это не означает, что он обязан сидеть в первоначальной загрузке. Намного разумнее сохранить измерение, но изменить момент загрузки скрипта.

Та же логика применима к поиску и SEO. Поиск должен остаться, но ему не обязательно входить в начальный payload. Страницы-списки остаются полезными для навигации, но не обязаны быть основными целями индексации. И network dependency tree сам по себе не означает провал — нужно смотреть внутрь и оценивать, разумна ли оставшаяся цепочка.

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

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

Итог

Как продолжение предыдущей статьи, финальная настройка закрыла следующие задачи:

• Подтверждены 100 баллов по всем категориям PageSpeed Insights на мобильных и десктопе
• Отключён Cloudflare Web Analytics, при этом GA4 сохранён, но переведён на отложенную загрузку
• Поиск и Pagefind переведены на загрузку по требованию, что уменьшило начальную нагрузку
• Разобраны оставшиеся сетевые диагностики и чётко определено, какие остаточные проблемы допустимы
• Упорядочены breadcrumbs в Search Console и правила индексации для страниц-списков
• Устранены проблемы пропадающих иконок за счёт унификации на общем SVG Icon
• Отброшены дополнительные оптимизации с низкой отдачей, а разумная точка остановки стала явной

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