Пошагово разберём, что реально ускоряет сайт: изображения, кэш, сервер, CSS/JS и Core Web Vitals. Чек-лист и простые тесты для новичков.
«Быстрый сайт» — это не один магический показатель, а то, насколько быстро пользователь видит полезный контент, может взаимодействовать со страницей и не раздражается из‑за скачков верстки.
Важно различать два похожих, но не одинаковых улучшения:
Чтобы не гадать «на глаз», удобнее смотреть на несколько метрик — каждая отвечает за свою часть впечатления:
Можно легко получить ситуацию, где LCP хороший, но INP плохой: крупный контент показался быстро, а кнопки нажимаются с задержкой из‑за тяжёлого JavaScript. Или наоборот: сайт отзывчивый, но LCP высокий, потому что главный визуальный элемент грузится слишком долго.
Поэтому задача — собрать понятную картину из нескольких сигналов, а не гнаться за одной цифрой.
Дальше разберём, как быстро протестировать сайт, найти типовые узкие места и составить понятный план работ: от изображений и шрифтов до JavaScript/CSS, сервера, кэша и CDN. В конце — приоритеты на 1–2 недели и способы проверить, что изменения действительно ускорили загрузку.
Ускорение сайта начинается не с «оптимизаций наугад», а с короткой и повторяемой диагностики. Цель — получить честную базовую точку, чтобы потом сравнить «до/после» и понимать, что именно сработало.
PageSpeed Insights (PSI) — быстрый старт. Показывает и лабораторный отчёт Lighthouse, и (если есть) данные реальных пользователей из Chrome UX Report.
Lighthouse (в Chrome DevTools или CLI) — удобен для повторных прогонов на одном компьютере и для проверки конкретной страницы перед релизом.
WebPageTest — для более «приближённых к реальности» проверок: выбор устройства, региона, скорости сети, повторный визит, waterfall (кто и когда грузится).
Chrome DevTools (Network / Performance) — чтобы увидеть причины: тяжёлые файлы, блокирующие ресурсы, долгие запросы, плохой кэш.
Лабораторные тесты (Lighthouse/WebPageTest) — это контролируемая среда: удобно искать узкие места и проверять правки.
Данные реальных пользователей (полевая статистика в PSI/CrUX, аналитика, RUM) — показывают, как сайт ведёт себя у людей: на слабых телефонах, с нестабильной сетью, с «тяжёлыми» страницами.
Правило простое: лаборатория объясняет “почему”, а реальные данные подтверждают “стало ли лучше для большинства”.
Сохраните:
Хорошая привычка — завести одну таблицу «изменение → эффект» и добавлять туда результаты после каждого шага.
Запишите минимум:
Этого набора достаточно, чтобы осмысленно выбрать следующие шаги и проверить результат без самообмана.
Медленная загрузка почти всегда объясняется несколькими повторяющимися причинами. Хорошая новость: большинство из них дают заметный эффект уже после первых правок.
Частый сценарий: на странице стоят фотографии по 3–8 МБ, иногда ещё и в несколько раз больше нужного разрешения. Браузеру приходится скачивать лишнее, а мобильная сеть и слабые устройства «проваливаются» сильнее всего.
Важно: даже один «hero»-баннер наверху страницы может сделать сайт визуально медленным — потому что именно его ждёт пользователь.
Вторая типовая причина — слишком много скриптов: виджеты, аналитика, чаты, A/B‑тесты, а также «тяжёлые» библиотеки, которые подключены «на всякий случай». Итог: страница может скачаться, но долго оставаться неотзывчивой — клики и прокрутка ощущаются с задержкой.
Практическое правило: если функция не влияет на первый экран и первые действия пользователя, ей не место в критическом пути загрузки.
Если сервер долго формирует HTML (например, из‑за базы данных, тяжёлых запросов или отсутствия кэша), тормоз начинается ещё до загрузки картинок и скриптов. Это особенно заметно на главной и страницах со сложными блоками.
Главная обычно самая «нагруженная»: много блоков, слайдеры, спецэффекты, максимум трекинга. А шаблон/общие компоненты (шапка, меню, футер) подключаются на всех страницах. Поэтому один неудачный скрипт в шаблоне замедляет весь сайт, а не одну страницу.
Начинайте с того, что даёт 80% эффекта: изображения первого экрана, самые тяжёлые скрипты, задержки на сервере. Мелкие правки вроде микро‑минификации имеют смысл позже — иначе легко потратить время на незаметный результат.
Делайте изменения по одному, фиксируйте «до/после» и держите быстрый откат. Частые проблемы после оптимизации — поломка верстки из‑за агрессивного объединения файлов, «скачущие» блоки из‑за неправильно заданных размеров, а также отложенная загрузка, которая случайно откладывает важное.
Когда вы открываете страницу, браузер делает две работы параллельно: скачивает ресурсы и пытается как можно раньше показать пользователю осмысленный первый экран. В ускорении почти всегда выигрывает тот, кто быстрее выводит ключевой контент (LCP) и быстрее становится «живым» для действий (INP).
Браузер получает HTML, читает его сверху вниз и по ходу обнаруживает ссылки на CSS, JavaScript, шрифты, изображения. Часть этих файлов нужна, чтобы вообще начать рисовать страницу: это и есть критический путь рендеринга. Если в нём есть тяжёлые или медленные ресурсы, первый экран задерживается даже при хорошем интернете.
CSS часто блокирует отрисовку: пока не загрузится и не применится критичный CSS, браузер не хочет показывать «поломанную» страницу.
JavaScript может блокировать разбор HTML и запуск рендера, если подключён без defer/async или если выполняет много работы на старте. Это бьёт не только по скорости появления первого экрана, но и по отзывчивости — INP.
Раньше объединять всё в один файл было почти универсальным советом. Сейчас HTTP/2/3 позволяют параллельно грузить несколько файлов, и иногда лучше разделить: например, отдать маленький критичный CSS быстро, а остальное догрузить позже. Один огромный бандл может замедлить LCP и ухудшить INP, потому что его нужно скачать, распаковать и выполнить.
До появления первого экрана важно успеть: HTML, критичный CSS, минимально необходимый JS (или вообще без него), а также изображения/шрифты, которые участвуют в LCP-элементе (герой-блок, заголовок, карточка товара). Всё остальное — кандидаты на отложенную загрузку.
Если страница «тяжёлая», чаще всего виноваты изображения: они занимают львиную долю трафика и напрямую влияют на ощущение скорости. Хорошая новость — ускорение здесь обычно даёт самый заметный эффект без переписывания сайта.
Практика: начните с 10–20 самых «тяжёлых» картинок (часто это баннеры и фото в карточках).
Классическая ошибка — загружать огромную картинку и уменьшать её «на глаз» через CSS. Браузер всё равно скачает оригинал.
Правило простое: отдавайте файл примерно под реальный размер отображения, с небольшим запасом под Retina (обычно 2×).
Один файл «на все случаи» почти всегда лишний. Лучше дать браузеру набор вариантов:
<img
src="/images/product-800.webp"
srcset="/images/product-400.webp 400w, /images/product-800.webp 800w, /images/product-1200.webp 1200w"
sizes="(max-width: 600px) 90vw, 600px"
alt="Товар"
>
Так на телефоне не будет скачиваться «настольная» версия.
Для картинок, которые пользователь увидит только после прокрутки, включайте ленивую загрузку:
<img loading="lazy" decoding="async" ...>
Важно: не делайте lazy для главного изображения вверху страницы — это может ухудшить скорость первого экрана.
«Hero» (картинка/баннер в первом экране) часто определяет ощущение быстроты. Что помогает:
<img fetchpriority="high" ...>
Если начать с hero и пары самых популярных страниц, результат по времени загрузки обычно виден сразу.
Шрифты часто «едят» время незаметно: страница уже почти загрузилась, но текст появляется поздно, меняет размер или «прыгает». Улучшения здесь обычно быстрые и не требуют переписывать сайт.
Начните с простого аудита: сколько семейств и начертаний (Regular/Bold/Italic) подключено, и какие языки нужны.
Используйте формат WOFF2 (почти всегда самый компактный). Дальше — subset: шрифт можно «обрезать» до нужных символов (например, только латиница+кириллица без редких знаков). Это уменьшает размер и ускоряет появление текста.
Важно: делайте subset осмысленно — если на сайте есть отзывы, имена или валюты, проверьте, что нужные символы не пропадут.
Добавьте font-display: swap; (или близкие варианты). Тогда браузер покажет текст системным шрифтом сразу, а кастомный подгрузит позже.
Чтобы уменьшить «прыжки» при замене шрифта, используйте метрики (например, size-adjust) или подберите системный шрифт-замену максимально похожий по ширине.
preload помогает, но его легко переиспользовать. Предзагружайте только 1–2 ключевых файла: шрифт основного текста или самый заметный в первом экране.
Для интерфейсных текстов (кнопки, формы, навигация) системные шрифты — это нормально: они быстрые, уже есть у пользователя и отлично читаются. Часто выигрыш в скорости и стабильности верстки важнее «уникальности» типографики.
JavaScript и CSS влияют на скорость не только «весом» файлов. Гораздо важнее, когда они загружаются и мешают ли браузеру показать первый экран. Частая ситуация: страница «скачалась быстро», но пользователь всё равно ждёт, пока скрипты отработают и интерфейс начнёт реагировать.
Минификация CSS/JS (убрать пробелы, сократить имена, упаковать) уменьшает размер, но обычно даёт умеренный эффект.
Сильнее влияет удаление неиспользуемого кода:
Практический ориентир: лучше убрать 100 КБ реально неиспользуемого кода, чем сэкономить 30 КБ минификацией.
Если сайт состоит из разных типов страниц (главная, каталог, карточка товара, блог), им редко нужен один и тот же набор скриптов. Разделение (code splitting) помогает не тащить «всё сразу».
Примеры, что стоит грузить отдельно:
Это уменьшает объём первого запроса и снижает шанс «заморозить» страницу тяжёлым JS.
Самое простое ускорение — перестать блокировать отрисовку.
defer подходит для ваших скриптов, которые нужны после разбора HTML (часто — лучший выбор).async хорошо для независимых скриптов, но порядок выполнения не гарантирован.Типичные ошибки:
async на зависимые скрипты и получают «ломается через раз»;<head> без defer, из-за чего первый экран появляется позже;Чат, аналитика, пиксели, виджеты отзывов и A/B‑тесты часто добавляют десятки запросов и выполняют много JS. Они могут ухудшать отзывчивость: страница визуально готова, но клики «задумываются».
Откройте страницу, выпишите все подключаемые JS/CSS (включая сторонние). Для каждого отметьте: «зачем нужен», «на каких страницах нужен», «можно ли грузить позже». Затем удалите или отключите хотя бы 1–2 пункта без понятной пользы — это часто даёт самый быстрый и заметный результат.
TTFB (Time To First Byte) — это время от клика по ссылке до момента, когда браузер получил первый байт ответа от сервера. Проще: сколько «думает» ваш сервер, прежде чем вообще начать отдавать страницу.
Если TTFB высокий, страница кажется медленной даже при идеальных картинках и CSS: браузер ждёт стартового сигнала.
Обычно виноват не «интернет у пользователя», а задержки внутри цепочки:
Кэш нужен, чтобы не делать одну и ту же работу снова и снова.
Практическое правило: кэшируйте то, что часто запрашивают и редко меняют — TTFB обычно падает заметно.
Без углубления в SQL, есть три частых улучшения:
Уберите лишние запросы: вместо 50 мелких — 1–3 понятных.
Возвращайте меньше данных: не тяните «все поля», если на странице видны только 5.
Следите за индексами для фильтров и сортировок (это один из самых дешёвых способов ускориться).
HTTP/2 обычно ускоряет загрузку за счёт более эффективной передачи множества файлов по одному соединению (особенно заметно на страницах с большим числом мелких ресурсов).
HTTP/3 может помочь на мобильных сетях и при потере пакетов, но эффект зависит от аудитории и инфраструктуры. Главное: эти протоколы не компенсируют медленный бэкенд — они улучшают доставку, а не время «думания».
О смене хостинга стоит думать, если:
Это не магия: более быстрые ресурсы и адекватная конфигурация часто дают прямой прирост именно по TTFB.
Если сайт «тормозит» на втором и третьем визите, часто виновато отсутствие кэширования. Правильно настроенный кэш позволяет браузеру не скачивать одни и те же файлы заново, а CDN — отдавать статику с ближайшего узла и разгружать ваш сервер.
Кэшировать стоит почти всю статику: CSS, JS, шрифты, изображения, иконки. Идеальная схема — «долго кэшируем, но безопасно обновляем»:
app.4f3a1c.js) ставьте долгий срок: Cache-Control: public, max-age=31536000, immutable.main.css) — короче, иначе пользователи будут видеть старую версию: max-age от нескольких минут до дня.Ключевая мысль: долгий кэш работает только если вы гарантируете обновление URL при релизе (хэш в имени, versioning).
CDN особенно полезен, если у вас аудитория из разных регионов или сервер не справляется с пиками. Через CDN логичнее всего отдавать:
Динамический HTML тоже можно отдавать через CDN, но только при чётких правилах кеширования.
Сжатие заметно ускоряет передачу HTML/CSS/JS/JSON.
Проверьте, что сервер реально сжимает ответы: в заголовках должен быть Content-Encoding: br или gzip.
HTML кэшируют аккуратно: на страницах с личным кабинетом, корзиной, разными ценами и персональными блоками легко «раздать чужое». Для таких страниц чаще ставят Cache-Control: no-store.
Для публичных страниц (лендинги, статьи) возможны варианты:
max-age=60…300) + обновление по purge;Самый простой путь — DevTools → Network → клик по файлу → вкладка Headers. Ищите:
Cache-Control (есть ли max-age, public, no-store);ETag или Last-Modified (помогают валидировать кэш);Age и cf-cache-status/аналоги (если используется CDN).Альтернатива из консоли:
curl -I https://example.com/assets/app.4f3a1c.js
Если видите Cache-Control: max-age=0 на статике — это почти всегда быстрый повод для исправления.
Core Web Vitals — это три метрики, которые хорошо отражают «ощущение скорости»: как быстро появляется главный контент, насколько отзывчив интерфейс и не «прыгает» ли страница при загрузке. Часто улучшения находятся в паре очевидных мест.
LCP (Largest Contentful Paint) — время, когда на экране появляется самый крупный видимый элемент (часто это геро‑картинка или крупный заголовок).
Быстрые рычаги:
INP (Interaction to Next Paint) показывает, насколько быстро сайт реагирует на действия пользователя.
Что работает чаще всего:
requestAnimationFrame), откладывайте второстепенное.CLS (Cumulative Layout Shift) растёт, когда элементы неожиданно сдвигаются.
Быстрые исправления:
Сначала LCP и CLS: они обычно дают самый заметный эффект «на глаз».
Затем INP: найдите «длинные задачи» и тяжелые скрипты (часто это аналитика, виджеты, большие бандлы).
Не гонитесь за 100/100: важнее убрать главные узкие места, а не косметические предупреждения.
Сделайте повторный тест тем же способом: тот же URL, устройство/эмуляция, режим (инкогнито, без расширений). Сравните отчёты «до/после» и зафиксируйте изменения: какие метрики улучшились и за счёт чего. Лучше всего хранить результаты в виде короткого журнала работ — так вы не потеряете причинно‑следственную связь.
Ускорение сайта часто начинают с «волшебных» решений и гонки за идеальными цифрами. Это нормально, но именно здесь проще всего потратить время впустую — или даже сломать важные вещи.
Плагины и готовые оптимизаторы действительно помогают — но только в рамках того, что уже позволяет ваш сайт. Они не исправят тяжёлые изображения, медленный хостинг, неэффективные запросы к базе или перегруженный фронтенд.
Главная ошибка — включить все галочки сразу: агрессивная минификация, объединение файлов, отсрочка всего JavaScript, «умная» оптимизация шрифтов. В итоге страница может стать быстрее в тесте, но перестать нормально работать у реальных пользователей.
100/100 — приятная цель, но не обязательная. Важно не «идеально в лаборатории», а заметно лучше для пользователя: чтобы первый крупный элемент появлялся быстро, сайт откликался без задержек, а блоки не прыгали. Иногда последние баллы требуют жертв: отключить полезный виджет, упростить аналитику или ухудшить качество контента.
Частые симптомы:
Если вы используете отложенную загрузку JavaScript, применяйте её точечно: критические скрипты (корзина, авторизация, формы) должны работать сразу.
Оптимизируя скорость, легко навредить другому:
После каждого изменения проверьте руками:
Откатывайте изменение, если оно:
Практика простая: делайте правки по одной, фиксируйте результат и сохраняйте возможность быстро вернуться к рабочей версии.
Чтобы ускорение не превратилось в «сделали что‑то и не уверены, помогло ли», работайте короткими итерациями: один набор изменений → замер → вывод → следующий шаг. Ниже — практичный план на 1–2 недели, который обычно даёт заметный эффект без героизма.
Изображения: сжать и перевести в современные форматы, убрать лишние размеры, включить ленивую загрузку там, где это уместно.
JS/CSS: убрать лишнее, отложить неважное, проверить, что «красивые» эффекты не блокируют первый экран.
Сервер: найти причины долгого ответа (TTFB), оптимизировать запросы/рендер, включить сжатие.
Кэш: настроить заголовки для статики, повторные визиты должны быть быстрее.
Core Web Vitals: точечно добить LCP/INP/CLS тем, что реально мешает пользователю.
Заведите простой лог (таблица или заметка). На каждую правку — одна строка:
Так вы быстро поймёте, какие действия дают прирост, а какие — только шум.
Если есть мониторинг, поставьте алерты на рост TTFB, ухудшение LCP/INP/CLS и резкое увеличение веса страницы.
Автоматизация экономит время и снижает риск регрессий: оптимизация изображений, минификация, проверка лимитов (например, «JS не больше X»), и обязательный отчёт о производительности в CI.
Если вы делаете продукт с нуля или регулярно выпускаете новые страницы, удобно, когда сборка и инфраструктура изначально заточены под скорость. Например, в TakProsto.AI можно собирать веб‑приложения через чат (фронтенд на React, бэкенд на Go с PostgreSQL), а затем быстро деплоить и откатывать изменения через снапшоты/rollback. Это помогает держать «короткий цикл» из этой статьи: правка → замер → вывод — без долгого ручного пайплайна.
Если нужна помощь с внедрением и поддержкой, посмотрите варианты на /pricing или материалы в /blog — там проще выбрать подход по бюджету и команде.
Ориентируйтесь не на одну цифру, а на связку:
Практика: сначала добейтесь ощутимого улучшения на главной/шаблоне и на самом популярном типе страниц — это даст эффект всему сайту.
Можно использовать ориентиры Core Web Vitals:
Для сервера часто берут как сигнал:
Минимальный повторяемый сценарий:
Инструменты по уровню глубины:
Лаборатория (Lighthouse/WebPageTest) полезна, чтобы понять почему медленно: блокирующие ресурсы, тяжёлые файлы, длинные задачи JS.
Полевые данные (CrUX/RUM/аналитика) отвечают на вопрос стало ли лучше у людей: слабые устройства, нестабильная сеть, реальный микс страниц.
Практика: правки находите в лаборатории, а подтверждение эффекта смотрите по полю (или хотя бы по повторным лабораторным прогонам в одинаковых условиях).
Почти всегда самый быстрый выигрыш дают изображения, особенно на первом экране:
loading="lazy" только ниже первого экрана.Начните с 10–20 самых тяжёлых картинок на популярных страницах — эффект обычно виден сразу.
Hero-изображение часто и есть LCP-элемент, поэтому:
loading="lazy".fetchpriority="high".После правки перепроверьте LCP на той же странице и в тех же условиях теста.
Частые «быстрые» шаги:
font-display: swap;, чтобы текст появлялся сразу.preload — только для 1–2 критичных шрифтов.Цель: быстрее показать текст и уменьшить скачки при подгрузке (CLS).
Проверьте два слоя:
defer (часто лучший вариант), а async — только если нет зависимостей и не важен порядок.Быстрые действия:
Самые частые причины:
Что обычно помогает быстро:
Если после этого TTFB всё равно высокий и есть 5xx/нагрузка — возможно, пора усиливать сервер или менять хостинг.
Базовая схема для статики:
app.4f3a1c.js) ставьте:
Cache-Control: public, max-age=31536000, immutablemax-age, иначе будут «залипать» старые версии.CDN имеет смысл, если аудитория географически распределена или есть пики: отдавайте через CDN изображения, CSS/JS, шрифты, загрузки.
Проверка:
Cache-Control, ETag/Last-Modified, признаки CDN (Age, статус кэша).curl -I /path/to/asset.js.