Скорость загрузки сайта — первое, с чем сталкиваются пользователи при посещении страницы. Если веб-страницы открываются медленно, одной из причин могут быть скрипты: браузеру нужно скачать, разобрать и выполнить каждый файл JavaScript, а часть из них останавливает разбор HTML. Добиться быстрой загрузки помогает понимание того, какие файлы лишние, тяжелые или блокирующие и что с ними делать.
Оптимизация JavaScript — это комплекс мер, которые сокращают число, размер и время выполнения скриптов и помогают браузеру и поисковому роботу получить готовую страницу без лишних задержек.
Основа статьи — шесть советов по оптимизации JS из видео разработчика Google Алана Кента, о котором Search Engine Journal писал в мае 2022 года. Кент перечислил распространенные проблемы со скриптами и способы их исправить. К этим советам добавлены измерение результата, различие async и defer и обработка JavaScript поисковыми системами, чтобы SEO-оптимизация не шла в ущерб скорости. После прочтения можно разобрать отчет PageSpeed Insights, выбрать прием под причину и поставить разработчикам задачу с проверяемым результатом.
- Зачем оптимизировать JavaScript и чем измерить результат
- Откажитесь от большого количества файлов JavaScript
- Избегайте чрезмерных запросов к DNS-серверу
- Устраните неэффективно работающий JavaScript
- Удалите неиспользуемый JavaScript
- Сожмите файлы JavaScript и настройте кэширование
- Как JavaScript влияет на SEO и работу поисковых систем
- FAQ по оптимизации JavaScript
- Коротко о главном
Зачем оптимизировать JavaScript и чем измерить результат
JavaScript может замедлять страницу, потому что браузер должен скачать скрипт, разобрать его и выполнить. Скрипт без атрибутов async, defer и type=module блокирует разбор HTML: пока он не загрузится и не выполнится, браузер не продолжает собирать страницу. Если такой скрипт подключен в блоке head, он фактически блокирует и отрисовку страницы, пока не загрузится и не выполнится, поэтому скорость работы сайта зависит от скриптов.
По данным Web Almanac 2025 (HTTP Archive, сканирование июля 2025 года, сайты всего мира), медианная страница передает 708 КБ JavaScript на десктопе и 646 КБ на мобильных устройствах. Это сжатые байты. Google оценивает скорость и отзывчивость страниц сайта по метрикам Core Web Vitals и рекомендует добиваться хороших значений для успеха в поиске.
| Инструмент | Что показывает | Когда использовать |
|---|---|---|
| PageSpeed Insights | Полевые данные реальных пользователей за последние 28 дней, если у страницы достаточно посещений, и лабораторный отчет Lighthouse с рекомендациями по странице | Первая проверка страницы и поиск проблем из следующих разделов |
| Lighthouse | Лабораторный отчет о загрузке страницы. В версии 13 часть прежних проверок заменена блоками insights, поэтому названия строк отчета меняются | Проверка до и после правок скриптов |
| Chrome DevTools | Вкладка Network показывает запросы, домены, размер файлов и заголовки ответа, а панель Lighthouse запускает аудит страницы | Поиск конкретного файла и проверка заголовков |
Core Web Vitals — это набор метрик Google для оценки пользовательского опыта страницы: скорости загрузки основного контента, отзывчивости и стабильности макета.
Largest Contentful Paint (LCP) показывает, когда на экране появляется самый крупный элемент страницы, например изображение или блок текста, и хорошим считается значение 2,5 секунды или быстрее. Cumulative Layout Shift (CLS) оценивает неожиданные сдвиги макета, а хороший результат составляет 0,1 или меньше. Interaction to Next Paint (INP) измеряет отзывчивость на действия пользователя: с 12 марта 2024 года он заменил First Input Delay (FID), а хорошим считается значение 200 мс или меньше. Все три метрики оценивают по 75-му процентилю загрузок страницы, отдельно для мобильных устройств и десктопов. Для технической оптимизации сайта важно сравнивать результат до и после правок по одним и тем же метрикам.

