Редакция WebOptimize 
1 июля 2026 
16 минут Как ускорить загрузку сайта: разбор механики изнутри
Оглавление:
- Почему скорость загрузки стала критичным фактором: история и контекст
- Как браузер загружает страницу: механика изнутри
- Ключевые метрики скорости: что измерять и почему
- 7 главных причин медленной загрузки и как их устранить
- Реальные кейсы: до и после оптимизации с конкретными цифрами
- Частые ошибки при оптимизации скорости: что идёт не так
- Серверная vs клиентская оптимизация: что выбрать и когда
- Пошаговый план: как ускорить загрузку сайта самостоятельно
- Заключение
- Часто задаваемые вопросы
Почему скорость загрузки стала критичным фактором: история и контекст
Кратко:
- Скорость загрузки влияет на ранжирование в Яндексе и Google одновременно: медленный сайт теряет позиции независимо от качества контента.
- Переход пользователей на мобильные устройства сделал требования к скорости жёстче: мобильный интернет нестабилен, и каждая лишняя секунда загрузки увеличивает отказы.
- Медленный сайт — это не только SEO-потеря, но и прямой удар по конверсии: пользователь уходит к конкуренту раньше, чем страница успевает загрузиться.
- Оптимизация скорости стала обязательной частью технической оптимизации сайта, а не опциональной настройкой «для перфекционистов».
Скорость загрузки сайта — это характеристика, которая измеряет время от отправки запроса браузером до момента, когда пользователь может взаимодействовать со страницей. Она влияет одновременно на поведение пользователей, конверсию и позиции в поисковой выдаче.
Ещё десять лет назад скорость сайта была «приятным бонусом». Сегодня это базовое требование — и поисковые системы это прямо зафиксировали. В 2018 году Google официально включил скорость загрузки в факторы ранжирования для мобильного поиска в рамках обновления Speed Update Google Search Central — Speed Update, 2018. Яндекс пошёл другим путём: скорость влияет на ранжирование через поведенческие сигналы — если пользователь уходит обратно в выдачу через несколько секунд после перехода на сайт, это фиксируется как отказ и снижает релевантность страницы.
Механика этой связи проста. Браузер запрашивает страницу, пользователь ждёт. Если ожидание затягивается — часть аудитории уходит, не дождавшись. Поисковая система видит: переходы с выдачи на этот сайт заканчиваются быстрым возвратом. Страница получает сигнал низкой удовлетворённости запроса. Позиции проседают.
Исследования Amazon и Google зафиксировали прямую связь между задержкой загрузки и конверсией: каждые 100 миллисекунд дополнительной задержки снижают конверсию на несколько процентных пунктов. Конкретные цифры варьируются по нишам, но направление зависимости устойчиво — чем медленнее сайт, тем меньше продаж и заявок.
Главным драйвером ужесточения требований стал мобильный трафик. Мобильные сети нестабильны по определению: скорость соединения меняется в зависимости от местоположения, загруженности вышки, типа сети. Сайт, который нормально открывается на десктопе за пару секунд, на мобильном устройстве в метро может грузиться вдвое дольше. Аудитория к этому не адаптировалась — терпение пользователей не выросло вместе с объёмом мобильного трафика.
Как браузер загружает страницу: механика изнутри
Браузер не просто «открывает страницу» — он проходит строго определённую последовательность шагов, и каждый из них добавляет время до момента, когда пользователь видит что-то на экране.
Цепочка начинается ещё до того, как браузер отправит первый запрос. DNS-резолвинг преобразует доменное имя в IP-адрес сервера. Затем устанавливается TCP-соединение — трёхэтапное рукопожатие (SYN → SYN-ACK → ACK). Если сайт работает по HTTPS, поверх TCP добавляется TLS-хендшейк: браузер и сервер договариваются о шифровании, обмениваются сертификатами. Только после этого браузер отправляет HTTP-запрос и начинает получать HTML-документ.
Получив HTML, браузер разбирает его в DOM (объектную модель документа). Параллельно он обнаруживает ссылки на CSS и JavaScript и запрашивает их. Здесь возникает первая серьёзная проблема — блокирующий рендеринг (render-blocking). CSS в <head> браузер обязан загрузить и обработать до отрисовки страницы: без таблицы стилей он не знает, как выглядит контент. JavaScript по умолчанию тоже блокирует парсинг HTML — браузер останавливается, выполняет скрипт и только потом продолжает. Итог: пока не загрузятся все блокирующие ресурсы, пользователь видит белый экран.
Путь от первого байта HTML до момента, когда пользователь видит отрисованную страницу, называют критическим путём рендеринга (Critical Rendering Path). Именно он определяет воспринимаемую скорость — то, насколько быстро сайт кажется загрузившимся, а не то, когда завершилась полная загрузка всех ресурсов. Браузер фиксирует два ключевых события: DOMContentLoaded — HTML разобран, DOM построен, блокирующие скрипты выполнены; и Load — загружены все ресурсы, включая изображения и iframe. Разрыв между этими событиями может составлять несколько секунд на тяжёлых страницах.
Чтобы сократить критический путь, браузер поддерживает механизмы предзагрузки ресурсов:
- preload — сообщает браузеру, что ресурс нужен немедленно (например, шрифт или hero-изображение):
<link rel="preload">. Браузер загружает его с высоким приоритетом параллельно с парсингом HTML. - preconnect — заранее устанавливает TCP/TLS-соединение с внешним доменом (CDN, шрифты Google Fonts, аналитика). Экономит время на DNS + TCP + TLS при первом запросе к этому домену.
- prefetch — загружает ресурс с низким приоритетом в фоне, когда браузер свободен. Используется для ресурсов следующей страницы, а не текущей.
Протокол HTTP/2 радикально изменил механику загрузки: в отличие от HTTP/1.1, он передаёт несколько запросов по одному TCP-соединению одновременно (мультиплексирование). HTTP/1.1 открывал несколько параллельных соединений, но каждое требовало своего TCP/TLS-хендшейка. HTTP/3 идёт дальше — использует протокол QUIC поверх UDP, что устраняет проблему блокировки очереди (head-of-line blocking) и ускоряет соединение на нестабильных сетях, характерных для мобильного интернета.
defer/async к скриптам убирает блокировку рендеринга без изменений на сервере. Это первое, что проверяют при аудите скорости.
Ключевые метрики скорости: что измерять и почему
Скорость загрузки — не единственная метрика, и измерять «просто скорость» бессмысленно. У каждого этапа загрузки есть своя метрика, и каждая из них отвечает на конкретный вопрос: когда сервер ответил, когда пользователь увидел первый контент, когда страница стала стабильной.
Шесть метрик, которые реально нужны в работе:
- TTFB (Time to First Byte) — время от отправки запроса до получения первого байта от сервера. Это серверная метрика: она показывает, как быстро бэкенд генерирует ответ. Высокий TTFB сигнализирует о проблемах на стороне хостинга, базы данных или отсутствии кэширования — и никакая клиентская оптимизация это не исправит.
- FCP (First Contentful Paint) — момент, когда браузер отрисовал первый видимый элемент: текст, изображение или SVG. Пользователь получает сигнал «загрузка идёт». Если FCP затягивается, человек видит белый экран и уходит, не дождавшись контента.
- LCP (Largest Contentful Paint) — отрисовка самого крупного элемента в области просмотра: обычно это главный баннер, заголовок или изображение. Это ближайший аналог «воспринимаемой скорости»: именно LCP пользователь ощущает как момент, когда страница «загрузилась».
- TBT (Total Blocking Time) — суммарное время, в течение которого главный поток браузера был заблокирован скриптами и не мог реагировать на действия пользователя. Высокий TBT — страница выглядит загруженной, но клики не работают. Это типичная проблема сайтов с тяжёлыми JS-бандлами.
- CLS (Cumulative Layout Shift) — стабильность вёрстки при загрузке. Метрика фиксирует, насколько элементы смещаются после отрисовки: появляется баннер и сдвигает текст вниз, изображение без заданных размеров «прыгает» при загрузке. Высокий CLS — пользователь промахивается по кнопкам и теряет место на странице.
- Speed Index — визуальная скорость заполнения экрана. В отличие от LCP, Speed Index учитывает, как быстро заполняется весь первый экран в целом, а не только один элемент. Полезен при сравнении двух версий страницы: одна может иметь одинаковый LCP, но заметно лучший Speed Index за счёт прогрессивной загрузки.
Взаимосвязь между метриками нелинейная. TTFB влияет на FCP: если сервер отвечает медленно, браузер просто ждёт и не может начать рендеринг. FCP и LCP могут расходиться на секунды — например, если первый контент это небольшой текстовый заголовок, а главный баннер грузится из медленного CDN. TBT и CLS независимы от скорости загрузки файлов: страница может грузиться быстро, но иметь высокий TBT из-за тяжёлого JavaScript или высокий CLS из-за шрифтов без font-display.
Где смотреть эти метрики в российских реалиях — вопрос инструментария. Яндекс.Метрика собирает реальные данные пользователей: отчёт «Скорость сайта» показывает медианные значения по устройствам и браузерам на реальном трафике сайта. Это полевые данные, а не синтетика. PageSpeed Insights даёт синтетический тест плюс данные из Chrome UX Report — полезен для разовых проверок и сравнения с конкурентами. WebPageTest позволяет запустить тест с конкретного региона и увидеть waterfall-диаграмму: какой ресурс сколько времени занял и что блокировало рендеринг.
| Метрика | Что измеряет | Где проблема, если высокое значение |
|---|---|---|
| TTFB | Ответ сервера | Хостинг, база данных, отсутствие кэша |
| FCP | Первый видимый контент | Блокирующие CSS/JS в <head>, медленный TTFB |
| LCP | Главный элемент страницы | Тяжёлые изображения, медленный CDN, lazy load на hero-баннере |
| TBT | Блокировка главного потока | Тяжёлые JS-бандлы, сторонние скрипты аналитики и виджетов |
| CLS | Стабильность вёрстки | Изображения без размеров, шрифты без font-display, динамические баннеры |
| Speed Index | Визуальное заполнение экрана | Поздняя отрисовка контента выше линии сгиба |
Для регулярного мониторинга удобнее всего настроить веб-аналитику с автоматическим отслеживанием скоростных метрик — тогда деградация заметна сразу после деплоя, а не через неделю, когда позиции уже просели.
7 главных причин медленной загрузки и как их устранить
Медленный сайт почти всегда имеет несколько причин одновременно — чаще это комбинация из трёх-пяти факторов, каждый из которых добавляет свои миллисекунды. Ниже — семь причин, которые встречаются чаще всего, и конкретные шаги по устранению каждой.
- Тяжёлые неоптимизированные изображения — самая частая причина. PNG и JPEG весом в несколько мегабайт грузятся дольше всего и раздувают LCP. Решение: конвертировать в WebP со сжатием, задать атрибуты
widthиheight, добавитьloading="lazy"для картинок ниже первого экрана. - Блокирующие рендеринг CSS и JavaScript. Стили и скрипты в
<head>останавливают отрисовку, пока не загрузятся. Решение: вынести критический CSS инлайном, остальной загружать асинхронно, а скриптам добавитьdeferилиasync. - Медленный ответ сервера — высокий TTFB. Если бэкенд «думает» над каждым запросом, никакая клиентская оптимизация это не исправит. Решение: серверное кэширование, оптимизация запросов к базе, при нехватке ресурсов — переезд на выделенный хостинг.
- Отсутствие сжатия текстовых ресурсов. HTML, CSS и JS без сжатия передаются в разы тяжелее. Решение: включить на сервере Brotli — или Gzip, если Brotli недоступен.
- Нет кэширования на стороне браузера. Пользователь при каждом визите заново скачивает статику, которая не менялась. Решение: настроить директивы кэша для CSS, JS и изображений через
.htaccessилиnginx.conf. - Раздача статики с одного сервера без CDN. Аудитория из других регионов ждёт ответа с удалённого сервера. Решение: подключить CDN — файлы отдаются с ближайшего к пользователю узла.
- Внешние шрифты и сторонние скрипты. Запросы к серверам шрифтов, чатам и виджетам блокируют отрисовку и зависят от чужой доступности. Решение: перенести шрифты на свой сервер с
font-display: swap, использоватьpreconnectк нужным доменам, а виджеты грузить отложенно.
Реальные кейсы: до и после оптимизации с конкретными цифрами
Три кейса из практики — с конкретными числами, ошибками и шагами, которые реально дали результат.
Кейс 1. Интернет-магазин на 1С-Битрикс: изображения и CDN
Магазин одежды, около 4 000 карточек товаров. Метрика показывала высокий показатель отказов (Bounce Rate) на мобильных устройствах, конверсия в корзину была заметно ниже, чем на десктопе. Замер через PageSpeed Insights выявил проблему сразу: LCP (Largest Contentful Paint, метрика отрисовки главного элемента) — 6,2 секунды. Причина — PNG-изображения весом по 2–4 МБ, без сжатия и без атрибута loading="lazy". CDN не был подключён: все ресурсы отдавались с одного сервера в Москве, а аудитория была распределена по регионам.
Сделали три вещи: конвертировали все изображения в WebP со сжатием без потери качества, добавили loading="lazy" на карточки ниже первого экрана, подключили CDN с точками присутствия в крупных городах. LCP опустился до 2,1 секунды. По данным Яндекс.Метрики, конверсия из карточки в корзину выросла на 12% за следующие четыре недели. Позиции в мобильной выдаче Яндекса подтянулись через три недели после изменений.
Ошибка, которую допускают почти все: CDN подключают, но забывают прогреть кэш после деплоя. В первые часы после подключения пользователи всё равно получают «холодные» ответы — важно форсировать прогрев через API CDN или просто пройтись по ключевым страницам вручную.
Кейс 2. Новостной портал на WordPress: TTFB и Redis
Региональный новостной портал, около 50 000 материалов в базе. TTFB (Time to First Byte) составлял 800 мс — сервер думал почти секунду до первого байта. Shared-хостинг с ограниченным объёмом оперативной памяти: каждый запрос к странице генерировал полный PHP-цикл с обращением к MySQL, даже если страница не менялась последние три часа.
Решение состояло из двух шагов: переезд на VPS с выделенными ресурсами и настройка Redis-кэша для объектного кэширования WordPress. Redis хранит результаты тяжёлых запросов к базе данных в оперативной памяти — при повторном обращении PHP не идёт в MySQL, а забирает готовый результат напрямую. После переезда и настройки TTFB упал до 180 мс. Яндекс.Бот начал обходить сайт заметно активнее — это видно в разделе «Краулинг → Статистика обхода» в Яндекс Вебмастере Яндекс Вебмастер — статистика обхода: количество страниц, обходимых за сутки, выросло примерно вдвое.
Типичная ошибка при настройке Redis на WordPress — не выносить в исключения страницы корзины, личного кабинета и авторизации. Если кэшировать их, пользователи видят чужие данные или устаревшее состояние корзины. Для плагина Redis Object Cache это настраивается через wp-config.php.
Кейс 3. Лендинг услуг: блокирующий рендеринг шрифтов
Landing Page юридической компании. FCP (First Contentful Paint) — 3,4 секунды, хотя страница была лёгкой по весу. Причина нашлась в Screaming Frog: шрифты подключались через внешний запрос к серверам Google Fonts с атрибутом render-blocking (блокирующий рендеринг). Браузер ждал ответа от внешнего сервера, прежде чем отрисовать хоть что-то на экране. При медленном или нестабильном соединении это давало задержку в 1,5–2 секунды только на шрифтах.
Решение — перенос шрифтов на собственный сервер (self-hosting). Шрифтовые файлы скачали, разместили на домене клиента, в CSS заменили @import url(fonts.googleapis.com/...) на локальный @font-face с атрибутом font-display: swap. Последнее позволяет браузеру сначала показать текст системным шрифтом, а потом подменить его на загруженный — без блокировки рендеринга. FCP упал до 1,2 секунды.
Дополнительный эффект: исчезла зависимость от доступности внешнего сервера. Если серверы Google Fonts недоступны или медленно отвечают — страница теперь не зависит от этого.
Частые ошибки при оптимизации скорости: что идёт не так
Оптимизация скорости — одна из немногих областей в SEO, где «сделал, но стало хуже» встречается регулярно. Причина почти всегда одна: правки делаются под инструмент, а не под реального пользователя.
- Погоня за баллами PageSpeed вместо реального опыта. PageSpeed Insights показывает лабораторные данные — синтетический замер в контролируемых условиях. Реальный пользователь приходит с другим устройством, другим соединением и другим кешем. Команды часто тратят недели на подъём балла с 68 до 90 в лаборатории, тогда как полевые данные (field data) в Яндекс.Метрике не меняются вовсе. Смотрите на отчёт «Скорость сайта» в Метрике — там реальные пользователи, а не симулятор.
-
Lazy loading на изображениях выше линии сгиба. Это одна из самых распространённых ошибок после выхода атрибута
loading="lazy". Разработчик ставит его на все изображения скопом — в том числе на главный баннер или первый экран. Браузер откладывает загрузку этих изображений, и LCP (Largest Contentful Paint, метрика отрисовки главного элемента) резко ухудшается. Правило простое: изображения в зоне первого экрана грузятся безloading="lazy", всё ниже — с ним. - Агрессивная минификация и бандлинг JavaScript. Минификация убирает пробелы и переименовывает переменные. Звучит безопасно, но агрессивные настройки некоторых сборщиков ломают зависимости между модулями. Особенно уязвимы сторонние виджеты, встроенные скрипты аналитики и компоненты с динамическими именами. Итог: сайт получает высокий балл в тесте, а корзина или форма заявки перестают работать у части пользователей.
-
Перенос всех скриптов в
<footer>без анализа зависимостей. Совет «перенеси скрипты в конец страницы» верен для независимых аналитических счётчиков. Но если скрипт нужен для рендеринга элементов выше — перенос приводит к тому, что блоки появляются с задержкой или не появляются вовсе. Перед переносом проверьте каждый скрипт: он нужен до DOMContentLoaded или после? - CDN без правильной инвалидации кеша. CDN кеширует статику на edge-серверах по всему миру. Если после обновления сайта не сбросить кеш вручную или не настроить правила инвалидации, пользователи продолжают получать устаревшие версии CSS, JS или изображений. Особенно болезненно это проявляется после редизайна: браузер рисует новый HTML со старыми стилями.
- Оптимизация только под десктоп. Большинство инструментов по умолчанию показывают десктопный замер — он выглядит лучше, и его удобнее демонстрировать клиенту. Между тем на большинстве коммерческих сайтов мобильный трафик составляет значительную долю сессий. Медленная мобильная версия напрямую влияет на показатель отказов и конверсию — именно её данные стоит смотреть в первую очередь в Яндекс.Метрике через сегментацию по типу устройства.
Серверная vs клиентская оптимизация: что выбрать и когда
Серверная и клиентская оптимизация решают разные проблемы, и смешивать их в одну задачу — типичная ошибка. Сервер отвечает за то, что происходит до момента, когда браузер получил первый байт. Клиентская часть — за всё, что браузер делает после.
Серверная оптимизация работает один раз и сразу для всех пользователей: настроил HTTP/2, включил кэширование, подключил CDN — и каждый запрос проходит быстрее. Клиентская требует точечных правок под конкретные ресурсы: минификация CSS, отложенная загрузка (lazy load), перенос скриптов через defer/async, выделение критического CSS. Эффект точечный, но суммарно ощутимый.
Диагностика через PageSpeed Insights даёт первую подсказку: если TTFB высокий — начинать нужно с сервера, не с браузера. Оптимизировать JS-бандл на сайте с медленным хостингом — всё равно что красить стены в протекающем доме. Сначала устраняют причину, потом следствие.
| Параметр | Серверная оптимизация | Клиентская оптимизация |
|---|---|---|
| Что решает | Высокий TTFB, медленный ответ сервера, отсутствие кэша | Долгий рендеринг, блокирующие скрипты, тяжёлые ресурсы |
| Инструменты | CDN, HTTP/2, серверное кэширование, оптимизация базы данных | Минификация CSS/JS, defer/async, lazy load, критический CSS |
| Трудозатраты | Разовая настройка, требует доступа к хостингу/серверу | Регулярная работа с кодом, зависит от CMS и разработчика |
| Эффект | Глобальный — ускорение для всех пользователей сразу | Локальный — улучшение рендеринга конкретных страниц |
| Когда приоритет | TTFB выше рекомендованных значений, медленные регионы, динамические страницы | Нормальный TTFB, но плохой LCP/FCP, тяжёлые JS-фреймворки |
Гибридный подход — серверный рендеринг (SSR) плюс CDN плюс оптимизация ресурсов на клиенте — закрывает оба слоя. На практике это работает так: CDN отдаёт статику из ближайшего узла, SSR сокращает время до первого байта, а минификация и defer убирают блокировки рендеринга. Каждый слой снимает свой тип задержки, и суммарный эффект заметно превышает результат от работы только с одним из них.
Исключение — небольшие сайты на общем хостинге без тяжёлых фреймворков: там серверная часть уже достаточно быстрая, и большинство выигрыша дают именно клиентские правки — оптимизация изображений, удаление неиспользуемого CSS, правильный порядок загрузки шрифтов.
Пошаговый план: как ускорить загрузку сайта самостоятельно
Девять шагов ниже — это рабочий порядок, который мы проходим на большинстве проектов. Каждый шаг решает конкретную проблему, и пропускать их не стоит: узкое место на шаге 2 определяет, куда тратить время на шагах 3–8.
- Замерить исходные показатели. Откройте Яндекс.Метрику → «Скорость сайта» и PageSpeed Insights. Зафиксируйте значения до начала работ — без базовой точки невозможно понять, что реально помогло, а что просто совпало по времени.
- Определить узкое место. Смотрите на метрики: TTFB (время до первого байта) указывает на серверную сторону, LCP (отрисовка главного элемента) — чаще на изображения или блокирующие ресурсы, TBT (суммарное время блокировки) — на тяжёлый JavaScript, CLS (смещение элементов) — на отсутствие резервирования размеров под изображения и шрифты. Работайте с тем показателем, который хуже всего.
-
Оптимизировать изображения. Конвертируйте PNG/JPEG в формат WebP — он даёт заметно меньший вес при сопоставимом качестве. Добавьте атрибуты
widthиheightко всем тегам<img>— это устраняет CLS. Для изображений ниже первого экрана добавьтеloading="lazy". -
Настроить кэширование. Серверное кэширование снижает нагрузку на базу данных при повторных запросах. Браузерное — через директивы в
.htaccess(Apache) илиnginx.conf— позволяет браузеру хранить статику локально и не запрашивать её повторно. - Включить сжатие Gzip или Brotli. Brotli даёт лучшее сжатие текстовых ресурсов (HTML, CSS, JS), чем Gzip, и поддерживается большинством современных браузеров. Если сервер не поддерживает Brotli — Gzip лучше, чем ничего.
-
Перенести некритичный JavaScript. Скрипты, не нужные для первоначальной отрисовки, перенесите в конец
<body>или добавьте атрибутdefer. Атрибутasyncподходит для независимых скриптов (счётчики, виджеты), которые не зависят от DOM. -
Вынести критический CSS инлайном. Стили, нужные для отрисовки первого экрана, встройте прямо в
<head>. Остальной CSS загружайте асинхронно. Это устраняет блокирующий рендеринг и ускоряет LCP. - Подключить CDN для статики. Изображения, CSS, JS — раздавайте через CDN. Пользователь получает файлы с ближайшего к нему узла, а не с вашего основного сервера. Особенно заметный эффект — для аудитории за пределами города размещения сервера.
- Повторно замерить и зафиксировать результат. Снова проверьте отчёт «Скорость сайта» в Яндекс.Метрике и запустите PageSpeed Insights. Сравните с исходными значениями. Если улучшение есть — зафиксируйте в Яндекс.Вебмастере дату изменений, чтобы отследить корреляцию с позициями и трафиком.
Заключение
Главное:
- Сначала замер — потом правки: Яндекс.Метрика → «Скорость сайта» и PageSpeed Insights дают базовую точку, без которой невозможно понять, что реально помогло.
- TTFB и LCP дают наибольший эффект для SEO и поведенческих показателей — начинайте с них, а не с погони за баллами PageSpeed.
- Серверная оптимизация (HTTP/2, кэширование, CDN) работает один раз для всех пользователей; клиентская — требует точечных правок под каждый ресурс.
- Скорость загрузки — не разовая задача: после первичной оптимизации нужен регулярный мониторинг, иначе деградация накапливается незаметно.
- Даже небольшие улучшения скорости влияют на конверсию и показатель отказов — это подтверждают кейсы с реальными сайтами.
Скорость загрузки — это инфраструктурный вопрос, а не косметика. Страница, которая грузится медленно, теряет пользователей до того, как они увидят контент. Яндекс учитывает поведенческие сигналы при ранжировании, и медленный сайт получает их в худшем виде: короткие сессии, высокий показатель отказов, низкая глубина просмотра.
Порядок работы не меняется от проекта к проекту: замерить → найти узкое место → устранить → проверить результат. Пропустить первый шаг — значит оптимизировать вслепую и не знать, что именно дало эффект.