Агентний вебперегляд у PageSpeed Insights: що це і навіщо

Нещодавно я проганяв свій блог через PageSpeed Insights. Продуктивність, доступність, найкращі практики і SEO показали по 100, і це приємно. Але поруч з цими чотирма звичними категоріями з'явилась п'ята: «Агентний вебперегляд» (Agentic Browsing). Я вирішив розібратися, що це таке, бо виглядає так, ніби веб тихо отримав нового типу відвідувачів.

Хто такі ШІ-агенти і до чого тут браузер

Ще недавно мовні моделі в основному генерували текст. Тепер усе частіше вони самі відкривають сайти і виконують завдання: знайти товар і порівняти ціни, записатися до лікаря, заповнити форму, оформити замовлення. Такий агент «бачить» сторінку не так, як людина. Йому важливо зрозуміти, що на сторінці є, що з цим можна зробити і як не помилитися.

Google описує це як рух до «agent-ready» сайтів: сайтів, які дають агентам передбачувані сигнали, зрозумілі машині, щоб ті могли надійно довести завдання до кінця. Нова категорія в Lighthouse якраз і перевіряє, наскільки сайт до цього готовий.

Звідки взялася категорія

Категорія живе в Lighthouse, тому вона з'явилась і в PageSpeed Insights, і в панелі Lighthouse у Chrome DevTools. Перевіряти її повноцінно можна в Chrome 150 і новіших. Chrome прямо називає категорію експериментальною: вона спирається на стандарти, які ще тільки пропонуються, і може змінюватися.

Що саме вона перевіряє

Перевірки поділені на кілька груп.

1. Доступність, орієнтована на агентів

Це підмножина звичайних перевірок доступності. Річ у тім, що для агента головна модель сторінки це дерево доступності (accessibility tree), а не картинка на екрані. Тому перевіряється:

• імена й підписи: у кожного інтерактивного елемента є програмне ім'я (текст кнопки, aria-label, підпис поля);
• цілісність дерева: ролі елементів і зв'язки «батько-дитина» правильні;
• видимість: інтерактивні елементи не сховані від дерева доступності.

Кнопка-іконка без підпису для людини ще якось зрозуміла з контексту, а для агента це просто «button» без жодного сенсу.

2. Стабільність макета (CLS)

Cumulative Layout Shift показує, наскільки елементи стрибають під час завантаження. Для людини це просто дратує, а для агента може закінчитися кліком не туди: він вирішив натиснути на кнопку, а поки клікав, на її місце з'їхало щось інше.

3. Знаходимість: llms.txt

Lighthouse дивиться, чи є на сайті файл /llms.txt. Це короткий опис сайту в Markdown спеціально для мовних моделей: що це за сайт і де лежать головні сторінки. Формат запропонував Джеремі Говард у вересні 2024 року, специфікація лежить на llmstxt.org.

Важливий момент: якщо файлу немає (404), аудит позначається як «не застосовується», а не як провал, бо поки це необов'язкова річ. Провалом вважається, коли сервер відповідає помилкою.

Мінімальний приклад для блогу міг би виглядати так:

# Zhurbiy Tech

> Особистий блог про фронтенд, розробку продуктів і все, що я вивчаю на цьому шляху.

## Статті

