Отваряте PageSpeed Insights, въвеждате сайта си и виждате 48 от 100 на мобилни устройства. Под резултата има списък с технически препоръки: LCP, JavaScript, изображения, блокиращи ресурси. Кое от всичко това действително трябва да поправите?
Полезният резултат от теста е конкретен план: коя страница има проблем, какво забавя посетителите и коя промяна си струва да направите първо.
В това ръководство ще покажем как да използвате Google PageSpeed Insights, да разчитате отчета и да превърнете препоръките в задачи за вашия WordPress сайт.
Какво е Google PageSpeed Insights?
PageSpeed Insights е безплатен инструмент на Google за анализ на производителността на уеб страници на мобилни и настолни устройства. Въвеждате URL адрес и получавате отчет с измервания и предложения за подобрение.
Той съчетава данни от реални посещения, когато са налични, и лабораторен тест с Lighthouse. Това са различни източници на информация и трябва да ги разглеждате отделно. Официално описание на PageSpeed Insights.
Отворете PageSpeed Insights и оставете отчета пред себе си, докато следвате стъпките.
HOW-TO
Как да тествате сайта си с PageSpeed Insights — стъпка по стъпка
1. Изберете страниците, които са важни за бизнеса
Започнете с три до пет представителни адреса. За фирмен сайт това могат да бъдат началната страница, основна услуга, рекламна лендинг страница и блог статия. За магазин добавете категория и продукт.
Например една продуктова страница може да съдържа галерия, вариации и отзиви, които липсват на началната. Само тестът на началната страница няма да ви покаже как работи този шаблон.
Подгответе списък с точните адреси. Използвайте крайната HTTPS версия, към която действително водите посетителите.
2. Въведете адреса в PageSpeed и стартирайте анализа
В полето на PageSpeed Insights поставете пълния URL и натиснете Analyze / Анализиране. След появата на отчета разгледайте разделите Mobile и Desktop. Може да отворете инструмента директно от тук.
Проверете и показаната снимка на страницата. Ако виждате защитна проверка, съобщение за грешка или екран за поддръжка, първо установете защо тестът не е достигнал до нормалното съдържание.
3. Запазете началните резултати от PageSpeed
За избраната страница направете три лабораторни теста в един и същ режим. За всеки показател запишете средната от трите подредени стойности — медианата.
Например при LCP от 3,8, 4,2 и 3,9 секунди запишете 3,9 секунди. Това е работен метод за сравнение, а не изискване на Google.
Запазете датата, адреса, режима и резултатите. Ако сменяте едновременно страницата, устройството и настройките, няма да разберете на какво се дължи разликата.
РЕЗУЛТАТИ
Как да разчетете резултатите от PageSpeed: реални потребители и лабораторни данни
Ето и най-важната част, която крие истинската стойност – как да разчетете резултатите.
- Данните от реални потребители показват натрупаното преживяване: Горната част на отчета използва Chrome User Experience Report, или CrUX. Данните обхващат предходен период от 28 дни. Проверете дали е избрано This URL или Origin. Първото се отнася до конкретната страница, а второто обобщава страниците в съответния origin — комбинацията от протокол, хост и порт. При недостатъчно данни за URL инструментът може да покаже обобщените данни. Ако и те не достигат, няма да има отчет за реалните потребители. Вижте как PageSpeed Insights използва CrUX.
- Лабораторният тест помага да откриете причините: Долната част анализира едно зареждане при зададени условия. Тя е полезна за възпроизвеждане на проблеми и оценка на промени. Двата отчета могат да се различават – реалните посетители използват различни устройства, мрежи и състояния на кеша. Освен това взаимодействат със страницата след зареждането — нещо, което стандартният тест не възпроизвежда изцяло. Научете защо лабораторните и реалните данни се различават.
Практическо правило: използвайте реалните данни, за да установите какъв проблем имат посетителите, а лабораторната диагностика — за да потърсите причината.
Какво означават LCP, INP и CLS?
Тези три показателя образуват Core Web Vitals. Те разглеждат зареждането, реакцията при взаимодействие и визуалната стабилност.
| Показател | Какво показва | Добра стойност |
|---|---|---|
| LCP — Largest Contentful Paint | Кога се появява най-големият видим блок текст или изображение | До 2,5 секунди включително |
| INP — Interaction to Next Paint | Колко бързо страницата показва следващия кадър след взаимодействие | До 200 милисекунди включително |
| CLS — Cumulative Layout Shift | Колко нестабилно е разположението на видимото съдържание | До 0,1 включително |
При реалните данни се оценява 75-ият персентил. Например LCP от 2,5 секунди на този персентил означава, че поне 75% от отчетените зареждания са с LCP до тази стойност. CLS няма мерна единица и не се измерва в секунди. Може да разгледате подробно определения и прагове на Core Web Vitals в тази статия.
Представете си страница за услуга. Основната снимка се появява със закъснение — това може да се отрази на LCP. Менюто реагира мудно на натискане — проверявате INP. Текстът се измества, когато над него се появи изображение — търсите причината за CLS.
А какво е Total Blocking Time?
В лабораторния отчет ще срещнете и TBT — Total Blocking Time. Той измерва блокиращата част на дългите задачи в основната нишка на браузъра през определения период на зареждане.
Високият TBT насочва към работа, която може да затрудни реакцията на страницата. Той е полезен диагностичен показател, но не е INP и не доказва самостоятелно как реагира сайтът през цялото посещение. Научете повече за Total Blocking Time тук.
Какво означава оценката от 0 до 100 в PageSpeed?
Performance е претеглена оценка на лабораторните показатели. Тя не се изчислява чрез преброяване на зелените и червените препоръки. Отстраняването на дадено предупреждение помага на оценката, когато подобри измерваните показатели. Вижте повече по темата как Lighthouse изчислява Performance.
Оценка | Категория |
|---|---|
90–100 | Добра |
50–89 | Нуждае се от подобрение |
0–49 | Слаба |
Тези диапазони се отнасят до лабораторната оценка. Зелен Performance резултат не е равнозначен на успешно премината оценка на Core Web Vitals. Научете подробно как се интерпретират оценките.
Не смесвайте и категориите Performance, Accessibility, Best Practices и SEO. Те проверяват различни аспекти. За този първи преглед запишете проблемите със скоростта в отделен списък със задачи.
Защо мобилният и десктоп резултатът се различават?
Лабораторните режими използват различни условия за устройство и мрежа. Освен това различният размер на екрана може да промени оформлението, зарежданите изображения и елемента, който се отчита като LCP. Затова мобилният резултат не трябва да се сравнява директно с десктоп резултата. Повече за разликите в условията и измерванията може да намерите в тази статия.
Ако имате 95 на Desktop и 58 на Mobile, работете с мобилния отчет и го сравнявайте с последващи мобилни тестове. След промяната проверете и настолната версия, за да потвърдите, че не сте влошили друго оформление.
Чести проблеми в PageSpeed Insights и как да ги отстраните
Имената на диагностиките се променят с развитието на Lighthouse. Отваряйте подробностите на препоръката и вижте конкретните ресурси, вместо да търсите само познато заглавие.
1. Тежки или прекалено големи изображения
При Improve image delivery прегледайте посочените файлове. Проверете размерите им в пиксели, формата и размера за изтегляне.
Практическият ред, който е препоръчително да се спазва тук,е:
- Подгответе вариант с подходяща резолюция за мястото на показване и плътността на екрана.
- Сравнете компресиран WebP или AVIF с оригинала.
- Проверете дали страницата действително зарежда оптимизирания вариант.
- Повторете теста.
Responsive изображенията позволяват на браузъра да избира между варианти чрез srcset и sizes. Само визуално смаляване на голяма снимка с CSS не намалява изтегления файл. Разгледайте още по темата за препоръки за доставяне на изображения.
За подготовката на файловете следвайте ръководството ни за компресиране на снимки за уеб. В него ще намерите практически стъпки за намаляване на размера и конвертиране на изображенията.
2. Висок LCP: основното съдържание се появява късно в PageSpeed
Отворете диагностиката за LCP breakdown и идентифицирайте отчетения елемент. Той може да бъде снимка или текст — не приемайте автоматично, че е банерът.
Ако е изображение, проверете дали браузърът го открива рано и дали не е отложено с lazy loading. LCP изображението не бива да чака приближаване до видимата област, за да започне да се зарежда.
Разгледайте къде се губи времето: до първия отговор, преди започване на изтеглянето, при самото изтегляне или преди показването. Компресирането няма да реши изцяло проблем, при който малка снимка остава скрита от анимация. Вижте стъпките за оптимизация на LCP.
3. Бавен първи отговор: проверете TTFB
Time to First Byte показва времето до получаването на първия байт от отговора. То включва повече от изпълнението на WordPress: пренасочванията, установяването на връзка и мрежовото разстояние също имат значение.
При висок TTFB проверете веригата от пренасочвания, кеширането на публичните страници и натоварването на хостинга. Ако проблемът остава, необходима е диагностика на сървъра и приложението. Относно оптимизацията на TTFB, посетете следната статия.
Ако следващата задача е кеширането на WordPress, следвайте ръководството ни за настройки на WP Rocket. За работа с CDN разгледайте настройката на Cloudflare за WordPress, включително проверките за HTTPS и кеша. Изберете действието според откритата причина — CDN няма да поправи сам бавна заявка към базата данни.
4. Блокиращи CSS и JavaScript ресурси
При Render-blocking requests браузърът чака ресурси, преди да покаже първоначалното съдържание. Отворете списъка и установете кои принадлежат на темата, плъгините или външна услуга.
Възможните решения включват намаляване на ненужния код и отлагане на ресурси, които не са необходими за първото показване. При WordPress част от това може да се управлява чрез плъгин за оптимизация. Обяснение на блокиращите ресурси.
За конкретните опции и проверките след активирането им вижте ръководството ни за ускоряване на WordPress с WP Rocket. Прилагайте настройките поотделно. След всяка промяна проверявайте мобилното меню, формата, галерията и покупката. Ресурс, който не е използван при първоначалното зареждане, може да е необходим след натискане на бутон.
4. Висок INP: страницата реагира бавно
Повторете конкретни действия: отваряне на меню, филтриране на продукти, избор на вариация и писане във форма. Пробвайте и докато страницата още се зарежда.
След като възпроизведете бавната реакция, разработчик може да проследи обработката ѝ с инструментите на браузъра. Причината може да е продължително изпълнение на JavaScript или тежка работа по оформлението. Оптимизацията може да изисква разделяне на дълги задачи и намаляване на работата при взаимодействие. Как да диагностицирате и подобрите INP.
При Elementor започнете с преглед на сложните секции и интерактивните добавки. В ръководството ни как да ускорите бавен Elementor сайт ще намерите стъпки за преглед на структурата, DOM елементите и зарежданите функционалности.
5. Висок CLS: съдържанието „подскача“
Проверете дали изображенията и вградените елементи имат предварително резервирано пространство. Прегледайте и банери или шрифтове, които променят оформлението след първото показване.
Решението може да бъде задаване на ширина и височина на изображението, подходящо съотношение на страните или запазване на място за динамичен блок. Наблюдавайте и какво се случва при скрол, защото размествания могат да възникнат след началното зареждане.
Откъде да започнете с PageSpeed: приоритетен план за оптимизация
За всяка задача запишете засегнатата страница, показателя, вероятната причина и начина за проверка. Нашият предложен ред е:
- Изберете важна страница с установен проблем. Например лендинг страница, към която води активна реклама.
- Поправете най-ясната причина. Ако отчетът посочва прекалено голямо LCP изображение, започнете от него.
- Измерете отново. Ако проблемът остава, разгледайте следващата част от забавянето.
- Проверете сходните шаблони. Поправка в общия header може да засегне много страници.
- Запишете резултата и следващата задача. Не активирайте всички оптимизации наведнъж.
Пример: как превръщаме един отчет в задачи
Следните стойности са измислен учебен пример, а не измерване на vectory.bg или клиентски сайт.
Представете си мобилен тест на страница за услуга с LCP 4,8 секунди, TBT 420 ms и CLS 0,18. Отчетът посочва голяма снимка в първата секция и разместване около нея.
Наблюдение | Задача | Как потвърждаваме резултата |
|---|---|---|
Отчетеното LCP изображение е прекалено тежко | Подготвяме подходящ вариант и проверяваме кога започва зареждането му | Нов тест и преглед на LCP разбивката |
Около снимката има разместване | Запазваме място според съотношението ѝ | Проверка на CLS и визуално наблюдение |
TBT остава висок | Проследяваме тежките задачи и съответните скриптове | Ново измерване и тест на взаимодействията |
Не определяме предварително какъв ще бъде новият резултат. Първо проверяваме дали причината е потвърдена и дали промяната помага.
Как да измерите ефекта от промените?
Използвайте един и същ URL, режим и сравними условия. Ако работите с кеш, записвайте дали тестът е непосредствено след изчистване или след предварително зареждане. Избягвайте сравнение на различни версии на съдържанието.
Тази таблица е шаблон за попълване:
Показател | Преди | След |
|---|---|---|
Дата и режим | Попълнете | Попълнете |
LCP — медиана от 3 теста | Попълнете | Попълнете |
TBT — медиана от 3 теста | Попълнете | Попълнете |
CLS — медиана от 3 теста | Попълнете | Попълнете |
Performance — медиана от 3 теста | Попълнете | Попълнете |
Форма: изпратена и получена | Да / не | Да / не |
Мобилно меню и ключови действия | Работят / проблем | Работят / проблем |
Лабораторният тест може да покаже ефекта веднага след внедряването. Реалните данни се променят постепенно, докато новите посещения заместват старите в отчетния период. Не очаквайте историческият отчет да отрази изцяло промяната в същия ден. Научете как да сравнявате лабораторни и реални данни.
Трябва ли да постигнете 100/100 в PageSpeed Insights?
100/100 може да бъде техническа цел, но не е универсално условие за успешен сайт. Performance е обобщение на конкретен лабораторен тест и може да се колебае между изпълненията. Какво влияе върху оценката може да разгледате подробно.
Нашата препоръка е да приоритизирате добри реални показатели, работещи потребителски действия и устойчиво подобрение. След като основните проблеми са решени, преценете дали допълнителната работа за няколко точки носи достатъчна полза.
Влияе ли PageSpeed Insights върху SEO?
Google използва Core Web Vitals в системите си за класиране, но добрите стойности не гарантират първи позиции. Качеството и релевантността на съдържанието също имат значение. Вижте какво е отношението на Google за преживяването на страницата и класирането.
Затова разглеждайте оптимизацията като част от SEO работата. Използвайте и отчета за Core Web Vitals в Search Console, за да проследявате проблемите в по-широк набор от страници. Повече за препоръките на Google Search Central.
Често задавани въпроси
Защо PageSpeed Insights не показва данни от реални потребители?
Възможно е да няма достатъчно данни за URL адреса или неговия origin. Това само по себе си не е оценка за скоростта. Започнете с наличната лабораторна диагностика.
Защо резултатът е различен при втория тест?
Условията и ресурсите, които страницата зарежда, могат да се променят. Затова сравнявайте поредица от тестове и самите показатели, вместо да правите извод от един резултат.
Един плъгин достатъчен ли е за оптимизацията?
Зависи от причината. Плъгин може да помогне с кеширането и доставянето на ресурси, но проблемът може да изисква промяна в изображение, оформление, външна интеграция или сървърна настройка.
Колко често да тествам сайта?
Като работен навик препоръчваме тест след значима промяна: нов шаблон, галерия, видео, маркетингов скрипт или настройка за кеширане. Запазете списък с представителни страници и използвайте него за сравненията.
Кога е необходим професионален одит на скоростта?
Потърсете помощ, когато знаете кой показател е проблемен, но не можете да установите причината; когато лабораторните и реалните данни се разминават силно; или когато оптимизацията нарушава важни функции.
Изпратете на екипа точните URL адреси, отчетите, направените промени и пример за бавното действие. Така анализът ще започне от конкретен проблем.
Ако искате да подобрите скоростта на вашия WordPress сайт, свържете се с Vectory. Ще обсъдим кои страници са важни за бизнеса ви и какви проверки са необходими, за да подредим задачите по приоритет.
СКОРОСТ
Оптимизация на уебсайт с Vectory Design?
Можете да се възползвате от нашата услуга за оптимизиране на производителността и надеждността за вашият сайт чрез цялостна оптимизация, технически настройки, повишаване на скоростта, SEO др. Потърсете нашият екип за допълнителна информация!
