Google официално направи Core Web Vitals фактор за класиране през 2021 г. Оттогава SEO индустрията е произвела огромен обем съвети за LCP, INP и CLS — повечето фокусирани върху постигането на зелена оценка в PageSpeed Insights.
Проблемът: зелената оценка не означава, че реално сте подобрили приходите на магазина си. Някои от най-въздействащите оптимизации, правени от нас, почти не влияят на PageSpeed оценките. А някои промени, движещи значително оценките, почти не влияят на реалните потребители.
Ето какво реално има значение за е-търговски магазини — и какво можете спокойно да депriоритизирате.
Метриките, движещи приходите
LCP (Largest Contentful Paint): Най-важната метрика
LCP измерва колко отнема зареждането на най-големия видим елемент на страницата — обикновено вашето hero изображение, продуктова снимка или банер над сгъвката.
За е-търговия, LCP е метриката, най-пряко свързана с приходите. Причината е интуитивна: когато клиент попадне на продуктова страница, продуктовото изображение обикновено е LCP елементът. Ако то се зарежда бавно, клиентът стои на частично заредена страница и решава дали да изчака или да излезе.
Прагът от значение: под 2,5 секунди е „добро”, 2,5–4 секунди е „нуждае се от подобрение”, над 4 секунди е „лошо”. Но за е-търговия трябва да се целите под 2 секунди на мобилни устройства — не просто да преминете прага от 2,5 секунди.
Какво реално движи LCP:
Времето за отговор на сървъра (TTFB) е upstream проблемът, пренебрегван от повечето магазини. Ако сървърът ви отнема 800 мс за отговор, вече сте изхарчили 800 мс преди да е заредил единствен байт от страницата. Никаква оптимизация на изображения не поправя бавен сървър. Това обикновено е проблем с хостинга.
Форматът и размерът на изображенията е оптимизацията с най-висок leverage за повечето WooCommerce магазини. Редовно намираме продуктови изображения, сервирани с ширина 2400px на мобилни потребители, виждащи ги при 400px, в JPEG формат, без WebP алтернативи. Само поправянето на това нерядко съкращава LCP с 1–2 секунди.
Приоритизирането на ресурсите е по-важно, отколкото повечето ръководства признават. Браузърът трябва бързо да открие LCP изображението и незабавно да го изтегли. Ако то е CSS фоново изображение, или е зад стена от render-blocking скриптове и стилове, то се открива късно независимо колко добре е оптимизирано самото изображение. fetchpriority="high" на LCP изображението е един ред код с измеримо въздействие.
INP (Interaction to Next Paint): Новата метрика, объркваща всички
INP замени FID (First Input Delay) през март 2024 г. Докато FID измерваше само забавянето преди браузърът да започне обработка на първото ви кликване, INP измерва пълната латентност на всички взаимодействия по целия период на посещение на страницата — от кликване или докосване до следващата визуална актуализация.
Тази промяна е от голямо значение за е-търговия, защото checkout процесите са богати на взаимодействия. Добавяне в количката, обновяване на количества, прилагане на купони, избор на метод за доставка — всяко от тях е взаимодействие, измервано от INP.
Лошият INP на WooCommerce магазин почти винаги идва от изпълнението на JavaScript. Обичайните виновници:
Скриптове на трети страни, зареждани синхронно. Анализи, чат уиджети, маркетингови пиксели, уиджети за отзиви — те нерядко изпълняват големи количества JavaScript на главния нишков процесор. Всеки добавя към латентността на взаимодействието. Измервали сме подобрение на INP от 300–400 мс само от преместване на скриптове на трети страни да се зареждат след взаимодействие с потребителя, а не при зареждане на страницата.
AJAX заявки на WooCommerce, блокиращи UI. Когато клиент кликне „Добави в количката” и бутонът остава неотзивчив 800 мс докато AJAX заявката се обработва, това е лошо INP събитие. Решението не е само ускоряване на сървъра (макар и то да помага) — а незабавно обновяване на UI за потвърждение на взаимодействието, след което потвърждаване след отговор на сървъра.
Bloat от page builder-и. Много page builder-и зареждат цялото си JavaScript runtime на всяка страница, включително такива без интерактивни елементи. Страница с продуктов архив не се нуждае от същия JS footprint като страница с конфигурируем продукт.
CLS (Cumulative Layout Shift): Най-дразнещата, но с най-малко влияние върху приходите
CLS измерва колко съдържание на страницата се измества при зареждане — изображения без размери, изскачащи и натискащи съдържанието надолу, шрифтове, сменящи се и преформатиращи текста, реклами, зареждащи се в пространства, нерезервирани за тях.
Високата CLS оценка реално влошава потребителското изживяване. Но от нашия опит с десетки WooCommerce сайтове, подобренията на CLS корелират по-слабо с приходите от подобренията на LCP или INP. Изключението е checkout-ът: изместване на оформлението по време на взаимодействие с форма за плащане — при което бутонът за потвърждение се премества точно когато някой кликва върху него — е катастрофално. Виждали сме такова явление да причинява скокове в изоставянето на количката.
Поправянето на CLS е предимно хигиенна работа: задайте изрична ширина и височина на всички изображения, резервирайте пространство за динамично съдържание, използвайте font-display: swap или optional внимателно (swap реално може да увеличи CLS на бавни връзки) и тествайте checkout процеса специално.
Оптимизациите по принципа 80/20
Ако искате да знаете откъде да започнете, ето честната приоритизация за типичен WooCommerce магазин:
1. Поправете хостинга първо. Това е единствената промяна с най-голямо въздействие върху всичките три метрики. Сървър, отговарящ за 150 мс вместо 800 мс, подобрява LCP директно, дава на INP повече времеви бюджет за изпълнение на JavaScript и премахва TTFB overhead-а, затрудняващ всичко останало. Управляваният WordPress хостинг с кеширане на ниво сървър не е опционален, ако сте сериозни за производителността.
2. Сервирайте модерни формати на изображения с правилни размери. Конвертирайте продуктовите изображения в WebP или AVIF. Сервирайте подходящо оразмерени изображения чрез srcset. Задайте изрични атрибути за ширина и височина. Само това адресира мнозинството от LCP проблемите на продуктово-ориентирани страници.
3. Одитирайте и отложете скриптовете на трети страни. Отворете таба Network в браузъра и преброете колко домейна на трети страни зареждате на продуктова страница. Всеки е потенциален INP и LCP проблем. Google Tag Manager по-специално нерядко е неправилно конфигуриран — зарежда десетки тагове синхронно, когато трябва да бъдат отложени или премахнати изцяло.
4. Активирайте full-page кеширане на ниво сървър. LiteSpeed Cache, Nginx FastCGI кеш или CDN с HTML кеширане — всичко, сервиращо кеширани страници на анонимни посетители без достигане до PHP или базата данни. Това е най-важната WooCommerce-специфична оптимизация и тази, пропускана най-често при споделен хостинг.
5. Оптимизирайте WooCommerce AJAX обработването. Ако добавянето в количката, обновяването на количества и прилагането на купони се усещат бавно, профилирайте AJAX handlers-ите. Чести причини: скъпи заявки към базата данни, задействани при всяко обновяване на количката, плъгини, добавящи се към изчисленията на количката без нужда, липса на обектно кеширане (Redis/Memcached) — при което всяка заявка удря базата данни от нулата.
Какво е надценено
Обсебването от PageSpeed Insights оценки. PageSpeed изпълнява единичен симулиран тест на ограничена мобилна връзка от Google дата център. Реалните ви потребители имат различни устройства, различни връзки и различни географски разстояния от сървъра ви. Виждали сме магазини с PageSpeed оценка 45, конвертиращи по-добре от конкуренти с оценка 90 — защото магазинът с оценка 90 кешираше статични активи тежко (лесни за PageSpeed печалби), пренебрегвайки времето за отговор на сървъра и изпълнението на JavaScript, на които PageSpeed дава по-малка тежест.
Елиминирането на render-blocking ресурси на всяка цена. Да, render-blocking CSS и JavaScript забавят рендерирането. Но агресивното inline-ване или отлагане на всичко може да въведе по-лоши проблеми — FOUC (светкавица на нестилизирано съдържание), CLS от закъснели стилове, счупени интерактивни елементи. Целта е бърза, правилна страница — не максимална оценка.
Lazy loading на всичко. Lazy loading на изображения под сгъвката е правилен и ефективен. Lazy loading на първото продуктово изображение на страница с категории — което обикновено е LCP елементът — активно вреди на оценката и потребителското изживяване. Редовно намираме WooCommerce теми и плъгини, прилагащи loading="lazy" на всяко изображение на страницата без разбор.
Премахването на плъгини за намаляване на HTTP заявките. Bundling и кеширането направиха отделните HTTP заявки по-маловажни от 2015 г. насам. Премахването на плъгин, защото добавя една HTTP заявка, докато той предоставя реална функционалност, оптимизира грешното нещо. Важното е какво зареждат тези заявки: 50KB JavaScript bundle е проблем, 2KB CSS файл не е.
Реални резултати: Как изглеждат типичните подобрения
На WooCommerce магазин за дрехи, с който работихме наскоро: началният одит показа LCP от 5,2 сек. на мобилни, INP от 420 мс, CLS от 0,18. И трите — „лошо” или „нуждае се от подобрение”.
Работата, по ред:
- Мигриране от споделен хостинг към управляван WordPress VPS с LiteSpeed — TTFB спадна от 820 мс до 95 мс
- Конвертиране и оразмеряване на продуктовите изображения в WebP с правилен srcset — LCP спадна от 5,2 сек. до 2,1 сек.
- Добавяне на
fetchpriority="high"на първото продуктово изображение на страниците с архиви — LCP спадна допълнително до 1,8 сек. - Одит и отлагане на некритични скриптове на трети страни чрез GTM — INP спадна от 420 мс до 180 мс
- Задаване на изрични размери на изображения в целия сайт и поправяне на проблем с зареждане на шрифтове — CLS спадна от 0,18 до 0,04
Крайни оценки: LCP 1,8 сек., INP 180 мс, CLS 0,04. Всичко зелено. Органичният трафик от продуктови категорийни страници се увеличи с 23% през следващото тримесечие, тъй като страниците спечелиха класиращи позиции, губени преди на по-бързи конкуренти.
Общото изпълнение отне около 12 часа фокусирана работа. Без редизайн, без нова тема, без сериозни промени в кода.
Практическата отправна точка
Стартирайте тест в PageSpeed Insights на началната страница, най-важната категорийна страница и най-важната продуктова страница. Погледнете полевите данни (не само лабораторните), ако сайтът ви има достатъчно трафик.
След това погледнете TTFB първо. Ако е над 400 мс, хостингът е вашето тясно място и всичко останало е второстепенно. Ако TTFB е добро, преминете към LCP и идентифицирайте LCP елемента. Изображение ли е? Оптимизирано ли е? Приоритизирано ли е?
За INP, Chrome User Experience Report ви дава реални потребителски данни. Ако INP е в лошия диапазон, сесия за JavaScript профилиране в Chrome DevTools ще ви покаже точно кои взаимодействия са бавни и защо.
Работата по производителността има натрупващо качество: всяко подобрение прави следващото по-въздействащо. Магазин, поправящ хостинга си, след това изображенията, след това изпълнението на JavaScript, ще види значително по-добри резултати от такъв, опитващ да реши всичките три едновременно без правилно нареждане.
Ако искате честна оценка на производителностните тесни места на магазина ви и кои са оптимизациите с най-висок leverage, нашата услуга за техническо SEO включва пълен одит на Core Web Vitals с приоритизирани препоръки.