Core Web Vitals, mobile і rendering

Модуль 5 · Урок 18

Core Web Vitals, mobile і rendering

Швидкість — не один score. Професійна діагностика розділяє field і lab data, вимірює LCP, INP та CLS, перевіряє mobile content parity й знаходить конкретний resource, task або layout shift.

LCP ≤ 2.5 sINP ≤ 200 msCLS ≤ 0.175th percentile

Field і lab відповідають на різні питання

Field / CrUXРеальний досвід eligible Chrome users за rolling period; device/network mix і 75th percentile. Показує, чи проблема відбувається в житті.
Lab / LighthouseКонтрольований запуск для diagnosis і повторюваної перевірки. Допомагає знайти причину, але не замінює field population.

PageSpeed Insights може показувати обидва рівні. Не порівнюйте один lab run із origin-level field data як однакові populations і не називайте score «позицією Google».

Три Core Web Vitals

MetricGood thresholdДіагностичне питання
LCP≤ 2.5 sЯкий largest element, коли він discovery-ready, скільки займають TTFB/load/render?
INP≤ 200 msЯкі interactions і long tasks затримують next paint?
CLS≤ 0.1Які elements рухаються без user expectation і чому?

Оцінюйте приблизно 75-й percentile окремо для mobile та desktop. «Good» одного URL не виправдовує повільний template cluster.

Від metric до root cause

LCP. Server latency, render-blocking CSS, priority/preload, image bytes/dimensions, client render delay.
INP. Long JavaScript tasks, expensive event handlers, DOM work, main-thread contention, відсутній feedback.
CLS. Images/ads/embeds без dimensions, injected banners, font swaps, content inserted above viewport.
Regression. Third-party tags, experiments, consent/chat widgets, theme/template release і cache/CDN changes.

Оптимізуйте конкретну причинну частину. «Стиснути всі картинки» без LCP evidence або «видалити весь JS» без ownership/risk — не backlog.

Mobile-first parity

Google переважно використовує mobile version для indexing. Mobile має містити той самий primary content, descriptive titles/meta, structured data, images/alt та crawlable links, що й desktop. Accordion допустимий, якщо content реально є в rendered DOM і доступний користувачу; приховування важливого content лише за device може змінити indexing.

Responsive layout не гарантує parity

Перевірте mobile rendered DOM, not just screenshot: content, canonical, robots, structured data, hreflang, internal links, image URLs, lazy loading і resource errors.

JavaScript і loading states

Server-rendered або pre-rendered critical content знижує залежність від client execution. Якщо content приходить через API, обробляйте errors, loading і empty state; не вимагайте click/scroll для завантаження важливого тексту. Lazy-load images у viewport обережно: LCP resource має бути discoverable та пріоритетним.

Performance acceptance
Field population and window → affected template/URLs → lab reproduction → root-cause evidence → proposed change → functional/accessibility guardrails → before/after lab → field monitoring date → rollback owner.

Практика уроку

  1. Виберіть три representative URLs одного template.
  2. Запишіть field source/scope і lab conditions окремо.
  3. Для одного poor metric назвіть exact element/task/shift та evidence.
  4. Порівняйте mobile/desktop content, metadata, links і structured data.
  5. Створіть одну narrow recommendation із acceptance, guardrail і owner.

Офіційні джерела

← НазадДалі →
Практична перевірка · урок 18 з 42

Закріпіть матеріал уроку

Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.

1. Які метрики є Core Web Vitals зараз?
2. Який good threshold для LCP?
3. Який good threshold для INP?