Короткий ответ
Скорость страницы почти всегда объясняется четырьмя вещами: изображениями, шрифтами, сторонними скриптами и работой, блокирующей отрисовку. Разбираем каждый слой, показываем, как замерять изменение и не обманывать себя, и называем цену точечной правки.
Короткий ответ: что на самом деле влияет на скорость
Скорость страницы складывается из четырёх вещей, и каждую можно показать пальцем: изображения, которые несут больше данных, чем нужно макету; шрифты, задерживающие появление текста; сторонние скрипты, подключённые ради аналитики и чата; и работа, блокирующая отрисовку — стили и сценарии, без которых браузер отказывается что-либо рисовать.
Всё остальное — хостинг, кэш, протокол, база данных — тоже влияет, но относится ко второму слою разговора. Сначала имеет смысл посмотреть, что страница вообще загружает и в каком порядке, и только потом обсуждать, откуда она берёт эти файлы и как быстро отвечает сервер.
Для владельца бизнеса, который решает, нанимать ли подрядчика, это хорошая новость. Список короткий и проверяемый. Не нужно разбираться в устройстве браузера, чтобы задать четыре конкретных вопроса и услышать по ответам, сделаны они из фактов или из успокоительных фраз.
Дальше мы разбираем каждый слой отдельно: что именно происходит, почему это замечает посетитель, что с этим обычно делают и где заканчивается зона ответственности разработчика. Технические утверждения опираются на документацию MDN о производительности и на рекомендации W3C, ссылки приведены в конце.
Скорость как ощущение: что именно замечает посетитель
Посетитель не считает миллисекунды. Он замечает три момента: когда на экране появляется хоть что-нибудь, когда появляется то, ради чего он пришёл — заголовок, цена, фотография товара, — и когда страница начинает отвечать на нажатия пальцем.
MDN описывает это как воспринимаемую производительность: ощущение скорости зависит от того, что показано и в каком порядке, а не только от суммарного времени загрузки. Страница может грузиться дольше и при этом ощущаться быстрее, если выдаёт смысл осмысленными порциями.
Практический вывод отсюда такой: оптимизировать нужно путь до первого полезного экрана, а не среднее число в отчёте. Когда предложение, за которым человек пришёл, появляется последним, ускорение всего остального меняет цифру, но не меняет впечатление.
Обратное тоже верно. Страница, которая мгновенно нарисовала текст, но секунду не реагирует на касание, ощущается сломанной. Отзывчивость — часть скорости, и обеспечивает её свободный основной поток, а вовсе не то, насколько маленькие у вас картинки.
Изображения: вес, размер и формат
С изображениями сбой обычно один и тот же. В макет ставят файл в исходном разрешении, а на экране он показывается в несколько раз меньше. Браузер честно скачивает его целиком и потом уменьшает результат: за байты заплачено, пикселей никто не увидел.
Лечится это тремя привычками. Отдавать несколько размеров через srcset и sizes, чтобы телефон получал телефонную версию. Использовать современные форматы вроде WebP или AVIF там, где есть поддержка. И выгружать файл под реальный размер контейнера, а не полагаться на уменьшение средствами CSS.
Отложенная загрузка заслуживает отдельной фразы. Атрибут loading="lazy" уместен для картинок ниже первого экрана, но не для той, что стоит наверху страницы: отложив её, вы отложите ровно тот момент, ради которого посетитель страницу и открыл.
И всегда задавайте ширину и высоту либо соотношение сторон. Это никак не связано с весом файла и полностью связано с тем, чтобы браузер заранее занял место под картинку и текст не прыгал, когда она наконец придёт.
Шрифты: почему текст появляется не сразу
Веб-шрифт браузер обнаруживает не сразу. Сначала он должен получить и разобрать CSS и только после этого узнаёт, какой файл шрифта запрашивать. Поэтому текст, набранный подключённым шрифтом, приходит позже, чем разметка вокруг него.
Что происходит в этом промежутке, решает свойство font-display. При значении по умолчанию браузер может держать текст невидимым, пока ждёт файл. Значение swap велит показать системный запасной шрифт сразу и подменить позже: читатель получает слова раньше оформления.
Дальше идёт объём. Сайту не нужен файл со всеми алфавитами: подмножество символов, которые действительно используются, срезает вполне реальный вес. Переменный шрифт способен заменить три-четыре статических начертания, а предзагрузка одного критичного файла убирает паузу в заголовке.
Цена подмены — сдвиг в момент, когда приезжает настоящий шрифт. Его уменьшают, подбирая запасной шрифт с близкими метриками. Это компромисс, а не дефект: выбор идёт между невидимым текстом и текстом, который слегка сдвинется.
Сторонние скрипты: аналитика, чаты, пиксели и виджеты
Аналитика, рекламные пиксели, чат поддержки, карта, виджет отзывов, менеджер тегов. Каждый добавляет соединение с чужим доменом и код, который выполняется в том же основном потоке, что и ваш собственный интерфейс.
Сложность не в том, что они есть, а в том, что вы ими не управляете. Их размер и поведение задаёт поставщик, который их выпускает, и изменение на его стороне становится проблемой вашей страницы в тот же день.
Поэтому держите инвентаризацию: что подключено, кто это заказал и что оно возвращает. Скрипты, у которых нет владельца внутри компании, обычно остались от кампании, закрытой год назад, и снять их можно без долгого обсуждения.
Всё, что остаётся, можно отложить. Чат и карту грузят по действию человека, а не при открытии страницы. Кнопка «Написать нам», которая подтягивает виджет только после нажатия, обходится дешевле, чем виджет, доставленный каждому вошедшему.
Работа, блокирующая отрисовку: CSS и синхронный JavaScript
Прежде чем что-то нарисовать, браузер должен построить дерево стилей. Поэтому таблицы стилей в head блокируют отрисовку: пока они не получены и не разобраны, страница остаётся пустой, даже если HTML пришёл целиком.
Скрипты ведут себя похоже, но строже. Обычный тег script останавливает разбор HTML на время загрузки и выполнения. Атрибут defer переносит выполнение на момент после разбора и сохраняет порядок; async выполняет каждый файл сразу по готовности, и порядок при этом не гарантирован.
Часть стилей можно вывести из критического пути атрибутом media: стили печати или узкого брейкпоинта не обязаны задерживать первый экран. Остальное — вопрос объёма: одна таблица стилей на весь сайт заставляет каждую страницу ждать правила, которые ей не пригодятся.
Это тот слой, который снаружи оценить почти невозможно, а изнутри поправить может почти любой. Когда единственный ответ подрядчика про скорость звучит как «сожмём картинки», он не смотрел, что стоит между запросом и первым пикселем.
Смещения макета: страница, которая прыгает под пальцем
Прыгающая страница — не косметический вопрос. Человек тянется к кнопке, сверху дозагружается баннер, и палец попадает не туда. Это отказ интерфейса, и запоминается он отчётливее, чем секунда ожидания.
Причины предсказуемы: изображения и встраиваемые блоки без объявленных размеров, реклама переменной высоты, подмена шрифта с другими метриками и содержимое, которое дописывается над уже видимым. В каждом случае лекарство одно — зарезервировать место заранее.
Здесь тема смыкается с доступностью. В кратком справочнике W3C по WCAG 2.2 есть критерий Reflow (1.4.10), который требует, чтобы содержимое оставалось пригодным при увеличении и на узком экране, и Pause, Stop, Hide (2.2.2) для движущегося содержимого.
Общий принцип — предсказуемость. Резервирование места под медиа и сдержанность с автоматической анимацией одновременно улучшают и ощущение скорости, и доступность страницы: нечастый случай, когда одна правка закрывает два требования.
Что делает сервер: кэш, сжатие и время до первого байта
Серверная сторона отвечает за время до первого байта: сколько бэкенд собирает ответ. Медленный запрос к базе, полный рендер на каждый заход, отсутствие кэша — каждое из этого откладывает момент, когда у браузера появляется хоть что-то в работе.
Дальше идёт доставка. Сжатие текстовых ответов, заголовки кэширования для статики с версионированными именами, раздача из сети, расположенной ближе к посетителю. Это решения на уровне конфигурации, а не переписывание кода, и обычно они делаются быстро.
Современные протоколы снимают часть очереди: HTTP/2 и HTTP/3 ведут много запросов по одному соединению. Это не оправдывает загрузку лишнего — просто убирает ту часть ожидания, которую раньше создавали сами запросы.
Не путайте слои. Быстрый сервер не спасёт страницу, тянущую десяток сторонних скриптов, а аккуратно собранный фронтенд не поможет, если ответ появляется через две секунды. Смотреть нужно с обоих концов.
Телефон и сеть: где проходит честная проверка
Разработчик смотрит сайт по проводу, на мощной машине, где всё уже лежит в кэше. Посетитель приходит со среднего телефона, по мобильной сети и в первый раз. Это два разных сайта, и считается второй.
Разрыв не только в канале. Более слабый процессор дольше выполняет тот же JavaScript, дольше разбирает CSS и дольше декодирует изображения. То, что на ноутбуке проходит незаметно, на телефоне превращается в паузу перед реакцией на касание.
Поэтому проверяйте на настоящем устройстве и с холодным кэшем: приватное окно, включённое ограничение сети, повторный заход через несколько часов. Эмуляция устройств в инструментах разработчика полезна, но она моделирует условия, а не воспроизводит их.
Ещё одна привычка — смотреть на разброс, а не на среднее. Если у многих страница открывается приемлемо, а у части заметно хуже, полезный вопрос звучит так: кто эти люди — какой класс устройства, какой регион, какой раздел сайта.
Как измерять, чтобы не обмануть себя
Данные бывают двух видов. Лабораторные получаются в контролируемом прогоне: воспроизводимо, удобно для сравнения до и после, но условия выбрали вы. Полевые — это то, что реально случилось у посетителей: шумнее и определяется их собственными устройствами.
MDN описывает браузерные интерфейсы измерения — от навигационного тайминга до PerformanceObserver, — которые позволяют странице самой зафиксировать, когда произошли значимые события. На этом и стоят полевые данные: замер снимается там, где сидит человек.
Порядок работы простой. Зафиксируйте исходное состояние до любых правок, на тех же страницах и в тех же условиях. Меняйте по одному слою. Замеряйте снова. Иначе вы получите улучшение и не будете знать, какая именно правка его дала.
И договоритесь заранее, что считается результатом. «Стало быстрее» — не критерий приёмки. Критерий — это список правок, названные страницы, повторяемая процедура замера и сравнение до и после, которое сможет прочитать третий человек.
Сколько стоит работа над скоростью в VITON13
Когда проблема локальная — тяжёлые изображения, забытые скрипты, шрифт без запасного варианта, — подходит Site Fix Pack за $70: до 5 согласованных правок, проверка на мобильном и десктопе, список «до и после» при передаче, 1 раунд правок, срок 1-2 рабочих дня.
Site Fix Pack сознательно не включает новые страницы, редизайн и миграции. Это инструмент точечной работы. Если диагностика показывает, что медлительность заложена в устройстве сайта, разговор переходит к тому, чтобы собрать его заново, а не латать.
Тогда это «Сайт для запуска» за $380: адаптивная вёрстка, подключение базовой CMS или данных и настройка деплоя, срок 3-5 рабочих дней и 2 раунда правок до запуска. Контент и переводы предоставляет клиент — мы их не пишем.
Когда скорость должна оставаться в порядке и дальше, есть «Постоянная техническая поддержка» за $290 в месяц: приоритетные обновления, недельный ритм релизов и техническое обслуживание. Работает месячным циклом, объём согласуется в начале каждого цикла, прекращение — с уведомлением за 30 дней.
Границы: где скорость перестаёт быть ответом
Скорость убирает препятствие, но не создаёт спрос. Если страница не объясняет, что вы продаёте и почему это стоит своих денег, мгновенная загрузка просто раньше покажет человеку текст, который его не убедил.
Часть ограничений внешняя. Встроенный плеер, платёжная форма, виджет бронирования от партнёра — вы управляете тем, когда они грузятся, но не тем, сколько они весят. Иногда честный ответ звучит как «сменить поставщика», а не «оптимизировать его код».
Часть ограничений наша, и о них лучше знать заранее. VITON13 не пишет за клиента контент и переводы и не делает нативные мобильные приложения. Если задача именно в этом, она относится к другому исполнителю или к другому договору.
И последнее: работа над скоростью не бывает разовым событием. Каждая кампания добавляет скрипт, каждая новая страница добавляет изображения. Поэтому договариваться стоит не только о правках сейчас, но и о том, кто следит за страницей потом и с каким ритмом.
Практический чеклист
- Составьте список всех сторонних скриптов и найдите владельца для каждого.
- Отдавайте изображения в нескольких размерах и в современном формате.
- Задайте ширину и высоту или соотношение сторон каждому изображению и встраиваемому блоку.
- Проверьте, что подключённые шрифты используют font-display: swap и урезаны до нужных символов.
- Снимите с критического пути стили и скрипты, без которых первый экран обходится.
- Замерьте состояние до правок и после — на тех же страницах, на реальном телефоне и с холодным кэшем.
Вопросы и ответы
Что именно замедляет сайт?
Обычно дело в четырёх слоях: изображения тяжелее, чем нужно макету; веб-шрифты задерживают появление текста; сторонние скрипты занимают основной поток; стили и синхронные сценарии блокируют отрисовку. Серверная часть и протокол — второй слой разговора.
Сколько стоит точечно ускорить сайт?
Site Fix Pack стоит $70: до 5 согласованных правок, проверка на мобильном и десктопе, список «до и после» при передаче. Срок — 1-2 рабочих дня, включён 1 раунд правок. Новые страницы, редизайн и миграции в этот пакет не входят.
А если медленно из-за самого устройства сайта?
Тогда речь о сборке заново. «Сайт для запуска» стоит $380: адаптивная вёрстка, подключение базовой CMS или данных, настройка деплоя. Срок — 3-5 рабочих дней, 2 раунда правок до запуска. Контент и переводы предоставляет клиент.
Нужна ли поддержка после того, как правки сделаны?
«Постоянная техническая поддержка» стоит $290 в месяц: приоритетные обновления, недельный ритм релизов и техническое обслуживание. Работает месячным циклом, объём согласуется в начале каждого цикла, прекратить можно с уведомлением за 30 дней. Новая сборка или редизайн оцениваются отдельно.
А если нужна не правка, а новая функциональность?
«Разработка продукта» стоит $880: поставка функций, логика состояния и маршрутов, тестирование и укрепление. Срок — 2-3 недели, 2 раунда правок на каждую поставленную функцию. Нативные мобильные приложения и лицензирование платежей в пакет не входят.