Клиент с онлайн магазин за професионална козметика ни се обади притеснен. Беше пуснал сайта си през PageSpeed Insights, видял е червено 34 на мобилни устройства и е решил, че някой го е излъгал при изработката. Отворихме доклада заедно. Оказа се, че основната тежест идва от четири скрипта за проследяване, два от които бяха останали от кампания отпреди година и вече не се използваха от никого. Премахването им отне двадесет минути. Резултатът скочи на 71, а средното време за зареждане на продуктова страница падна от 4,8 на 2,1 секунди.
Историята е типична. PageSpeed Insights е безплатен, отворен за всеки и точно затова се превръща в източник на паника. Хората виждат число, реагират на числото и пропускат това, което инструментът всъщност им казва. Тази статия обяснява как се чете докладът, кои метрики влияят на позициите в Google и какво реално си струва да поправите първо.
Какво измерва PageSpeed Insights
PageSpeed Insights е инструмент на Google, който анализира една страница и връща оценка от 0 до 100, отделно за мобилни и за настолни устройства. Важното, което мнозина пропускат: докладът съдържа два различни типа данни и те не са взаимозаменяеми.
Първият тип са лабораторните данни. Google зарежда страницата в контролирана среда, със симулирана мобилна връзка и ограничен процесор, и измерва какво се случва. Оттам идва цветната оценка. Тя е диагностичен инструмент, не оценка на бизнеса ви.
Вторият тип са полевите данни, идващи от Chrome User Experience Report. Това са реални измервания от истински посетители на вашия сайт през последните 28 дни. Ако сайтът ви има достатъчно трафик, тази секция се появява най-горе в доклада и е далеч по-важна от оценката отдолу. Google използва точно полевите данни при класирането, не лабораторните.
Защо резултатите се променят при всяко пускане
Ако пуснете PageSpeed Insights три пъти подред, вероятно ще получите три различни числа. Разликата от 5 до 10 точки е нормална и се дължи на натоварването на сървърите на Google, на кеша и на моментното състояние на вашия хостинг. Затова не преследвайте конкретна цифра. Гледайте тенденцията през няколко измервания и се фокусирайте върху конкретните препоръки в доклада.
Core Web Vitals: трите метрики, които Google брои
Google свежда потребителското изживяване до три измерими показателя. Те се наричат Core Web Vitals и са част от алгоритъма за класиране от 2021 година насам.
LCP (Largest Contentful Paint) измерва кога се появява най-големият видим елемент на екрана, обикновено главното изображение или заглавието. Добър резултат е под 2,5 секунди. Това е метриката, която най-точно отговаря на въпроса "кога посетителят вижда, че страницата се е заредила".
INP (Interaction to Next Paint) измерва колко бързо страницата реагира, когато потребителят натисне бутон, отвори меню или попълни поле. Заменя старата метрика FID през март 2024 и е по-строга от нея. Добър резултат е под 200 милисекунди.
CLS (Cumulative Layout Shift) измерва колко елементите подскачат по време на зареждане. Всеки, който е натискал бутон и е попадал на реклама, защото страницата се е разместила в последния момент, знае защо тази метрика съществува. Добър резултат е под 0,1.
Как се четат праговете
| Метрика | Добър | Нуждае се от подобрение | Слаб | Какво я разваля най-често |
|---|---|---|---|---|
| LCP | до 2,5 сек | 2,5 до 4 сек | над 4 сек | тежки изображения, бавен сървър |
| INP | до 200 мс | 200 до 500 мс | над 500 мс | излишен JavaScript, тежки плъгини |
| CLS | до 0,1 | 0,1 до 0,25 | над 0,25 | липсващи размери на изображения, шрифтове |
Google оценява 75-ия персентил от реалните посещения. Тоест ако три четвърти от посетителите ви имат LCP под 2,5 секунди, страницата минава, дори останалите да са на по-бавна връзка.
Кои проблеми си струва да поправите първи
Докладът на PageSpeed Insights изброява десетки препоръки и повечето от тях носят по няколко десети от секундата. Смисълът е в приоритизирането. Ето какво в практиката ни дава най-голям ефект за най-малко усилие.
Изображения
Това е първопричина номер едно за бавни сайтове в България. Типичният случай: снимка, качена директно от телефона, 4000 на 3000 пиксела, 6 мегабайта, показвана в контейнер с ширина 400 пиксела. Браузърът тегли целите 6 мегабайта, за да покаже нещо, което изисква под 100 килобайта.
Три действия решават почти всичко. Преоразмерете изображенията до реалните им размери преди качване. Конвертирайте ги в WebP или AVIF, което спестява между 25 и 50 процента спрямо JPEG при същото визуално качество. Включете отложено зареждане за всичко под сгъвката, така че снимките в дъното на страницата да се теглят чак когато потребителят стигне до тях.
Скриптове от трети страни
Всеки пиксел за проследяване, чат виджет, инструмент за отзиви и банер за бисквитки добавя тежест. Направете инвентаризация: отворете раздела Network в инструментите за разработчици и вижте какво точно се зарежда. Почти винаги има поне един скрипт, който никой вече не използва.
Останалите скриптове могат да се отложат. Чат виджетът не е нужен в първата секунда от зареждането, нито инструментът за анализ на heatmap. Атрибутите defer и async, както и отложеното инициализиране след първо взаимодействие, свалят INP чувствително.
Хостинг и сървърно време
Метриката TTFB (Time to First Byte) показва колко време минава, преди сървърът изобщо да отговори. Ако тя е над 800 милисекунди, никаква оптимизация на изображенията няма да ви спаси. Причините обикновено са три: препълнен споделен хостинг, липса на кеширане на ниво сървър или база данни, която не е чиствана от години.
Сървър, разположен в България или в близък европейски център за данни, дава осезаемо предимство за българска аудитория. Ако не сте сигурни какво имате, започнете с нашето сравнение на хостинг решения.
Шрифтове
Персонализираните шрифтове изглеждат добре и мълчаливо влошават CLS. Когато браузърът изчаква изтеглянето на шрифта, текстът или е невидим, или се показва със заместващ шрифт и после подскача. Решението е font-display: swap, предварително зареждане на основния шрифт и ограничаване до два шрифта максимум с не повече от три дебелини общо.
Какво е специфично за WordPress и WooCommerce
Голяма част от българските сайтове стъпват на WordPress, а там проблемите със скоростта имат повтарящ се профил. Знанието кои са те спестява дни лутане.
Първо, темата. Универсалните теми с вграден конструктор носят стотици килобайта CSS и JavaScript, от които реално използвате може би десет процента. Ако темата зарежда цялата си библиотека с икони, за да покаже три икони, това се вижда веднага в доклада. Понякога най-бързото решение е смяна на темата, а не оптимизация върху нея.
Второ, плъгините. Средният български корпоративен сайт носи между двадесет и тридесет плъгина, като част от тях зареждат ресурси на всяка страница, дори там, където функцията им не се използва. Класически пример: плъгин за формуляри, който слага скриптове и стилове на началната страница, макар формулярът да е само на страницата за контакти.
Трето, при онлайн магазините WooCommerce добавя собствени скриптове и заявки към базата на всяка страница. Кошницата и количките с динамични фрагменти са честа причина за бавно зареждане на блога и информационните страници, където изобщо не са нужни.
Практичен ред на действие
Започнете с кеширащ плъгин и настройка на изображенията, защото това дава най-бърз резултат. После измерете отново. Ако сте под целта, минете към почистване на плъгини и условно зареждане на скриптове по тип страница. Смяна на темата или на хостинга оставете за накрая, защото са най-скъпите ходове. Ако сайтът ви е на WordPress, повече контекст има в ръководството ни за изработка на WordPress сайт.
PageSpeed Insights срещу реалното изживяване
Тук идва най-честото недоразумение. Оценка 100 не означава бърз сайт, а оценка 60 не означава бавен. Инструментът измерва техническо изпълнение, не възприемана скорост.
Виждали сме сайтове с оценка 95, които изглеждат бавни, защото главното изображение се появява последно. И сайтове с оценка 62, които се усещат мигновени, защото критичното съдържание е първо в реда на зареждане, а всичко останало идва след това.
Какъв резултат е достатъчен
За повечето български бизнеси разумната цел изглежда така: всички три Core Web Vitals в зелено при полевите данни, оценка над 70 на мобилни устройства и LCP под 2,5 секунди. Изкачването от 85 на 98 обикновено струва повече часове, отколкото носи стойност, и по-добре ги вложете в съдържание или в реклама.
Изключение правят онлайн магазините с голям трафик. Там всяка десета от секундата има измерима цена, защото се умножава по броя посетители в кошницата.
Как да следите скоростта постоянно
Еднократната проверка е снимка на момента. Скоростта се влошава постепенно, обикновено след добавяне на нов плъгин, нова кампания с проследяване или качване на галерия със снимки от събитие.
Google Search Console има отделен отчет Core Web Vitals, който показва вашите страници, групирани по проблем, на база реални посещения. Той е по-полезен от еднократното пускане на PageSpeed Insights, защото покрива целия сайт, а не една страница. Подробно за настройката има в статията ни за Google Search Console.
За по-прецизно наблюдение работят и инструменти като WebPageTest, който позволява тестване от конкретна географска локация и с конкретна скорост на връзката. За български сайт е логично да тествате от Европа при мобилна 4G връзка, а не от Северна Америка при оптика.
Ритъм на проверките
Веднъж месечно за информационен сайт е достатъчно. За онлайн магазин, и особено след всяка промяна по темата или добавяне на функционалност, проверката трябва да е част от процеса. Ако поддържате сайта си сами, добавете я към месечния си списък заедно с редовната поддръжка.
Често задавани въпроси
Влияе ли скоростта на сайта на позициите в Google?
Да, но не толкова силно, колкото се твърди. Core Web Vitals са потвърден фактор за класиране, но релевантността на съдържанието тежи много повече. Скоростта става решаваща, когато две страници са сравнимо добри по съдържание: тогава по-бързата печели. Косвеният ефект е дори по-голям, защото бавните сайтове губят посетители преди зареждането и това се вижда в поведенческите сигнали.
Какъв резултат в PageSpeed Insights е добър?
Над 90 се смята за отличен, между 50 и 89 за среден, под 50 за слаб. Практически, стремете се към над 70 на мобилни устройства и трите Core Web Vitals в зелено. Мобилният резултат е винаги по-нисък от настолния, защото Google симулира по-слаб процесор и по-бавна връзка.
Защо мобилният ми резултат е много по-нисък от настолния?
Заради условията на теста. Google симулира устройство от среден клас на 4G връзка. Настолният тест използва бърза връзка и мощен процесор. Разлика от 20 до 30 точки между двата е напълно нормална. Тъй като над 70 процента от българския трафик идва от телефони, мобилният резултат е този, който има значение.
Мога ли да оправя скоростта с плъгин?
Отчасти. Кеширащ плъгин като LiteSpeed Cache или WP Rocket решава голяма част от проблемите на WordPress сайт и често дава най-бързото подобрение за най-малко работа. Но плъгин не може да компенсира претрупана тема, слаб хостинг или петдесет неоптимизирани изображения. Понякога добавянето на още плъгини за оптимизация влошава нещата, защото те се конкурират помежду си.
Колко време отнема оптимизацията на скоростта?
За типичен корпоративен сайт основните подобрения се правят за един до два работни дни: изображения, кеширане, почистване на скриптове. Онлайн магазин с хиляди продукти изисква повече, обикновено между три и пет дни, защото продуктовите изображения се обработват групово, а проверката се прави по шаблони. Ако проблемът е в самата тема или в архитектурата, разговорът е за преработка, не за оптимизация.
Накратко
PageSpeed Insights е диагностика, не присъда. Чете се отгоре надолу: първо полевите данни, после конкретните препоръки, оценката накрая. Изображенията, скриптовете от трети страни и сървърното време покриват мнозинството от реалните проблеми и се решават без пренаписване на сайта.
Ако сте пуснали теста, видели сте червено и не сте сигурни кое от изброените неща се отнася за вас, изпратете ни адреса на сайта през формата за контакт. Правим безплатен преглед и връщаме конкретен списък с приоритети, а при нужда и оферта до 24 часа. Ако пък планирате нов сайт, скоростта е част от начина, по който подхождаме към изработката още от първия ден.
