Как найти блок или скрипт, который тормозит весь сайт

На коммерческом сайте одновременно могут работать формы, аналитика, рекламные пиксели, карта, онлайн-чат, коллтрекинг, слайдеры и собственный код. Часть этого появилась ещё в первой версии проекта, часть добавляли позже. В итоге проблема иногда находится совсем не там, где её ожидаешь.

На связи Марков Вадим из marmelad.digital.

Если сайт стал заметно медленнее после нескольких месяцев или лет доработок, я бы не начинал с PageSpeed и попыток улучшить все показатели сразу. Намного полезнее сначала понять, что именно создаёт задержку.

Для первичной диагностики обычно хватает Chrome DevTools. Причём разбираться во всех его возможностях для этого не требуется.

Сначала воспроизводим конкретную проблему

Сайт редко тормозит одинаково всё время.

Поэтому сначала я бы определил конкретное действие, после которого проблема хорошо заметна. Например, открыть мобильное меню, вызвать форму, прокрутить галерею или перейти к определённому блоку.

После этого открываем Performance, запускаем запись и повторяем то же действие. Эта панель записывает работу процессора и позволяет посмотреть, чем браузер занимался в нужный момент.

Если тормоза хорошо ощущаются только на телефонах, в Performance можно дополнительно замедлить процессор. Это полезно на мощном компьютере, где проблемный скрипт способен выполняться достаточно быстро и почти не привлекать внимания.

В записи стоит смотреть на участок Main. Если задержка совпала с большим куском выполнения скрипта, уже можно открыть его подробнее и посмотреть, какой файл и какие функции заняли время.

Иногда там обнаруживается вполне ожидаемый тяжёлый код. Иногда оказывается, что проблема появилась из-за небольшого стороннего виджета или старой анимации.

Что вообще загружает страница

Для этого удобнее Network.

После открытия панели лучше перезагрузить страницу, чтобы в журнал попали все запросы. Chrome показывает загруженные скрипты, стили, изображения, шрифты и обращения к внешним сервисам. Там же можно отфильтровать сторонние запросы и посмотреть их отдельно.

Я обычно сначала сортирую список по размеру и времени.

Так быстро находятся изображения в несколько мегабайт, видео, которое начинает загружаться раньше времени, лишние шрифты или тяжёлый файл стороннего сервиса.

Но смотреть только на размер нельзя. Скрипт может весить немного, а после загрузки выполнять много работы в браузере.

У запросов есть колонка Initiator. Через неё можно понять, какой файл запустил конкретную загрузку. Это особенно удобно, если на странице появился незнакомый loader.js или виджет после запуска подтягивает ещё несколько ресурсов.

На сайтах, которые давно поддерживаются, через Network иногда обнаруживаются вещи, о которых владелец уже вообще не знает. Например, код старого сервиса обратного звонка, отключённого визуально несколько месяцев назад, но всё ещё подключённого к странице.

Подозрительный файл можно просто отключить на время проверки

Когда круг подозреваемых сузился, я бы не пытался сразу переписывать код.

Гораздо быстрее проверить, изменится ли поведение сайта без конкретного ресурса.

В Chrome это можно сделать через Request conditions. Нужный запрос также блокируется прямо из Network: правой кнопкой по нему и Block request. DevTools перестанет загружать этот файл только локально, сам сайт при этом никак не изменяется.

После блокировки перезагружаем страницу и повторяем тот же сценарий.

Если с отключённым чатом меню неожиданно стало открываться нормально, уже есть понятное направление для дальнейшей работы.

Так же можно проверить карту, виджет отзывов, сторонний счётчик или отдельную библиотеку.

С блоком самой страницы логика похожая. Через Elements можно временно удалить подозрительную секцию из разметки и снова посмотреть Performance. Это удобно для тяжёлых галерей, большого количества карточек или блоков с активной анимацией.

Смысл такой проверки простой: менять за один раз что-то одно и смотреть, исчезла ли проблема. Иначе после десятка оптимизаций уже трудно понять, какая из них действительно помогла.

Cтарый код хорошо видно через Coverage

На проектах, которые пережили несколько редизайнов, я ещё проверяю Coverage.

Открыть его можно через More tools - Coverage или через командное меню DevTools. После перезагрузки страницы Chrome покажет, какая часть загруженных CSS и JavaScript использовалась во время проверки, а какая осталась невыполненной.

Допустим, страница загружает большой файл скриптов, а фактически используется небольшая его часть.

Удалять такой файл сразу нельзя. Остальной код может запускаться после другого действия или использоваться на других страницах. Но это хороший повод разобраться, зачем весь пакет загружается именно здесь.

На старых сайтах встречается достаточно много такого наследства: библиотека от давно удалённого слайдера, стили старой версии меню, общий скрипт каталога на страницах, где каталога вообще нет.

Coverage хорошо подходит именно для поиска таких мест.

Чтобы результат был полезнее, после запуска записи стоит пройти основные действия на странице - открыть меню, форму, вкладки и другие интерактивные элементы. Тогда Chrome увидит больше реально используемого кода.

Если сайт начинает тормозить не сразу

Бывает другая ситуация. Первые несколько секунд всё работает нормально, а потом страница постепенно становится тяжелее.

В таком случае можно открыть More tools - Performance monitor.

Он показывает в реальном времени CPU usage, размер памяти JavaScript, количество DOM Nodes, обработчиков событий, документов и пересчётов расположения элементов.

Здесь я бы смотрел в первую очередь на изменение показателей во время работы.

Например, открываем и закрываем форму несколько раз. Если количество обработчиков после каждого открытия растёт и уже не возвращается к предыдущему значению, стоит проверить код формы.

Похожая история может быть с количеством элементов в DOM. Если после каждого действия их становится всё больше, возможно, скрипт создаёт новые элементы и не убирает старые.

Или видно, что после появления определённого блока загрузка процессора резко возрастает и остаётся высокой, пока блок находится на экране. Тогда уже имеет смысл возвращаться в Performance и записывать именно этот участок.

С чего я бы начал проверку обычного коммерческого сайта

Если тормоза появились недавно, сначала стоит вспомнить последние изменения. Новый виджет, обновлённая форма или анимация первого экрана дают намного более короткий список кандидатов, чем попытка проверять весь проект.

На старом сайте полезно открыть Network и посмотреть сторонние запросы, затем записать проблемное действие в Performance. Когда появляется конкретный подозреваемый, его можно отключить через Request conditions и повторить проверку.

Coverage я бы подключал уже после этого, особенно если проект много раз переделывали.

Так обычно быстрее найти реальную причину, чем идти сверху вниз по всему отчёту PageSpeed. Он вполне может показать проблемы с JavaScript, изображениями или сторонним кодом, но там всё равно придётся выяснять, какой именно элемент создаёт задержку.

В DevTools эту связь можно увидеть гораздо ближе к исходной проблеме: нажали кнопку, получили тормоз, посмотрели, что браузер выполнял в этот момент, отключили подозрительный ресурс и повторили тест.

Для первичной диагностики этого часто достаточно, чтобы вместо расплывчатого сайт стал тяжёлым получить конкретную задачу для разработчика.