Откажитесь от большого количества файлов JavaScript
Много мелких файлов JavaScript могут замедлять загрузку, потому что при HTTP/1.1 браузер запрашивает каждый из них отдельно. Количество файлов может стать чрезмерным, особенно если для каждого UI-компонента используется отдельный файл. Google советует сократить число файлов, которые браузеру нужно скачивать при загрузке.
Сервис Google PageSpeed Insights поможет найти проблемы со скриптами: запустите проверку своего сайта и откройте группу «Диагностика». Число запросов при загрузке страницы показывает Chrome DevTools, на вкладке Network его отображает строка состояния внизу окна. Мелкие файлы можно объединить в один, и тогда при HTTP/1.1 браузер отправит меньше запросов. При HTTP/2 запросы идут параллельно по одному соединению, поэтому объединять файлы ради числа запросов не обязательно.
Если объединить файлы нельзя, подключите поддержку HTTP/2. Это вторая версия сетевого протокола HTTP.
Избегайте чрезмерных запросов к DNS-серверу
Каждый внешний домен, с которого загружаются файлы JavaScript, требует отдельного запроса к DNS-серверу (dns.lookup). Это может замедлить загрузку сайта при первом визите пользователя. Чтобы снизить количество таких запросов, Google советует разместить на своем сайте копии файлов JavaScript, которые загружаются с внешних источников.
Список скриптов с их URL есть в отчете PageSpeed Insights, в строке «Время выполнения кода JavaScript». Полный перечень доменов проще получить с помощью инструментов Chrome DevTools: на вкладке Network фильтр domain: оставляет ресурсы указанного домена, а подсказка перечисляет все встреченные домены. Копии сторонних файлов нужно обновлять самостоятельно, потому что при выходе новой версии у поставщика ваша копия не изменится.
Устраните неэффективно работающий JavaScript
Неэффективный JavaScript — это код, который блокирует разбор HTML или долго выполняется. Такой код может замедлять загрузку страниц, ухудшая пользовательский опыт. Задача в основном потоке длительностью больше 50 мс не дает браузеру показать ответ на действие пользователя.
Найти такие скрипты помогают две строки в отчете PageSpeed Insights:
- «Время выполнения кода JavaScript» (если проверка не пройдена, строка называется «Сократите время выполнения кода JavaScript»). В этом разделе показано, на анализ и компиляцию какого скрипта устройству придется потратить много ресурсов.
- «Запросы, блокирующие отрисовку страницы». Строка перечисляет запросы, из-за которых браузер откладывает первую отрисовку страницы, пока не загрузит и не обработает эти ресурсы.
Исправлять такой код стоит по результатам профилирования. Google советует профилировать уже существующий код и писать собственные уменьшенные версии более мощных компонентов. Долгие задачи полезно разбивать на небольшие фрагменты, чтобы браузер успевал отвечать на действия пользователя, а скрипты, которые не нужны для первого экрана, можно подключать с атрибутом async или defer. Async загружает скрипт параллельно с разбором документа и выполняет сразу после загрузки, а defer выполняет его после разбора документа.
Отложенная загрузка второстепенных изображений и iframe тоже ускоряет страницу. По рекомендации Google Search Central, весь важный контент должен загружаться, когда попадает в область просмотра, а к тому, что видно сразу при открытии страницы, отложенную загрузку применять не стоит: при неверной реализации контент может оказаться скрыт от Google.
Зависимые друг от друга скрипты не переводите в async: порядок их выполнения не гарантирован. Для таких скриптов подходит defer.
Удалите неиспользуемый JavaScript
Неиспользуемый JavaScript — это код, который браузер скачивает и анализирует, хотя он не нужен при загрузке страницы. По данным Web Almanac 2025 (HTTP Archive, июль 2025 года, сайты всего мира), медианная страница содержит 280 КБ неиспользуемого несжатого JavaScript на десктопе и 251 КБ на мобильных устройствах.
Повторное использование кода на сайте может привести к включению JavaScript, который не требуется. В этом случае JavaScript будет скачиваться и анализироваться браузером каждый раз, и это очевидная трата ресурсов.
В отчете PageSpeed Insights сведения о таком коде собраны в трех строках:
- «Удалите неиспользуемый код JavaScript». Раздел показывает JavaScript, который не используется при загрузке страницы.
- «Предотвратите чрезмерную нагрузку на сеть». Эта строка покажет, какие части сайта требуют скачивания больших файлов.
- «Минимизация работы в основном потоке» (если проверка не пройдена, строка называется «Минимизируйте работу в основном потоке»). Показывает, сколько времени основной поток браузера тратит на разные виды работы, включая обработку JavaScript.
Google рекомендует технику «встряхивание дерева», или tree-shaking. Этот прием работает на этапе сборки: сборщик, например webpack или Rollup, удаляет неиспользуемый код, опираясь на статическую структуру модулей ES, то есть на инструкции import и export.
Второй способ — разделение кода (code splitting): пакет скриптов (бандл) делят на части и сначала отправляют только то, что нужно для первого экрана, а остальное загружают по необходимости. Дополнительно файлы минифицируют: из них убирают комментарии, пробелы и табуляции, и файл весит меньше. Минификация неиспользуемый код не удаляет, поэтому ее применяют вместе с tree-shaking.

