Скорость и Core Web Vitals

Я устраняю причину медленного сайта. А не симптом.

Большая часть работ по ускорению — это плагин кэширования, минификатор и повторный тест с надеждой на лучшее. Это двигает лабораторный показатель и оставляет настоящую проблему на месте. Я измеряю, куда на самом деле уходит время, исправляю именно это и даю вам «до» и «после», которые вы можете воспроизвести на своём компьютере.

Начинается с Письменного диагноза, до любой оценки
Измеряется по Полевым данным, а не только лабораторному баллу
Подходит для WordPress, WooCommerce, Laravel, статических сайтов

01ДемонстрацияВживую из вашего браузера

Эта страница, измеренная, пока вы её читаете.

Любой, кто продаёт ускорение, может показать скриншот удачного прогона. А это цифры, которые ваш собственный браузер записал, загружая эту страницу, в сравнении с порогами Google. Откройте вкладку «Сеть» и проверьте их.

Эта страница
—

Разметка, стили, скрипт и три шрифта — всё, что нужно, чтобы показать то, что вы читаете.

Типичный сайт
2,3 МБ

Медианный вес веб-страницы по данным HTTP Archive.

Largest Contentful Paint — когда основной контент закончил отрисовываться
Хорошо — 2.50 s
Эта страница —
Time to First Byte — сколько сервер думал перед ответом
Хорошо — 800 ms
Эта страница —
Cumulative Layout Shift — насколько страница сдвигалась у вас на глазах
Хорошо — 0.100
Эта страница —

02ДиагнозКуда на самом деле уходит время

Медленность — это симптом. Вот причины.

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

Сервер слишком долго думает

Высокий Time to First Byte означает, что работа идёт ещё до того, как до браузера дошёл хоть один байт. В WordPress это обычно некэшированные запросы в цикле шаблона, таблица опций с autoload, разросшаяся до нескольких мегабайт, или плагин, который при отрисовке страницы обращается к внешнему API. Никакая оптимизация фронтенда этого не касается.

Самый крупный элемент на экране огромен

Главное изображение шириной 4000 пикселей, отданное в PNG, в одиночку проваливает Largest Contentful Paint. Лечение скучное: правильные размеры, современные форматы, srcset, чтобы телефоны не качали десктопную версию, явные ширина и высота и fetchpriority на единственном важном изображении.

Скрипты блокируют отрисовку

Каждый синхронный скрипт в head — это знак «стоп» перед тем, как браузер сможет рисовать. Менеджеры тегов, виджеты чатов, инструменты A/B-тестов и загрузчики шрифтов — обычные подозреваемые, и их часто подключают на каждой странице ради функции, которая используется на одной.

Страница прыгает при загрузке

Cumulative Layout Shift вызывают элементы, которые приходят поздно без зарезервированного места: изображения без размеров, веб-шрифты, подменяющиеся другим размером, баннеры cookie и реклама, вставленные над существующим контентом. Обычно это самое дешёвое из трёх в исправлении и самое раздражающее для посетителя.

Взаимодействия ощущаются вязкими

Interaction to Next Paint заменил First Input Delay в марте 2024 года, и это куда более строгая метрика. Она измеряет, сколько времени проходит от взаимодействия до видимого отклика, на протяжении всего визита, а не только при первом действии. Сайты её проваливают, потому что за основной поток борется слишком много JavaScript.

03ПроцессДействительно последовательность

Как идёт работа.

01

Диагноз до любой оценки

Я анализирую сайт и присылаю письменный разбор того, куда уходит время, упорядоченный по тому, во что это вам обходится и насколько сложно исправить. Этот документ остаётся у вас, наймёте вы меня или нет.
02

Базовая линия по полевым данным

Лабораторные показатели скачут от прогона к прогону. Сначала я фиксирую полевые данные из Chrome UX Report, чтобы в конце мы сравнивали то, что видели реальные посетители, а не два лабораторных прогона в разные дни.
03

Устранять причины, начиная с крупных

Работа идёт на стейджинге, по одному изменению за раз, каждое измеряется отдельно. Десять изменений разом ничего не говорят о том, какое сработало, и не дают откатить то, что навредило.
04

Проверить и передать вам метод

Вы получаете «до» и «после», шаги для воспроизведения обоих и заметку о том, что будет постепенно сводить работу на нет, — обычно это следующий плагин, который кто-то установит.

04ВопросыЧастые вопросы — прямые ответы

О чём спрашивают, прежде чем нанять меня.

Исправит ли плагин кэширования мои Core Web Vitals?

В лучшем случае частично. Кэширование улучшает время ответа сервера, что помогает Time to First Byte. Оно почти ничего не даёт для Largest Contentful Paint, испорченного слишком тяжёлым главным изображением, ничего — для сдвигов вёрстки из-за элементов без размеров и ничего — для Interaction to Next Paint, испорченного тяжёлым JavaScript. Большинство сайтов приходят ко мне с уже установленным плагином кэширования и всё равно не проходят проверку.

Почему мой балл в PageSpeed Insights постоянно меняется?

Большое число вверху — это лабораторный тест на симулированном медленном устройстве, и оно меняется от прогона к прогону. Раздел ниже — полевые данные из Chrome UX Report — это то, что Google действительно использует, и это скользящее среднее реальных посетителей за 28 дней. Ориентируйтесь на полевые данные и не обращайте внимания на мелкие колебания лабораторного балла.

Как скоро улучшение будет видно в Google?

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

Какое улучшение вы можете пообещать?

Никакого, пока я не посмотрю, — поэтому сначала диагноз, а потом оценка. У сайта, перегруженного плагинами, с неоптимизированным главным изображением, много лёгкого запаса. Сайт, уже лёгкий во фронтенде, но медленный в базе данных, — это другая работа за другую цену. Лучше я дам вам реальную цифру после часа анализа, чем впечатляющую прямо сейчас.

Нужно ли переделывать сайт?

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

Что такое INP и заменил ли он FID?

Interaction to Next Paint заменил First Input Delay в составе Core Web Vitals в марте 2024 года. FID измерял только задержку до того, как браузер начнёт обрабатывать ваше первое взаимодействие. INP измеряет, сколько времени всё взаимодействие занимает до видимого отклика, на протяжении всего визита. Его значительно сложнее пройти, и проваливают его обычно по одной причине: слишком много JavaScript в основном потоке.

Мой сайт был быстрым и стал медленным. Что изменилось?

По моему опыту, почти всегда одно из трёх: с тех пор добавили плагин или скрипт отслеживания, команда контента загружает изображения в полном разрешении прямо с камеры, или база данных тихо разрослась — ревизии записей, просроченные транзиенты, таблица опций с autoload. Все три дёшево исправить, когда они найдены.

Следующий шаг

Пришлите URL. Я скажу, что с ним не так.

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

Бриф проекта Шаг 1 из 2 · Задача

Что вы хотите создать?

Для начала вполне достаточно одного абзаца. Если это не моя задача, я так и скажу и подскажу, к кому лучше обратиться.

Задача

Отметьте всё подходящее.

Платформа

«Не знаю» — вполне нормальный ответ.

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

0 / 1200

Два шага. Меньше минуты.