- [Як я переїхав з блогом на Railway](https://zhurbiy.com/uk/articles/pereizd-na-railway): деплой Nuxt, Postgres і Cloudflare
- [Зрозуміти, для кого саме цей продукт](https://zhurbiy.com/uk/articles/dlia-koho-tsei-produkt): про цільову аудиторію

## Optional

- [Про автора](https://zhurbiy.com/uk/about)

Обов'язковий у ньому лише заголовок першого рівня. Далі йде цитата з коротким описом, а потім розділи зі списками посилань. Розділ «Optional» містить другорядне, яке агент може пропустити, якщо в нього мало контексту.

4. WebMCP

Найцікавіша і найсвіжіша частина. WebMCP це запропонований вебстандарт, який дозволяє сайту прямо оголосити агенту інструменти: «ось форма запису, ось пошук, ось кошик». Замість того щоб агент клікав по сторінці і вгадував, він викликає готовий інструмент з описом і схемою параметрів. За словами Chrome, це помітно підвищує точність виконання завдань.

Lighthouse тут перевіряє, чи зареєстровані на сторінці інструменти, чи є форми без декларативної розмітки WebMCP і чи валідні схеми параметрів.

WebMCP має два API. Декларативний працює через атрибути звичайної HTML-форми:

<form toolname="createSupportRequest" tooldescription="Submits a request for customer support.">
  ...
</form>

Імперативний дозволяє зареєструвати інструмент з JavaScript. Наприклад, пошук по блогу міг би виглядати приблизно так:

await document.modelContext.registerTool({
  name: 'search_articles',
  description: 'Search blog articles by keyword',
  inputSchema: {
    type: 'object',
    properties: { query: { type: 'string', description: 'Search phrase' } },
    required: ['query']
  },
  execute: async ({ query }) => {
    const res = await fetch('/api/articles?q=' + encodeURIComponent(query))
    return JSON.stringify(await res.json())
  }
})

Зараз WebMCP доступний як origin trial, починаючи з Chrome 149, а для локальних експериментів є прапорець chrome://flags/#enable-webmcp-testing. API ще обговорюється і змінюється: у старих прикладах можна зустріти navigator.modelContext замість document.modelContext. Тому перед використанням краще дивитися актуальну документацію.

Окремо в документації наголошують на безпеці. Реєстрацію інструментів обмежує політика дозволів tools: за замовчуванням вона працює лише для свого origin, а в cross-origin iframe потрібен allow="tools". Для чутливих дій, як-от оплата, радять просити підтвердження в користувача. І треба пам'ятати, що інструменти можуть бачити і викликати також розширення браузера.

Як рахується оцінка

Тут немає звичних 0-100. Результат показується як частка пройдених перевірок, наприклад 3 з 3, і кожна перевірка має статус «пройдено» або «не пройдено». Перевірки зі статусом «не застосовується» (наприклад, відсутній llms.txt) провалом не вважаються. Сам Chrome називає оцінку «інформаційною і без бенчмарків»: це сигнали для розробника, а не рейтинг.

На позиції в пошуку Google ця категорія, судячи з усього, зараз не впливає. Сприймати її варто як підказку, куди рухається веб, а не як ще одну метрику, за якою треба гнатися.

Як перевірити свій сайт

• PageSpeed Insights: категорія показується поруч з іншими.
• Chrome DevTools: вкладка Lighthouse, категорія Agentic Browsing (потрібен Chrome 150+).
• Lighthouse CLI: lighthouse https://example.com --only-categories=agentic-browsing.
• Chrome DevTools for agents: якщо працюєте з ШІ-агентом для коду, він може сам запустити аудит Lighthouse на відкритій вкладці.

Що я зробив і що планую на своєму блозі

Цікаво, що частина цієї категорії збіглася з тим, чим я займався буквально перед цим. Я якраз виправляв CLS на головній: через різні версії однієї бібліотеки дані з сервера не підхоплювались і цілі блоки на мить зникали. Тепер CLS на всіх сторінках нуль. Кнопки-іконки на сайті мають підписи для скрінрідерів, тож з деревом доступності теж усе гаразд.

llms.txt я додав, поки писав цю статтю. Він генерується автоматично зі списку опублікованих статей, тож завжди актуальний: zhurbiy.com/llms.txt. З WebMCP я поки почекаю. Для блогу тут небагато сценаріїв, хіба що пошук статей, а сам стандарт ще в стадії експерименту.

Висновок

«Агентний вебперегляд» це не ще одна оцінка заради оцінки, а сигнал, що в сайтів з'являється новий тип відвідувачів. Приємно, що більша частина вимог збігається зі звичайною якісною роботою: семантична розмітка, нормальна доступність і стабільний макет потрібні і людям, і агентам. А llms.txt і WebMCP це вже наступний крок, за яким варто стежити, поки стандарти дозрівають.

Корисні посилання: як рахується категорія, аудит llms.txt, набір інструментів для agent-ready сайтів, документація WebMCP.