Сожмите файлы JavaScript и настройте кэширование
Текстовые файлы, в том числе JavaScript, сжимают перед отправкой. Сжатие включают на сервере (gzip или Brotli), а браузер распаковывает полученный файл. Браузеры сообщают о поддержке сжатия в заголовке Accept-Encoding, а настройка относится к хостингу и серверу.
Строка «Задержка при запросе документа» в PageSpeed Insights проверяет сжатие только для HTML-документа, поэтому сжатие файлов JavaScript проверяют в Chrome DevTools.
Срок кэширования файлов
Убедитесь, что у файлов JavaScript указан подходящий срок кэширования. Это избавит браузер от постоянных проверок ресурса на актуальность и ненужных запросов на сервер. Проверить срок можно в Chrome DevTools по заголовку Cache-Control на вкладке Network. В PageSpeed Insights за это отвечает строка «Выбирайте эффективный период хранения кеша»: в ней указан список ресурсов, включая файлы JavaScript, которые выиграют от более долгого срока хранения.
У долгого срока хранения есть риск. По документации Google Search Central, Googlebot активно кэширует ресурсы, а рендерер может брать устаревшие JavaScript или CSS. Решение — добавлять отпечаток содержимого в имя файла: после правки имя меняется, и браузер с роботом запрашивают новую версию.
Как JavaScript влияет на SEO и работу поисковых систем
Скрипты используются почти на каждом сайте, а в веб-приложениях часть контента и ссылок создает JavaScript в браузере. Google ставит в очередь на рендеринг все страницы с кодом ответа 200, кроме закрытых от индексации. В очереди страница может находиться секунды и дольше, затем headless Chromium выполняет JavaScript, и Google индексирует отрендеренный HTML. Контент, которого нет в отрендеренном HTML, Google не увидит и не проиндексирует.
Рендеринг — это процесс, при котором код страницы превращается в готовую страницу, которую видит пользователь.
Серверный или клиентский рендеринг
При клиентском рендеринге (CSR) сервер отдает страницу, а контент добавляет скрипт в браузере. При серверном рендеринге (SSR) HTML с контентом приходит с сервера уже готовым, а при пререндеринге страницы заранее собирают в готовый HTML.
Google по-прежнему считает серверный рендеринг или пререндеринг хорошей идеей: так сайт работает быстрее для пользователей и поисковых роботов, ведь не все боты выполняют JavaScript. Динамический рендеринг, при котором роботам отдают серверную версию, а пользователям клиентскую, Google называет обходным путем. Рекомендуемым решением он не считается из-за сложности и затрат ресурсов.

Что проверить на странице с JavaScript
Проверку начинают со сравнения исходного HTML и отрисованной страницы. Код страницы можно открыть через просмотр кода, а итоговый DOM — через панель разработчика в Chrome DevTools: если код различается, часть контента создает скрипт. Важный контент, заголовки и ссылки лучше отдавать в исходном HTML, потому что не все роботы выполняют JavaScript. Google находит ссылки только в элементах a с атрибутом href. Отрисованную версию страницы, загруженные ресурсы и вывод JavaScript показывает инструмент проверки URL в Search Console.
Пример из практики Kokoc.com: при аудите сайта онлайн-школы в сентябре 2024 года специалисты агентства заметили, что код через панель разработчика и через просмотр кода страницы различается. Скрипты рендерились в браузере, Яндекс Вебмастер показывал ошибку дублей метатегов при уникальных метатегах в коде, а внутренние ссылки не сканировались, хотя страницы были в индексе, а в Вебмастере рендеринг скриптов был включен и сохраненная версия страниц содержала весь контент. Агентство рекомендовало перенести рендеринг на хостинг, и клиент вносил правки с ноября 2024 по апрель 2025 года.
В кейсе онлайн-школы трафик год к году (июль 2024 к июлю 2025) вырос в 2,28 раза, а лиды по цели «Успешная оплата» — в 2,43 раза. Причину роста специалисты агентства связывают с рендерингом по своим наблюдениям, контрольной группы не было, а клиент работал над сайтом комплексно.
FAQ по оптимизации JavaScript
Выполняет ли Яндекс JavaScript при индексировании?
В Яндекс Вебмастере есть раздел «Рендеринг страниц JavaScript» со статусом бета, и по умолчанию там включена опция «На усмотрение робота Яндекса»: робот сам решает, выполнять ли JavaScript. Если на сайте используется SSR или пререндеринг, Яндекс советует запретить рендеринг. Выполнение JavaScript роботом может создавать дополнительную нагрузку на сервер.
Видят ли ИИ-краулеры страницы с JavaScript?
Авторы Web Almanac 2025 отмечают, что ключевая информация должна быть в исходном HTML, так как ИИ-краулеры не рендерят JavaScript. Google, в отличие от ИИ-краулеров, выполняет JavaScript в очереди рендеринга.
Что будет, если файлы скриптов закрыты в robots.txt?
Google Search не рендерит JavaScript из файлов и со страниц, закрытых в robots.txt. Поэтому каталоги со скриптами не стоит закрывать в robots.txt, а существующие правила файла лучше проверить.
Можно ли задавать canonical скриптом?
Google советует задавать canonical в HTML. Если указывать его скриптом, значение не должно отличаться от значения в исходном HTML.
Коротко о главном
- Оптимизация JavaScript начинается с трех действий: меньше файлов и внешних запросов, удален неиспользуемый код, скрипты загружаются по необходимости.
- Сжатие и срок хранения файлов настраиваются на сервере, а версия в имени файла позволяет хранить файл долго.
- Проверять результат нужно по метрикам LCP, INP и CLS: INP смотрят в полевых данных PageSpeed Insights, остальные можно проверить и в Lighthouse или DevTools.
- Для поиска важный контент и ссылки лучше отдавать в исходном HTML, а серверный рендеринг или пререндеринг по-прежнему хорошая идея.
- Частые ошибки: зависимые скрипты в async, файлы скриптов закрыты в robots.txt, canonical в скрипте отличается от HTML.


Комментарии (7)
Оставить комментарий