Оптимизация скорости сайта с помощью ИИ
Скорость сайта больше не чинят только руками в инструментах разработчика. ИИ помогает собрать аудит, расставить приоритеты, подобрать сжатие и даже сгенерировать правки — но только если вокруг модели есть жёсткий процесс с метриками и ревью. Разбираем, как выстроить такую цепочку в агентстве и не получить «оптимизацию», которая ломает дизайн и SEO.
Зачем ИИ для скорости, если есть Lighthouse
Lighthouse отлично находит симптомы: огромный JS, неоптимизированные картинки, долгие задачи. Но на большом сайте с десятками шаблонов ручной разбор отчётов съедает недели.
ИИ ускоряет три слоя: сведение аудитов в единый список задач, генерацию конкретных заданий для разработчиков и автоматизацию рутины — изменение размеров медиа, поиск неиспользуемого CSS, черновики настроек CDN и фонового скрипта браузера.
Ключевой принцип: модель не «ускоряет сайт», она ускоряет работу вокруг скорости. Решение о внедрении всегда принимает человек по полевым метрикам. Иначе легко залить в прод агрессивную отложенную загрузку, которая убьёт LCP, или вырезать CSS, от которого зависит первый экран.
В агентской практике ИИ особенно силён на портфеле из нескольких однотипных сайтов: одни и те же классы проблем повторяются — неоптимизированные галереи, виджеты чата, тяжёлые шрифты, неуправляемый Google Tag Manager.
Модель, обученная на ваших внутренних разборах и чеклистах, быстрее новичка-аудитора собирает список задач «как мы уже чинили сто раз». Это и есть операционный рычаг: не магия нейросети, а перенос накопленной экспертизы в повторяемый процесс.
Процесс аудита: от сырых отчётов к списку задач
Рабочая схема выглядит так. Сборщики гоняют Lighthouse и WebPageTest по списку URL и устройств. RUM отдаёт web-vitals с привязкой к элементам. Всё складывается в хранилище (BigQuery, ClickHouse или даже структурированный JSON в артефактах сборки).
Дальше языковая модель (LLM) получает не «сделай сайт быстрее», а пакет: шаблон, метрики p75, самые тяжёлые ресурсы, долгие задачи, сравнение с прошлым релизом.
ФактИИ ускоряет разбор отчёта, но приоритеты и проверку откатов оставляет инженер.
- Снять лабораторные и полевые данные по ключевым шаблонам.
- Сгруппировать находки по типу (медиа, JS, TTFB, CLS, сторонние скрипты).
- Оценить «эффект × трудозатраты» моделью с ручной калибровкой.
- Сформировать тикеты с критерием приёмки в миллисекундах или баллах.
- После фикса — повторный прогон и сравнение p75.
Качество вывода модели резко растёт, если вы сводите находки к единой классификации: медиа, шрифты, JS в главном потоке, TTFB, сдвиги вёрстки, сторонние скрипты, кэширование. Тогда агент не плодит десятки уникальных формулировок одного и того же бага.
Добавьте в контекст «уже сделано / не трогать»: иначе процесс будет снова предлагать предзагрузку ресурса, который вы сознательно не грузите в первом экране.
Свяжите аудит с релизами: каждый прогон хранит хеш коммита и список URL. Тогда ИИ может строить сравнение «что ухудшилось после релиза», а не только абсолютный список проблем. Это превращает скорость из периодического аудита в непрерывный контроль откатов — именно так и должна выглядеть инженерия с поддержкой ИИ.
Автоматизация медиа и критического CSS
Самый безопасный контур для ИИ — конвейер обработки медиа. Модель (или классический скрипт под управлением агента) определяет кандидатов на LCP, предлагает ширины srcset, конвертацию в AVIF/WebP, вычистку EXIF и запрет отложенной загрузки для первого экрана.
Критический CSS можно генерировать по списку шаблонов и сравнивать в pull request: человек видит, что именно вынесено в inline.
| Этап | Что делает ИИ | Что проверяет человек | Риск |
|---|---|---|---|
| Аудит | Группировка находок, сводка для команды | Полнота URL и сегментов | Низкий |
| Медиа | Изменение размеров, форматы, подсказки preload | Качество картинок, LCP-элемент | Средний |
| CSS/JS | Черновик критического CSS, кандидаты на разделение | Откаты вёрстки и инициализации | Высокий |
| CDN/кэш | Рекомендации заголовков и времени жизни кэша | Корректность ключей кэша | Средний |
Для интернет-магазинов отдельно прогоняйте карточки с фото от покупателей: там чаще всего «сырые» загрузки из админки. ИИ-агент может патрулировать новые файлы и не пускать в прод изображения тяжелее лимита, пока их не сожмут.
JavaScript, инициализация и сторонние скрипты под контролем агента
Здесь ИИ полезен как аналитик бандла: сопоставить покрытие кода с маршрутами, найти дубли зависимостей, предложить отложенную загрузку для редких виджетов. Опасно отдавать модели право «просто удалить неиспользуемый код» без тестов — особенно в легаси.
Лучше режим: агент открывает pull request с гипотезой и тестом производительности, CI гоняет Lighthouse, человек мержит.
- Каталог сторонних скриптов с владельцем, триггером загрузки и лимитом на главный поток.
- Автообнаружение новых тегов в GTM и алерт в Slack.
- Сценарии отложенной загрузки чатов и рекомендательных систем.
- Сравнение INP до/после на ключевых действиях, а не только общий TBT.
Отдельный антипаттерн — просить модель «удалить всё неиспользуемое» по покрытию одного прогона. Покрытие зависит от сценария: то, что не выполнилось на главной, нужно на оформлении заказа. Поэтому рекомендации по «мёртвому коду» сопровождайте картой маршрутов и сквозными smoke-тестами. Иначе получите ускорение демо-стенда и инциденты на проде.
Для сторонних скриптов заведите контракт: каждый тег имеет владельца, цель бизнеса, способ загрузки и лимит на главный поток. Агент может еженедельно сверять фактический набор скриптов с контрактом и поднимать алерт на «незнакомца». Так скорость перестаёт быть сюрпризом после запуска рекламной кампании.
Встраивание в CI/CD и продуктовый процесс
Без автопроверок любой процесс с ИИ — демо. Настройте лимиты: вес JS на шаблон, LCP в лаборатории на мобильном профиле, запрет отката CLS выше порога. Агент может комментировать PR: «этот diff добавляет 180 КБ gzip к карточке товара». Это дешевле, чем ловить падение конверсии через месяц.
Роли в команде
Ответственный за скорость утверждает лимиты. Разработчик внедряет правки. Маркетинг согласует список сторонних скриптов. ИИ — ускоритель подготовки решений, не «владелец скорости». В Агентуре такое распределение ролей снимает вечные споры «кто сломал PageSpeed».
Как измерить успех оптимизаций с ИИ
Смотрите не на количество сгенерированных рекомендаций, а на движение полевых CWV и бизнес-метрик: отказы на мобиле, скорость до первого осмысленного экрана воронки, время до добавления в корзину. Параллельно считайте стоимость владения: часы команды на ревью PR от ИИ.
Если ревью дороже ручного фикса — процесс нужно упростить.
| Показатель | Как считать | Целевой ориентир |
|---|---|---|
| p75 LCP (mobile) | RUM по шаблону карточки/лендинга | ≤ 2,5 с или устойчивый тренд вниз |
| Доля задач от ИИ, дошедших до прода | Смерженные PR / созданные предложения | ≥ 40% после калибровки |
| Откаты после релиза | Алерты RUM за 14 дней | 0 критических без hotfix |
| Время аудита пакета URL | Часы от сбора до списка задач | Сокращение в 2–4 раза |
Не забывайте качественные отзывы разработки: если инженеры игнорируют задачи от ИИ, значит формулировки слабые или приоритет мимо бизнеса. Собирайте фидбек и калибруйте запросы раз в две недели на старте. Через месяц хороший процесс требует меньше ручной правки гипотез и больше времени на внедрение.
Практический запуск за две недели
- Неделя 1: список URL, исходный уровень RUM/лаборатории, лимиты, каталог сторонних скриптов.
- Неделя 1–2: конвейер медиа и автоприоритизация находок.
- Неделя 2: пилотные PR на 1–2 шаблона, сравнение p75.
- Далее: расширение на остальные шаблоны и алерты об откатах.
Не пытайтесь сразу «подключить ИИ ко всему сайту». Начните с одного денежного шаблона и одного класса задач — обычно медиа и LCP. Когда процесс стабилен, подключайте JS и кэш. Так работа со скоростью через ИИ становится операционной системой, а не разовым экспериментом.
На втором месяце обычно появляются два соблазна: расширить ИИ на все шаблоны сразу и ослабить code review «раз CI зелёный». Оба вредны. Масштабируйте по классам задач, а не по количеству URL.
Ревью оставляйте жёстким на всём, что трогает критический CSS, инициализацию интерфейса и заголовки кэша — цена ошибки там выше экономии часа инженера.
Частые вопросы
Можно ли полностью автоматизировать оптимизацию скорости?
Нет. Автоматизируются сбор, приоритизация и безопасная рутина вроде сжатия медиа. Архитектурные решения и рискованные правки CSS/JS требуют ревью человека и проверки полевых метрик.
Какая модель лучше для аудита скорости?
Важнее качество контекста, чем бренд модели: URL, сводки трассировок, вес ресурсов, ограничения по дизайну. Используйте модель с хорошим пониманием кода и обязательно прогоняйте результат через CI.
С чего начать, если команда маленькая?
С RUM на ключевых страницах и ИИ-разбора Lighthouse в еженедельный список задач. Затем — автоматическое сжатие изображений. Это даёт быстрый эффект без тяжёлой платформы.
Не ухудшит ли ИИ SEO, вырезав контент или CSS?
Может, если дать право на деструктивные правки без тестов. Ограничьте агента: только PR, визуальные smoke-тесты, запрет менять текстовый контент и разметку без явного разрешения.
Как связать это с Core Web Vitals?
Сделайте CWV целевой функцией процесса: каждый тикет привязан к LCP, INP или CLS конкретного шаблона, а приёмка — по лаборатории плюс поле через 7–14 дней.