Дружественное руководство для начинающих: что реально улучшает время загрузки сайта — изображения, кеширование, хостинг, код и Core Web Vitals — плюс быстрые шаги для старта.
Когда люди говорят «мой сайт медленный», обычно имеют в виду одно из двух:
«Время загрузки» — это не одно число на секундомере. Страница загружается по этапам: браузер запрашивает файлы (HTML, изображения, шрифты, скрипты), скачивает их, а затем превращает в пригодную для пользования страницу. Можно представить это как открытие магазина: открыть двери, включить свет, расставить товары и, наконец, быть готовым обслуживать клиентов.
Скорость влияет на:
Не нужно 50 микро-оптимизаций. Для большинства сайтов‑начинающих самые большие улучшения даёт короткий список: изображения, слишком много JavaScript/CSS, виджеты третьих сторон и время ответа сервера/хостинг.
Руководство фокусируется на практических, малорисковых шагах, которые реально улучшают загрузку страниц, особенно на мобильных. Мы не будем глубоко погружаться в перестройку архитектуры приложения, создание кастомных кеширующих слоёв или бюджетирование производительности для больших команд. Цель — помочь вам сделать изменения, которые можно закончить и проверить, не ломая сайт.
Когда говорят «мой сайт медленный», обычно имеют в виду три вещи: основной контент появляется поздно, страница кажется тормозной при взаимодействии или макет постоянно прыгает. Core Web Vitals хорошо отражают эти жалобы.
LCP (Largest Contentful Paint): сколько времени нужно, чтобы появился самый большой «основной» элемент (часто hero‑изображение или блок заголовка). При высоком LCP пользователь смотрит на почти пустую страницу.
INP (Interaction to Next Paint): как быстро страница реагирует после взаимодействия пользователя (тап, клик, ввод). При высоком INP сайт кажется «липким» — кнопки реагируют с задержкой, меню открываются не сразу.
CLS (Cumulative Layout Shift): насколько страница смещается во время загрузки. Если текст сдвигается и вы промахнулись по кнопке — это CLS.
TTFB (Time to First Byte) — сколько времени сервер (и всё между) тратит, чтобы начать что‑то отправлять в ответ. Медленный TTFB задерживает всё остальное: изображения не начнут скачиваться, шрифты не загрузятся, и LCP обычно ухудшается. Проблемы с TTFB часто указывают на хостинг, тяжёлую серверную логику или отсутствие кеширования.
Лаб‑тесты (Lighthouse и т. п.) симулируют загрузку в заданных условиях. Они хороши для отладки и сравнений «до/после».
Данные реальных пользователей (field data, например CrUX в PageSpeed Insights) отражают то, что видят посетители на разных устройствах и сетях. Именно это важнее всего для вопроса: «Кажется ли сайт быстрым для реальных людей?»
Если начать оптимизировать без точки отсчёта, легко потратить время впустую — или случайно сделать сайт медленнее. Потратьте 20 минут на измерения сначала, и вы увидите, какие изменения помогли.
Используйте PageSpeed Insights для быстрого снимка. Инструмент отдаёт field data (опыт реальных пользователей, если доступен) и lab data (симулированный тест). Обратите внимание на:
Для более глубокого лабораторного теста используйте Lighthouse в Chrome:
Когда нужно увидеть, что замедляет страницу, WebPageTest даёт один из самых наглядных отчётов. Вид waterfall показывает каждый загружаемый файл в порядке — HTML, изображения, шрифты, скрипты и сторонние теги — и где браузер ждёт.
Начните с одной ключевой страницы (главная или целевая) и тестируйте:
Фиксируйте для каждого теста:
Ведите небольшой лог (подойдёт таблица): дата, инструмент, URL, результаты и что изменили. Меняйте только одну–две вещи за раз, затем повторно тестируйте в тех же условиях.
Если вы работаете с приложением (не только статическим сайтом), полезно иметь безопасный способ выкладки и отката экспериментов по производительности. Платформы вроде Koder.ai (генерируют и хостят React/Go приложения из чат‑рабочего процесса) полезны, потому что позволяют делать снимки, тестировать изменения и быстро откатываться, если «фиксы» сломали UX.
Медленные страницы редко вызваны одной загадочной проблемой. Обычно это набор «веса и задержки», которые накапливаются — особенно на мобильных.
Изображения часто — самая тяжёлая часть страницы. Один неправильно экспортированный hero может добавить мегабайты и секунды.
Частые виновники:
JavaScript может задерживать момент, когда страница становится пригодной к использованию. Даже если страница «появилась», она может казаться медленной, пока скрипты загружаются, парсятся и выполняются.
Часто виноваты скрипты третьих сторон: виджеты чата, поп‑апы, тепловые карты, A/B‑тесты, рекламные теги и встраивания социальных сетей. Каждый из них добавляет сетевые вызовы и может задерживать критическую работу браузера.
Иногда браузер ждёт ответа сервера, прежде чем начать загрузку страницы. Это ощущается как медленный начальный отклик (TTFB). Причины: слабый хостинг, нагруженные базы данных, неоптимизированные темы/плагины или страницы, которые строятся динамически при каждом запросе.
Если сайт заставляет каждый визит начинать с нуля, повторные посетители платят за это. Без кеширования сервер пересобирает страницы, а браузер заново скачивает редко меняющиеся файлы.
Кроме того, множество мелких файлов (шрифты, скрипты, стили, трекеры) создают «перегрузку запросов». Даже если каждый файл маленький, суммарное время ожидания накапливается.
Хорошая новость: эти причины исправимы — и обычно самые большие выгоды вы получите, устранив их в этом порядке.
Если можно сделать только одно улучшение — займитесь изображениями. На многих сайтах‑для‑начинающих изображения составляют большую часть «веса» страницы, особенно на мобильных. Хорошая новость: исправления с изображениями обычно безопасны, быстры и не требуют изменения дизайна.
Распространённая ошибка — загрузить огромное фото (например, 4000px) и показывать его в 800px. Браузеру всё равно придётся скачать большой файл.
Экспортируйте изображения близко к максимально возможной ширине их показа. Например, если область контента блога 800px, не загружайте 3000–4000px «на всякий случай».
JPEG/PNG всё ещё работают, но современные форматы дают сопоставимое качество при меньшем размере файла.
Если CMS или плагин автоматически отдают WebP/AVIF с запасными вариантами, это идеальный вариант.
Сжатие даёт большинство немедленных выигрышей. «Визуально идентичное» изображение часто можно уменьшить на 30–70%.
Уберите метаданные (информацию о камере, геолокацию) — они не меняют вид, но добавляют байты.
Практическое правило: сжимайте до появления заметного падения качества, затем вернитесь на шаг выше по качеству.
srcset) для мобильных и десктопаМобильным пользователям не нужно скачивать десктопные версии. Адаптивные изображения позволяют браузеру выбрать подходящий размер по ширине экрана.
Если ваш сайт генерирует несколько размеров автоматически, убедитесь, что тема использует их корректно. В HTML вы ищете что‑то вроде srcset (несколько версий), а не один гигантский файл.
Перед переходом к минификации кода проверьте только топ‑изображения:
Делайте эти четыре вещи последовательно — и скорость сайта обычно улучшится сразу, часто настолько, что Core Web Vitals пойдут в нужную сторону.
Lazy loading откладывает скачивание некоторых изображений (и iframe) до тех пор, пока они не приблизятся к видимой области. Это сокращает начальное время загрузки, потому что браузер не тянет всё сразу — особенно полезно на длинных страницах с множеством изображений ниже сгиба.
Lazy loading особенно хорош для:
Правильно применённый, он уменьшает «работу в начале» и делает страницу быстрее.
Самое большое изображение выше сгиба — часто hero. Если ленивить его, браузер может слишком поздно запросить ресурс, и это повредит LCP.
Правило: никогда не ленивите главное hero‑изображение или критичные элементы первого экрана (изображение заголовка, основной фото продукта, верхний баннер).
Lazy loading может вызвать «прыжки», когда изображения появляются. Чтобы избежать CLS, всегда резервируйте пространство:
width и height для изображений, илиТак макет остаётся стабильным, пока загружается картинка.
Если изображение или шрифт критичны для первого впечатления, рассмотрите preload, чтобы браузер забрал их раньше. Используйте это экономно — предзагрузка слишком большого числа ресурсов может навредить, отнимая полосу пропускания.
Если хотите чек‑лист, комбинируйте это с шагом измерения в /blog/how-to-measure-site-speed-before-you-change-anything.
Кеширование — это способ браузера сказать: «Я уже скачивал это — могу ли я повторно использовать?» Вместо того чтобы заново скачивать логотип, CSS или бандл JavaScript при каждом просмотре, браузер хранит локальную копию на время. Это делает повторные визиты заметно быстрее и экономит трафик — особенно на мобильных.
Когда ваш сайт отправляет файл (например, styles.css или app.js), он может также послать инструкцию, как долго файл можно переиспользовать. Если браузеру разрешено хранить его, скажем, 30 дней, при следующем визите эти файлы загрузятся мгновенно с устройства, а не с сервера.
Это не ускорит самый первый визит, но сильно улучшит:
Статичные файлы — это то, что редко меняется: изображения, CSS, JavaScript, шрифты. Их можно кешировать долго.
Что логично:
Ваш хост, CMS или фреймворк может предлагать простой переключатель «кеш статичных активов». Если есть разработчик, попросите настроить Cache-Control заголовки для активов.
Как обеспечить обновления при длинном кэше? Используйте версионированные имена.
Вместо постоянного app.js ваш билд может выдавать:
app.3f2a1c.jsstyles.a81b09.cssКогда контент меняется, меняется и имя файла, и браузер скачивает новую версию, в то время как старые версии остаются закешированы.
Сервис‑воркеры позволяют сайту более тонко контролировать, что и когда хранится, иногда обеспечивая офлайн‑режим. Но они могут вызывать «устаревший контент», если реализованы неверно. Для начинающих — вариант для продвинутых с опытным сопровождением.
CDN (Content Delivery Network) — это набор серверов в разных регионах, которые могут отдавать файлы ближе к посетителю. Вместо того чтобы каждый запрос шел на ваш один сервер, многие запросы обрабатываются «рядом» с пользователем.
CDN лучше всего ускоряет статичные активы — изображения, CSS, JavaScript, шрифты и видео. Эти файлы копируются на edge‑серверы и переиспользуются для многих посетителей.
Кому особенно полезен CDN: сайтам с аудиторией в разных городах/странах, медиа‑тяжёлым ресурсам и бизнесам с платным трафиком по миру.
Расстояние добавляет задержку. Если ваш сервер в одной стране, а посетитель — на другом континенте, каждый запрос идёт дольше. CDN уменьшает задержку, отдавая кэш с сервера ближе к пользователю, что обычно улучшает время загрузки и может помочь Core Web Vitals — особенно на мобильных сетях.
Неправильные заголовки кеша могут полностью отключить кеширование (или наоборот — сделать его слишком долгим). Обратная проблема — «устаревший кеш»: вы обновили файл, а посетители всё ещё получают старую версию. Решение — версионирование имён и изучение функции purge у CDN.
CDN не заменит исправление тяжёлых изображений или раздутых скриптов, но станет сильным умножителем, когда базовые вещи уже оптимизированы.
CSS и JavaScript часто — «невидимый вес», который замедляет страницу. В отличие от изображений, проблему не всегда видно, но браузер всё равно скачивает, парсит и выполняет эти файлы.
Минификация убирает пробелы, комментарии и форматирование. Это уменьшает размер файлов и ускоряет загрузку.
Что она делает: уменьшает размер файла.
Чего она не делает: не снижает объём работы по разбору и выполнению кода. Если скрипты много делают при загрузке, минификация этого не решит — потому рассматривайте её как быстрый выигрыш, но не полное решение.
Многие сайты грузят «универсальную» таблицу стилей с правилами для всех страниц и компонентов. Этот лишний CSS всё равно скачивается и может замедлять рендеринг.
Практический подход:
Цель проста: главная страница не должна тащить вес всего сайта.
Некоторые скрипты блокируют страницу от становления интерактивной, потому что браузер останавливается, чтобы их выполнить.
defer обычно лучше для собственных скриптов, которые могут подождать, пока HTML распарсится.async подходит для независимых скриптов (часто сторонних), которые не зависят от других.Если не уверены, начните с откладывания всего, что не нужно для первого экрана (меню, анимации, слайдеры, дополнительные трекеры).
Крупные библиотеки могут добавить сотни килобайт. Перед подключением ещё одного плагина спросите:
Меньше скриптов — меньше сюрпризов, особенно на мобильных, где время CPU столь же важно, как и размер скачивания.
Скрипты третьих сторон — всё, что загружается с серверов других компаний. Они популярны: быстро дают функции, но часто становятся самыми непредсказуемыми причинами замедления.
Наиболее распространённые:
Эти скрипты загружают дополнительные файлы, выполняют много JS и иногда блокируют завершение загрузки страницы.
Откройте Chrome DevTools → Performance, запишите загрузку страницы и смотрите на:
Также Lighthouse даст рекомендации в разделе «Reduce JavaScript execution time» и «Eliminate render-blocking resources».
Несколько простых приёмов для начинающих:
Вместо подгрузки полного YouTube/Facebook/Map встраивания при загрузке, показывайте простое превью (миниатюра + кнопка «воспроизвести»). Реальное встраивание загружайте только по клику.
Так вы сохраняете функциональность без ущерба для скорости — особенно на мобильных.
TTFB — это время, которое проходит с момента запроса страницы до первого байта ответа от сервера. Это «как долго кухня начинает готовить», а не «как долго сервируется полный обед».
Красивый фронтенд всё ещё может казаться медленным при высоком TTFB — особенно в мобильных сетях, где каждая задержка заметнее.
TTFB зависит от серверной работы до отправки ответа:
Даже при оптимизированных изображениях и скриптах медленный сервер оставит пользователя перед пустым экраном.
Если сайт на CMS или генерируется динамически, серверное кеширование часто даёт самый большой прирост по TTFB. Вместо пересборки страницы для каждого посетителя сервер хранит готовую версию.
Примеры:
Включите Brotli (предпочтительно) или Gzip для текстовых файлов (HTML, CSS, JS). Это уменьшает передаваемый объём данных и улучшает воспринимаемую скорость, особенно при повторных загрузках и на мобильных.
Лучше сначала исправить явные фронтенд‑проблемы (огромные изображения, много сторонних скриптов, тяжёлый JS). Если браузер скачивает мегабайты, более быстрый хостинг не сделает сайт по‑настоящему быстрым.
После базовой оптимизации апгрейд хостинга (больше CPU/RAM, настроенная база, лучшая runtime‑оптимизация) может быть окончательным шагом к стабильной отзывчивости.
Если вы создаёте продукт и хотите меньше переменных с хостингом с самого начала, рассмотрите управляемые платформы с хорошими настройками по умолчанию. Например, Koder.ai хостит приложения глобально на AWS, поддерживает деплой, кастомные домены и откаты окружения — удобно при тестировании изменений производительности по регионам или при соблюдении требований к размещению данных.
Не нужен огромный план — нужен простой порядок действий, возможность подтвердить, что вы не ухудшили ситуацию, и склонность к надёжным фиксам.
День 1: измерьте (до изменений).
Выберите 2–3 ключевые страницы (главная, целевая, популярный пост/карточка товара). Запустите:
Запишите базовые показатели мобильной и десктопной версии. Если возможно, протестируйте на реальном телефоне по сотовой сети — часто там видно то, что скрывают лабораторные тесты.
Дни 2–3: исправляйте изображения (самый быстрый и надёжный выигрыш).
Приоритеты:
Повторно тестируйте после обновления нескольких изображений, чтобы увидеть эффект.
Дни 4–5: настройте кеширование (повторные визиты быстрее).
Включите базовое браузерное и серверное/страничное кеширование там, где это уместно. Цель — не пересобирать и не перезагружать одни и те же ресурсы при каждом визите. Проверьте, что возврат на страницу стал заметно быстрее.
Дни 6–7: сокращайте JavaScript (долговременный выигрыш).
Ищите:
Небольшие изменения здесь сильно улучшают интерактивность и Core Web Vitals, особенно на мобильных.
После каждого крупного изменения делайте три быстрые проверки:
Если вы уже оптимизировали изображения и кеш и всё ещё наблюдаете постоянно высокий TTFB, это чаще всего про хостинг, конфигурацию сервера или тяжёлую backend‑логику. Также стоит привлекать специалистов, если ваш сайт — сложное приложение (сайты с членством, маркетплейсы, много персонализации), где «просто закешировать» недостаточно.
Если хотите углубиться в серверное время ответа, смотрите /blog/ttfb-explained.
Скорость сайта обычно означает два момента:
Страница может «выглядеть загруженной», но при этом быть медленной, если JavaScript занят или макет прыгает.
Core Web Vitals соответствуют типичным жалобам пользователей:
Улучшение этих метрик обычно улучшает восприятие скорости, а не только оценку в инструменте.
Используйте эти практические целевые значения:
Рассматривайте их как ориентиры — сначала улучшайте самые худшие метрики.
Начните с базовой отправной точки, чтобы не угадывать:
Фиксируйте устройство, сеть, регион, точный URL и меняйте по 1–2 вещи перед новым тестом.
Чаще всего основные причины:
Исправление этих проблем в указанном порядке обычно даёт быстрые выигрыши.
Потому что изображения часто составляют большую часть веса страницы и напрямую влияют на время загрузки и LCP. Сфокусируйтесь на четырёх базовых вещах:
Lazy loading полезен для контента ниже первого экрана, но может навредить LCP при неправильном использовании.
Практические правила:
Кеширование ускоряет повторные визиты:
app.3f2a1c.js), чтобы обновления не застревали в кэше.Правильно настроенное кеширование уменьшает повторную загрузку и нагрузку на сервер, не ломая обновления.
CDN особенно полезен, если у вас аудитория по разным регионам и много статичных файлов.
Он хорошо подходит для:
На что обращать внимание:
CDN не заменит оптимизацию тяжёлых изображений и скриптов, но хорошо умножает эффект после базовой оптимизации.
Используйте простой последовательный план, который можно завершить и проверить:
srcset), чтобы мобильные устройства получали меньшие файлы.Эти изменения обычно низкорискованные и быстро измеримы.
widthheightЕсли элемент критичен для первого экрана, рассмотрите его предзагрузку (preload) экономно.
После каждого шага прогоняйте те же тесты и кликайте по сайту, чтобы убедиться, что ничего не сломано.