Ви прогнали сайт через PageSpeed Insights і отримали 34 бали з червоною шкалою. Під нею — двадцять рекомендацій англійською, кожна з посиланням на документацію, і жодного натяку на те, з чого починати. Половина з них взагалі не стосується вашої CMS. Це знайома точка, у якій більшість людей закриває вкладку й вирішує, що сайт і так нормально працює.
Насправді 80% роботи тут — не технічна, а сортувальна: зрозуміти, які три правки дадуть результат, а які вісімнадцять можна ігнорувати. Саме цю частину й має сенс віддати ШІ. Розберемо покроково, як це робиться в ChatGPT Work — і, головне, чого від нього чекати не варто.
🎧 Прослухати аудіоогляд статті
Що таке ChatGPT Work і чому це не просто чат
ChatGPT Work — це командна версія ChatGPT (чат гпт), побудована навколо однієї ідеї: модель не тільки відповідає, а й виконує задачі до кінця. Технічно вона працює на моделі GPT-5.6, але важливіше інше — набір режимів, яких немає у звичайному чаті.
- Режим агента. Модель не просто радить, а сама збирає контекст, планує послідовність дій і працює з вашими файлами, інструментами й застосунками на комп’ютері.
- Режим плану. Перед тим як щось робити, модель показує покроковий план — і ви можете його виправити до запуску, а не розгрібати результат після.
- Підключення до інструментів. OpenAI заявляє понад 1400 інтеграцій — тобто дані можна тягнути з тих сервісів, якими ви вже користуєтесь, а не копіювати вручну.
- Готові файли на виході. Таблиці, документи, презентації, а через функцію Sites — навіть інтерактивні сторінки-дашборди.
- Повторювані задачі. Одноразові й регулярні завдання з відстеженням прогресу, включно з мобільного.
Для аудиту швидкості критичні три з цих пунктів: агент, план і повторювані задачі. Далі буде видно чому.
Що з аудиту швидкості справді можна віддати ШІ, а що ні
Почнемо з чесної межі, бо без неї гайд перетворюється на рекламу.
Модель добре робить: розбирає технічний звіт і пояснює його людською мовою; сортує рекомендації за співвідношенням «ефект до складності»; рахує, скільки важать ваші зображення і скільки могли б важити; знаходить у переліку плагінів очевидних підозрюваних; пише конкретні правки коду під ваш стек; складає план і чек-ліст перевірки після кожної правки.
Модель не робить: не має доступу до вашого сервера й не бачить, що реально відбувається на хостингу; не вимірює швидкість сама — цифри беруться з інструментів, які ви їй дасте; не може гарантувати, що правка не зламає верстку; і не знає, які саме плагіни у вас критичні для бізнесу, доки ви цього не скажете.
Практичний висновок: ШІ тут — аналітик і планувальник, а не адміністратор сервера. Вимірювання й впровадження лишаються за вами або за розробником.
Крок 1: зібрати вихідні дані
Якість аудиту цілком залежить від того, що ви покладете на вхід. Мінімальний комплект — чотири речі.
- Звіт PageSpeed Insights. Не скріншот балу, а повний звіт — його можна зберегти як JSON через кнопку в правому верхньому куті або просто скопіювати текст усіх рекомендацій разом із цифрами.
- Дані з поля, якщо вони є. У верхній частині звіту PageSpeed показує реальні дані користувачів за останні 28 днів. Це важливіше за лабораторні цифри, бо Google оцінює саме їх.
- Список того, на чому працює сайт. CMS, тема, повний список активних плагінів чи модулів, хостинг, наявність CDN.
- Що ви вже пробували. Інакше перший пункт плану буде «встановіть кеш-плагін», який у вас стоїть уже два роки.
Якщо у вас підключені інтеграції, частину цього можна не збирати руками — модель дістане дані з підключених інструментів сама. Але для першого разу простіше вкинути все текстом.
Крок 2: попросити пріоритезувати, а не переказувати
Головна помилка на цьому кроці — попросити «проаналізуй звіт». Модель слухняно перекаже вам той самий список тими самими словами, тільки українською. Користі нуль.
Правильний запит просить не переказ, а рішення. Приблизно так:
«Ось звіт PageSpeed для сторінки [URL] і список технологій сайту. Не переказуй звіт. Замість цього: 1) назви три правки, які дадуть найбільший приріст швидкості; 2) для кожної оціни очікуваний ефект у секундах і складність упровадження — низька, середня, висока; 3) окремо випиши те, що в цьому звіті можна ігнорувати, і поясни чому. Якщо даних для оцінки бракує — скажи, яких саме, замість того щоб вгадувати».
Остання фраза важлива: без неї модель охоче вигадає точні цифри там, де їх нізвідки взяти. З нею вона чесно скаже «щоб оцінити ефект від оптимізації шрифтів, мені треба знати, скільки їх завантажується» — і це набагато корисніше.
Крок 3: перетворити список на план правок
Три пріоритетні правки — це ще не план. План — це послідовність дій, де кожен крок можна виконати й перевірити окремо. Тут якраз стає в пригоді режим плану: ви бачите послідовність до того, як щось почало відбуватись.
Що варто вимагати від плану:
- Один крок — одна зміна. Якщо ви одночасно стиснете картинки, увімкнете кеш і поміняєте тему, ви не дізнаєтесь, що саме спрацювало, а що зламало.
- Спосіб перевірки після кожного кроку. Не «перевірте, що все добре», а «прогнати PageSpeed по цій самій сторінці й порівняти LCP з попереднім значенням».
- Спосіб відкату. Що робити, якщо після правки поїхала верстка. Для WordPress це зазвичай «зробити резервну копію перед кроком», але краще, щоб це було написано явно.
- Оцінка часу. Хоча б у категоріях «п’ять хвилин / година / потрібен розробник». Це одразу відсіює задачі, які ви не робитимете ніколи.
Просіть віддати план таблицею — ChatGPT Work уміє генерувати готові таблиці, і такий план зручно вести як чек-ліст.
Крок 4: розібратись у трьох метриках, які насправді важать
Бал PageSpeed — це похідна величина, і ганятись за круглими цифрами в ній сенсу мало. Google дивиться на три конкретні метрики, і саме їх варто тримати в голові, коли модель пояснює вам звіт.
| Метрика | Що вимірює | Добре | Погано |
|---|---|---|---|
| LCP | Коли з’явився найбільший видимий елемент сторінки | до 2,5 с | більше 4 с |
| INP | Наскільки швидко сторінка реагує на дії користувача | до 200 мс | більше 500 мс |
| CLS | Наскільки сильно «стрибає» верстка під час завантаження | до 0,1 | більше 0,25 |
Дві деталі, які варто знати про ці цифри. По-перше, Google оцінює 75-й перцентиль реальних відвідувань — тобто сайт вважається успішним, якщо в трьох чвертей людей усе добре, а не в середньому. По-друге, метрика INP замінила стару FID у 2024 році й вимогливіша за неї: вона враховує кожну взаємодію на сторінці, а не тільки першу.
Просіть модель прив’язувати кожну рекомендацію до конкретної метрики: «ця правка впливає на LCP, ця на CLS, а ця — ні на що з трьох, тому вона внизу списку». Так одразу видно, чи не витрачаєте ви час на косметику.
Крок 5: поставити повторюваний контроль
Найкорисніша частина, яку майже завжди пропускають. Швидкість сайту не фіксується один раз назавжди: додали галерею на головну — і LCP поїхав назад. Оновили плагін — з’явився зайвий скрипт.
ChatGPT Work уміє виконувати повторювані задачі за розкладом. Логічний сценарій: раз на тиждень перевіряти ключові сторінки й повідомляти, якщо якась метрика вийшла за поріг. Формулювання приблизно таке: «щопонеділка перевіряй швидкість цих чотирьох сторінок і напиши мені, тільки якщо LCP став гіршим за 2,5 секунди або з’явилась нова рекомендація, якої не було минулого разу».
Ключове слово тут — «тільки якщо». Звіт, який приходить щотижня незалежно від того, чи щось змінилось, перестають читати на третьому тижні.
До речі, повторювані задачі в ChatGPT можна запускати не тільки за розкладом, а й за подією в іншому сервісі — ми розбирали це в матеріалі про тригери подій з Gmail, Slack і GitHub у ChatGPT. Для сайту це може бути, наприклад, перевірка після кожного деплою.
Три підводні камені
Модель упевнено називає цифри, яких не знає. «Ця правка пришвидшить сайт на 1,8 секунди» звучить переконливо, але без вимірювання це здогадка. Завжди додавайте в запит вимогу розділяти те, що виміряно, і те, що оцінено приблизно.
Поради можуть бути не для вашої CMS. Багато загальних рекомендацій написані під самописні сайти й погано лягають на WordPress чи конструктори. Обов’язково вказуйте платформу в запиті — і перепитуйте «чи це взагалі можливо зробити на моїй CMS без розробника».
Не давайте моделі доступів «про запас». Для аудиту швидкості потрібні звіти й опис стека, а не адмінка сайту. Чим менший доступ ви даєте, тим менша ціна помилки — і це стосується будь-якого агентного інструмента, не тільки цього.
Що з цього виходить на практиці
Реалістичний результат такого аудиту — не «сайт став літати», а три конкретні задачі замість двадцяти незрозумілих, зрозуміла причина кожної й спосіб перевірити, чи спрацювало. Це саме та частина роботи, яку люди зазвичай не роблять — не тому що складно, а тому що незрозуміло, з чого почати.
І остання порада, яка стосується не швидкості, а самих запитів: чим детальніше ви опишете свій сайт і свої обмеження, тим менш загальною буде відповідь. Як саме будувати такі запити, ми розбирали окремо в матеріалі про запити до ChatGPT українською. А якщо після аудиту захочеться зробити ще й відео про оновлений сайт — у нас є гайд про монтаж коротких відео в ChatGPT Work.
