Мы прогнали свой сайт через PageSpeed Insights — бесплатный инструмент Google, которым скорость сайтов меряют все, — и получили 82 балла из 100 на телефоне. При том, что за неделю до этого собственные замеры показывали цифры, которыми можно хвастаться: сервер отвечает за 48 миллисекунд, страница весит втрое меньше среднего по интернету.
Оба замера были верными. Просто мерили они разное.
Разберу, что показывает PageSpeed, какие три ошибки нашлись на сайте, который делали аккуратно, и сколько стоило их исправить. В конце — как проверить свой сайт за пять минут и что делать с результатом.
Почему наши цифры врали, а сайт был медленным
Мы меряли по журналу веб-сервера: сколько времени проходит от запроса до ответа. Получалось 48–55 миллисекунд — отличный результат, вчетверо лучше порога.
Проблема в том, что это время сервера. В него не входит дорога до посетителя, разбор страницы браузером, загрузка шрифтов и картинок. Человек с телефоном в метро видит совсем другое.
PageSpeed меряет именно это: он эмулирует недорогой телефон на медленном мобильном интернете и смотрит, когда страница станет пригодной для чтения. На таком стенде наш сайт получил 82 балла и красную отметку у главного показателя.
Вывод, который стоит записать: если вы меряете скорость по логам сервера, вы меряете свою половину пути. Она важна, но не она определяет, уйдёт ли человек, не дождавшись.
Что вообще меряют: четыре показателя без жаргона
В отчёте четыре главные строки. Названия английские, смысл простой.
Первая отрисовка (First Contentful Paint). Когда на белом экране появляется хоть что-то. Хорошо — быстрее 1,8 секунды. До этого момента человек смотрит в пустоту и не знает, работает ли сайт.
Главный элемент (Largest Contentful Paint). Когда появляется самое большое, ради чего страница открыта: заголовок, главная картинка, первый абзац. Хорошо — быстрее 2,5 секунды. Это ключевой показатель: именно он говорит, когда страницей можно пользоваться.
Блокировка (Total Blocking Time). Сколько времени страница не отвечает на касания, потому что браузер занят выполнением кода. Хорошо — меньше 200 миллисекунд. Знакомое «нажимаю, а оно не реагирует» — это оно.
Смещение вёрстки (Cumulative Layout Shift). Насколько прыгает содержимое, пока страница дозагружается. Хорошо — меньше 0,1. Когда вы целитесь в кнопку, а она уезжает вниз, потому что сверху догрузилась картинка, — это оно.
Отдельно: Speed Index — насколько быстро экран заполняется целиком.
Ошибка первая: картинка в восемь раз больше нужного
Самая дорогая находка. В стилях главной был подключён декоративный значок — файл на 299 килобайт. Рисуется он размером 88 на 88 пикселей, то есть меньше ногтя на экране телефона.
Файл был 760 на 686 пикселей. Восьмикратный запас «на всякий случай», о котором все забыли.
Рядом, в той же папке, лежала облегчённая версия того же значка на 49 килобайт. Её сделали когда-то и не подключили.
Мы сделали версию под реальный размер: 9 килобайт вместо 299. Разница в тридцать три раза, на глаз — никакой.
Как такое заводится. Никто не подключал тяжёлый файл специально. Картинку положили в исходном размере, чтобы «не потерять качество», потом сверстали блок, потом поменяли размер блока — и связь между файлом и тем, как он используется, потерялась. На сайте, который делает один человек за один день, это заметно. На сайте, который живёт год и которого касались пятеро, — нет.
Ошибка вторая: три запроса, из-за которых экран оставался белым
Стили сайта лежали в трёх файлах — суммарно 41 килобайт. Немного. Но браузер устроен так: пока не загружены все стили, он не рисует ничего. Пустой экран.
На быстром интернете три запроса — это миллисекунды. На медленном мобильном каждый запрос стоит времени сам по себе, независимо от размера: соединение, ожидание, ответ. PageSpeed оценил задержку в 300 миллисекунд только на ожидании стилей.
Мы встроили стили прямо в страницу. Теперь браузер получает всё нужное для отрисовки одним ответом: запросов за стилями — ноль.
За это есть плата, и её надо понимать. Встроенные стили не кэшируются отдельно: на каждой странице они приезжают заново. Для сайта из полутора десятков страниц это выгодный размен — человек обычно смотрит одну-две. Для интернет-магазина с тысячей карточек, по которым ходят подряд, решение было бы обратным.
Ошибка третья: счётчик, который грузился раньше содержимого
Скрипт Яндекс.Метрики весит около 50 килобайт и до нашей правки загружался вместе со страницей. Он не блокирует отрисовку напрямую, но занимает канал: на медленной сети браузер тянет счётчик вместо того, что человек пришёл читать.
В отчёте это выглядело как «неиспользуемый JavaScript — 52 КиБ».
Мы отложили загрузку: счётчик стартует после того, как страница отрисовалась, либо при первом действии человека — прокрутке, касании, нажатии клавиши, — что случится раньше.
Данные при этом не теряются. Очередь вызовов создаётся сразу, счётчик отправляет её, когда доедет. Визит засчитывается — просто на секунду позже.
⚠️ Почему нельзя ждать только окончания загрузки. Если посетитель закроет страницу раньше, чем она догрузится, визит не засчитается вовсе — и вы потеряете именно тех, у кого сайт грузился долго. То есть данные о проблеме исчезнут вместе с проблемой. Поэтому счётчик стартует и по первому действию тоже.
Кэш: браузер перепроверял каждую картинку при каждом заходе
Отдельная строка отчёта — «выберите эффективный период хранения кеша». Наши картинки отдавались с указанием «проверяй каждый раз»: браузер хранил копию, но перед показом всё равно спрашивал сервер, не изменилась ли она.
Поставили неделю. Повторные заходы стали бесплатными.
Почему не год, как советует PageSpeed. Год безопасно давать файлам, у которых в имени зашит номер версии: изменилось содержимое — изменилось имя, старое никому не мешает. У наших картинок имена постоянные, поэтому год означал бы, что заменённая картинка неделями показывается старой у тех, кто уже был на сайте. Неделя — компромисс: повторные заходы дёшевы, а правка догоняет посетителя за приемлемый срок.
Что получилось
| Показатель | Было | Стало |
|---|---|---|
| Оценка на телефоне | 82 | 99 |
| Оценка на компьютере | 97 | 99 |
| Появление главного элемента | 4,9 с | 2,0 с |
| Первая отрисовка | 2,2 с | 1,2 с |
| Блокировка | 50 мс | 30 мс |
| Смещение вёрстки | 0,04 | 0,008 |
На компьютере первая отрисовка — 0,4 секунды, главный элемент — 0,5.
Работы примерно на час: найти, заменить, проверить. Ни строчки нового функционала, ни копейки на инструменты.
На чём делать сайт, если скорость важна
Теперь то, ради чего всё затевалось. Наш сайт статический: страницы собраны заранее и лежат на диске готовыми файлами. Веб-сервер просто отдаёт их — без базы данных, без движка, без плагинов в цепочке ответа.
Отсюда 48 миллисекунд на ответ сервера. Их нечем ухудшить: генерировать нечего.
Из чего это собрано у нас — раз уж речь о выборе основы:
- Генератор страниц — Astro. Собирает готовые файлы из шаблонов и текстов один раз, при сборке. В браузер уезжает разметка и стили; кода, который выполняется на сервере при каждом заходе, нет вовсе.
- Веб-сервер — Caddy. Отдаёт готовые файлы, сам получает и продлевает сертификаты, сжимает ответы. Настройка — три десятка строк, из них половина про кэширование и защиту от сканеров.
- Тексты и статьи — своя CMS. Живут в базе, но в базу ходит не посетитель, а сборка: нажали «Опубликовать» — собрались файлы, дальше сайт снова статический. Правка доезжает за пару минут.
- Выкладка — по пушу в репозиторий. Изменили код, отправили — сборка и выкладка идут сами.
Ключевое здесь не названия, а разделение: база и админка есть, но их нет в цепочке ответа посетителю. Всё, что может тормозить или сломаться, происходит до того, как человек открыл страницу, а не во время. Типовой сайт на популярном движке работает иначе. На каждый запрос: движок стартует, обращается к базе, собирает страницу из шаблонов, прогоняет через десяток расширений, отдаёт результат. В хорошем случае это 200–400 миллисекунд, в обычном — секунда и больше. Сверху ставят кэширующее расширение, которое сохраняет готовую страницу и отдаёт её, — то есть делают из динамического сайта статический, только сложнее и с шансом отдать устаревшее.
Когда движок оправдан: каталог на тысячи позиций с фильтрами, личные кабинеты, всё, что меняется у каждого посетителя своё. Тогда генерация на лету — не блажь, а требование.
Когда нет: сайт компании, услуги, блог, портфолио. Всё, что одинаково для всех и меняется несколько раз в месяц. Здесь динамика даёт только замедление и лишние места, где что-то ломается.
⚠️ Но статика не гарантирует скорость сама по себе. Наш сайт статический — и получил 82 балла. Забытая картинка на 299 килобайт съедает преимущество мгновенно. Основа определяет потолок, а не результат.
Как проверить свой сайт за пять минут
- Откройте PageSpeed Insights, вставьте адрес, дождитесь отчёта. Смотрите вкладку «Мобильные устройства» — там строгий стенд, и там же большинство ваших посетителей.
- Найдите строку про появление главного элемента. Красная — с этого и начинайте, остальное подождёт.
- Раскройте раздел про изображения. Обычно там и лежит главная находка: файл в несколько сотен килобайт, который показывается размером с ноготь.
- Посмотрите «запросы, блокирующие отрисовку». Если их много — стили и шрифты приезжают раньше содержимого.
- Проверьте, что грузится до содержимого: счётчики, чаты, виджеты обратного звонка. Каждый такой скрипт — 30–100 килобайт впереди того, ради чего человек пришёл.
Пятый пункт обычно самый обидный: сторонние виджеты ставят «на пять минут», а платит за них каждый посетитель.
Коротко
Скорость сайта складывается из двух вещей: основа определяет потолок, содержимое определяет результат. Статический сайт даёт запас, который легко потерять на одной забытой картинке.
Мерить надо тем, что видит человек, а не тем, что удобно померить. Наши логи показывали 48 миллисекунд и были правы — просто отвечали на другой вопрос.
И главное: 99 из 100 — это не месяцы работы и не переписывание сайта. Это час на поиск трёх ошибок, каждая из которых заводится сама, если за скоростью не следить.
Мы собираем сайты так, чтобы такие вещи не заводились сами, — и следим за ними из CMS Ось Бизнеса, нашей системы управления сайтом.
Это не отдельная админка сайта, а раздел рабочего портала: там же, где ведутся задачи, клиенты и деньги. Что в нём есть по теме этой статьи:
- Скорость каждой страницы — сколько сервер отдаёт её обычно и сколько в редких задержках, плюс вес. Считается по живым запросам посетителей, а не по разовому замеру.
- Проверка веса картинок встроена в сборку: файл, который больше нужного, виден до публикации, а не через полгода в отчёте.
- Переобход в поиске — адрес уходит роботу сам при публикации и после правок; вручную можно отправить любую страницу или все сразу.
- Статьи и тексты сайта пишутся здесь же, с проверкой длины заголовков и списком битых ссылок.
Расскажите, что у вас с сайтом, — посмотрим и скажем, где теряется время.
Коротко: частые вопросы
- Почему на телефоне оценка ниже, чем на компьютере?
- PageSpeed эмулирует недорогой телефон на медленном мобильном интернете, а компьютерный тест — быструю сеть и мощное устройство. Разрыв нормален: у нас было 82 против 97. Ориентироваться стоит на мобильную оценку — там строже стенд и там же большинство посетителей.
- Что важнее всего исправлять в первую очередь?
- Строку про появление главного элемента (Largest Contentful Paint). Она показывает, когда страницей можно пользоваться, и весит в оценке больше остальных. Хорошо — быстрее 2,5 секунды. Чаще всего причина одна: тяжёлая картинка в первом экране.
- Насколько статический сайт быстрее сайта на движке?
- Ответ сервера у статики — десятки миллисекунд, потому что генерировать нечего: страницы лежат готовыми файлами. У типового сайта на движке это сотни миллисекунд, потому что на каждый запрос стартует движок, обращается к базе и собирает страницу. Но основа определяет потолок, а не результат: статический сайт с забытой картинкой на 300 килобайт будет медленным.
- Обязательно ли переводить все картинки в webp?
- Нет. Сначала посмотрите, не больше ли файл того размера, в котором он показывается — это даёт выигрыш в разы, а не проценты. Формат меняют вторым шагом, и не везде: карточки ссылок для мессенджеров должны остаться png или jpg, иначе ссылка уйдёт без картинки.
- Мешают ли счётчики и виджеты скорости сайта?
- Да, если грузятся вместе со страницей. Скрипт счётчика — около 50 килобайт, чат или виджет обратного звонка — столько же и больше, и всё это едет по каналу раньше того, ради чего человек пришёл. Лечится отложенной загрузкой: после отрисовки или по первому действию посетителя. Данные при этом не теряются.