В тази статия · 12 раздела
- Какво е PageSpeed Insights и какво показва
- PageSpeed Insights, Lighthouse и Search Console: кой инструмент за какво
- Как да проверите скоростта на сайта: 6 стъпки за 20 минути
- Какъв PageSpeed резултат е добър
- Core Web Vitals: LCP, INP и CLS и праговете им
- Влияе ли скоростта на продажбите и на позициите в Google
- Какво зависи от платформата и какво от вас
- Как да ускорите онлайн магазина: 10 поправки по ефект
- Как да проверите снимките на целия каталог със Здраве на снимките
- Как да следите скоростта с AI асистент вместо ръчно
- Грешки, които гонят 100 точки и губят поръчки
- Често задавани въпроси
Накратко: PageSpeed Insights е инструментът на Google, който оценява скоростта на сайта от 0 до 100 точки за телефон и компютър. Добър резултат е 90 и нагоре. За класирането обаче решават Core Web Vitals на реалните посетители: LCP до 2,5 секунди, INP до 200 милисекунди и CLS до 0,1. В онлайн магазина скорост губят най-вече снимките, банерите и външните скриптове.
Какво е PageSpeed Insights и какво показва
PageSpeed Insights (PSI, често търсен и като Google PageSpeed) е инструмент на Google на адрес pagespeed.web.dev, който проверява една страница и дава два вида данни: лабораторен тест и данни от реални посетители (Google for Developers). Влизате без регистрация, поставяте адреса и след около минута виждате резултата в раздели Mobile и Desktop. Същата проверка се пуска и през PageSpeed Insights API, когато искате да мерите много адреси наведнъж или по график.
Двете части на отчета отговарят на различни въпроси. Търговците често гледат само голямото число в кръга, а то е лабораторното.
| Част от отчета | Откъде идва | Какво ви казва | Кога я гледате |
|---|---|---|---|
| Горната част: данни от реални посетители (полеви данни) | Chrome User Experience Report (CrUX): реални посещения от Chrome за последните 28 дни | Минава ли страницата Core Web Vitals. Това вижда Google | Веднъж месечно и след голяма промяна, 4 седмици по-късно |
| Долната част: лабораторен тест | Lighthouse: едно зареждане, симулирано на среден телефон с бавна мобилна връзка | Оценката от 0 до 100 и списък какво бави страницата | Преди и след всяка промяна, веднага |
Полевите данни се появяват само ако страницата има достатъчно посещения от Chrome. При нов или малък магазин PSI показва само лабораторния тест, а полевите данни идват по-късно или само за целия домейн (Origin).
PageSpeed Insights, Lighthouse и Search Console: кой инструмент за какво
PageSpeed Insights, Lighthouse и отчетът Core Web Vitals в Search Console мерят скоростта с едни и същи показатели, но отговарят на различни въпроси. Lighthouse е двигателят на лабораторния тест в PSI и е вграден в Chrome (Chrome for Developers), а Search Console показва полевите данни за всички страници на магазина наведнъж.
| Инструмент | Какво мери | Обхват | За какво го ползва търговецът |
|---|---|---|---|
| PageSpeed Insights | Полеви данни (CrUX) и лабораторен тест (Lighthouse) | Един адрес | Проверка на конкретна страница преди и след промяна |
| Lighthouse в Chrome (F12 → Lighthouse) | Само лабораторен тест, от вашия компютър и връзка | Един адрес | Бърз тест на страница, която още не е публична, например нова тема в демо |
| Search Console → Core Web Vitals | Само полеви данни, групирани по сходни страници | Целият магазин | Кои групи страници (продукти, категории) не минават и дали поправката е сработила |
| Алтернативи: GTmetrix и WebPageTest | Лабораторен тест с подробна времева линия на зареждането (waterfall) | Един адрес | Кой точно файл (снимка, скрипт, шрифт) бави страницата, когато PSI не стига |
Lighthouse в Chrome често дава различна оценка от PSI, защото мери от вашия компютър, с вашите разширения и вашата връзка. GTmetrix и WebPageTest показват собствени оценки, които не съвпадат с точките в PSI; за Google важат Core Web Vitals от реалните посетители. За сравнения във времето ползвайте винаги един и същ инструмент.
Как да проверите скоростта на сайта: 6 стъпки за 20 минути
Скоростта на онлайн магазин се проверява по типове страници, защото началната страница, категорията и продуктът са построени различно. Една проверка само на началната страница не казва нищо за продуктите, от които идват поръчките.
- Изберете 4 адреса. Началната страница, най-посещаваната категория, най-продаваният продукт и страница с резултати от търсене. Кои са най-посещаваните, виждате в Google Analytics 4 или в Search Console.
- Пуснете всеки в PageSpeed Insights. Отворете pagespeed.web.dev, поставете адреса и изберете раздела Mobile. В България 63,65% от посещенията през октомври 2026 са от телефон (StatCounter), така че мобилният резултат е вашият резултат.
- Погледнете първо полевите данни. Ако горе пише, че Core Web Vitals са преминати, магазинът е бърз за Google, каквато и да е оценката отдолу.
- Пуснете лабораторния тест 3 пъти. Оценката се мени с няколко точки при всяко пускане. Запишете средния от трите резултата, не най-добрия.
- Запишете LCP, INP или TBT, CLS и теглото на страницата. Таблица с датата и четирите адреса е достатъчна. Без нея след месец няма да знаете дали промяната е помогнала.
- Отворете отчета Core Web Vitals в Search Console. Там Google групира всички страници на магазина на добри, нуждаещи се от подобрение и лоши, отделно за телефон и компютър (Search Console Help). Как се свързва Search Console с магазина е в статията Google Search Console за онлайн магазин.
Важно: тествайте адреса, който виждат клиентите, с вашия домейн и с https. Тест на страница, в която сте влезли като администратор, или в режим на редакция мери друго.
Какъв PageSpeed резултат е добър
Добър резултат в PageSpeed Insights е от 90 до 100 точки (зелено), 50–89 точки означава, че има какво да се подобри (оранжево), а под 50 е слаб резултат (червено) (Chrome for Developers). Оценката е сбор от пет лабораторни показателя с различна тежест.
| Показател в Lighthouse | Какво мери | Тежест в оценката |
|---|---|---|
| Total Blocking Time (TBT) | Колко време браузърът е зает (скриптове, изчертаване, анимации) и страницата не реагира | 30% |
| Largest Contentful Paint (LCP) | Кога се показва най-големият елемент, обикновено банерът или снимката на продукта | 25% |
| Cumulative Layout Shift (CLS) | Колко скача съдържанието по време на зареждане | 25% |
| First Contentful Paint (FCP) | Кога се показва първият текст или картинка | 10% |
| Speed Index | Колко бързо се запълва видимата част на екрана | 10% |
Над половината от оценката (TBT и LCP) зависи от две неща: колко работа има браузърът (скриптове, анимации, стотици картинки) и колко тежка е първата картинка. Затова магазин с пет пиксела и слайдер от пет снимки често остава под 50 точки на телефон, независимо от хостинга.
Пример от наш замер на cloudcart.com на 04.11.2026 (Lighthouse, мобилен тест). Двете страници са на един и същ хостинг, а разликата е само в съдържанието:
| Страница | Оценка | LCP | TBT | Тегло | Какво има в първия екран |
|---|---|---|---|---|---|
| /pricing | 95 | 2,3 s | 180 ms | 152 KiB | Текст и таблица с плановете |
| Началната страница | 49 | 4,6 s | 4 510 ms | 3 058 KiB | Видео от 1,32 MB, което се сваля цялото предварително, и 268 картинки в една страница |
Lighthouse изчисли за началната страница 1 133 KiB възможна икономия само от снимките. Поправките за нея са същите като в списъка с 10-те поправки по-долу.
Core Web Vitals: LCP, INP и CLS и праговете им
Core Web Vitals са трите показателя, с които Google мери как реалните хора усещат страницата: зареждане (LCP), реакция (INP) и стабилност (CLS) (web.dev). Страницата минава, когато поне 75% от посещенията са в зелената зона и за трите.
| Показател | Какво мери в магазина | Добре | Нужно е подобрение | Лошо |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Кога клиентът вижда банера на началната страница или основната снимка на продукта | до 2,5 s | 2,5–4 s | над 4 s |
| INP (Interaction to Next Paint) | Колко бързо реагират филтърът, бутонът „Добави в количката“ и изборът на размер | до 200 ms | 200–500 ms | над 500 ms |
| CLS (Cumulative Layout Shift) | Дали бутонът или цената се местят, докато се зареждат банери и снимки | до 0,1 | 0,1–0,25 | над 0,25 |
INP замени FID като Core Web Vital през март 2024 (web.dev). INP не се мери в лабораторния тест, защото там никой не натиска бутони. Най-близкият лабораторен заместител е TBT: висок TBT почти винаги означава слаб INP.
В онлайн магазина всеки показател има свой типичен виновник. LCP бавят тежкият банер и видеото в първия екран. INP бавят чатът, пикселите и скриптовете за отзиви, които тръгват с всяка страница. CLS идва от банери с различни пропорции, ленти, вмъкнати над менюто, и шрифтове, които сменят размера на текста.
Влияе ли скоростта на продажбите и на позициите в Google
Да, скоростта влияе пряко на продажбите. В проучването „Milliseconds Make Millions“ на Deloitte за Google (2020) мобилен сайт, по-бърз с 0,1 секунди, е вдигнал конверсията в търговията на дребно с 8,4% (Think with Google). Конверсията е делът на посещенията с поръчка; как се смята и какво друго я вдига е в статията конверсия на онлайн магазин: формула и 20 промени.
За Google скоростта е сигнал за класиране, но не най-силният. Google пише, че системите за класиране използват Core Web Vitals, а най-релевантната страница се показва и при слабо изживяване (Google Search Central, Page experience). На практика бързината решава между две еднакво добри страници, а при равни позиции бързият магазин продава повече от същия трафик. Останалите фактори за позициите на магазина са в статията SEO за онлайн магазин.
Онлайн магазинът трябва да показва основното съдържание до 2,5 секунди на телефон с мобилна връзка. Мерете на телефон, защото офисният компютър с оптичен интернет показва по-добра картина от тази, която виждат клиентите. Проверката на мобилния изглед е описана подробно в статията мобилната версия на онлайн магазина.
Какво зависи от платформата и какво от вас
Скоростта на онлайн магазина зависи от две страни: сървърът и мрежата са на платформата, а снимките, банерите и скриптовете добавя търговецът. При CloudCart, българската платформа за онлайн магазини, хостингът е част от всеки план и не поддържате сървър.
| Какво влияе на скоростта | Кой отговаря в CloudCart | Какво има |
|---|---|---|
| Хостинг и натоварване | Платформата | Скалируем хостинг, който расте с трафика при промоция и Черен петък, без да купувате по-голям сървър (домейн, хостинг и сигурност) |
| Доставка на снимките | Платформата | Снимките на продуктите тръгват от мрежата на Cloudflare (CDN), от точката, най-близка до клиента |
| SSL и защита | Платформата | Сертификатът се издава и подновява сам, а защитата от DDoS атаки на Cloudflare се включва с насочването на домейна |
| Кеш на стиловете | Платформата | След всяко запазване в редактора на темата стилът се обновява и кешът се изчиства сам |
| Размер и брой на снимките | Търговецът | Проверка с приложението Здраве на снимките |
| Банери, слайдери и видео | Търговецът | Дизайн → Модули |
| Пиксели, чатове и чужд код | Търговецът | Приложения и Дизайн → Добавяне на CSS/JS (кодът там е отделен за всяка тема) |
| Тема и шрифтове | Търговецът | Дизайн → Избери дизайн и Дизайн → Цветове и шрифтове |
Ако магазинът ви е на WooCommerce, Magento или OpenCart, първият ред от таблицата е ваш: хостингът, кешът и обновяванията на плъгините определят времето за отговор на сървъра. Това е честа причина търговците да сменят платформата. Как минава смяната стъпка по стъпка е в ръководството за миграция от WooCommerce.
Как да ускорите онлайн магазина: 10 поправки по ефект
Онлайн магазинът се ускорява най-много от по-леката първа картинка и от по-малко скриптове. Поправките са подредени от най-големия към най-малкия ефект за магазин на CloudCart. След всяка пуснете отново PageSpeed Insights за същите 4 адреса.
- Махнете видеото от първия екран. Видео във фона на началната страница е най-тежкият елемент и почти винаги е LCP. Сложете снимка на негово място. Ако видеото е важно за марката, вградете го от YouTube или Vimeo по-надолу в страницата, вместо да качвате mp4 файл в магазина.
- Един банер вместо слайдер от пет снимки. Слайдерът тегли всички снимки, а клиентът вижда първата. В Дизайн → Модули отворете модула на слайдера и оставете 1–2 слайда. Ако темата има и отделен модул за банер, изключете слайдера с превключвателя му и сложете един банер.
- Снимки с разумен размер и формат. Качвайте JPG или WEBP, с най-къса страна от 800 до 2 000 пиксела. Под 800 пиксела Здраве на снимките отчита ниска резолюция за zoom, а снимка от 6 000 пиксела направо от фотоапарата тежи многократно повече, без клиентът да види разлика на телефона. Миниатюри не качвате: CloudCart подава всяка снимка на продукт в размера, който витрината иска, през своята CDN.
- Сменете анимираните GIF. Анимираният GIF е тежък за телефона и товари процесора. Здраве на снимките ги отчита и предлага „Конвертирай в JPEG“, без кредити и с възможност да върнете оригинала.
- Прегледайте Дизайн → Добавяне на CSS/JS. Кодът там се добавя в <head> на всяка страница на витрината, без изключение. Махнете пиксели на кампании, които не вървят, стари тестове и скриптове на услуги, които вече не ползвате.
- Един път за таговете. Свържете Google Analytics 4, Google Tag Manager и рекламните пиксели от Приложения, а не като поставен код. Не слагайте един и същ таг и в приложението, и в Tag Manager: двойният таг бави страницата и брои всяка поръчка два пъти. Подробно: GA4 и Google Tag Manager в онлайн магазина.
- Изключете приложенията във витрината, които не носят продажби. Чат от външна услуга, отзиви от външна платформа и съдържание от производители зареждат свой скрипт от чужд сървър на всяка страница или на продуктовата. Ако чатът получава 2 въпроса на месец, той струва повече скорост, отколкото носи.
- Една фамилия шрифтове. В Дизайн → Цветове и шрифтове изберете един шрифт за заглавия и текст или най-много два. Всеки шрифт и всяка дебелина са отделен файл, който телефонът сваля преди да покаже текста.
- По-малко модули на началната страница. Пет реда с продукти, лента от Instagram, блог и карта са десетки снимки и няколко скрипта. Оставете модулите, на които клиентите кликват, и изключете останалите в Дизайн → Модули.
- Еднакви пропорции на банерите. Банери и слайдове с различна височина карат страницата да скача (CLS). Режете всички банери в една и съща пропорция, например 3:1 за десктоп. Ако темата е стара, проверете по-нова: темите в Дизайн → Избери дизайн имат демо адрес, който можете да пуснете в PageSpeed Insights преди смяната. Продуктите, клиентите и поръчките остават на място при смяна на темата, а модулите на старата тема, които новата няма, трябва да добавите отново.
Важно: мерете след всяка поправка поотделно. Ако махнете пет неща наведнъж и резултатът падне, няма да знаете кое е виновно.
Как да проверите снимките на целия каталог със Здраве на снимките
Здраве на снимките е приложение на CloudCart, което проверява всяка снимка на продукт за качество и изискванията на Google и Meta, дава оценка на каталога от 100 и казва какво да оправите първо. Инсталира се на всеки план, а 50 кредита на месец са включени.
- Отворете Приложения → Здраве на снимките и го инсталирайте. Приложението работи в админа, а витрината се променя само когато приложите поправка.
- В раздела с оценката натиснете сканиране на каталога. Първо минава техническа проверка на продуктите, после AI проверка на снимките, като започва от основните снимки на най-продаваните продукти. Голям магазин се сканира за няколко минути и можете да напуснете страницата.
- Отворете раздела с проблемите. Продуктите, отхвърлени от Google или Meta, са най-отгоре, после тези с най-много приходи за 90 дни. Филтрирайте по проблем: „Неподдържан формат“, „GIF снимка“, „Ниска резолюция“, „Необичайни пропорции“.
- Приложете поправките. „Конвертирай в JPEG“ сменя GIF и неподдържаните формати, а „бели полета“ прави квадрат от много широка или висока снимка. И двете не ползват кредити и пазят оригинала. Alt текстът с AI струва 1 кредит на снимка.
- Оставете автоматичната проверка включена. В настройките на приложението автоматичната проверка на новите и променените снимки е включена по подразбиране. С нея всяка нова или сменена снимка се проверява около 10 минути след промяната.
Същото сканиране показва и снимките, които са твърде малки за Google Shopping или за каталога в Meta, и продуктите, за които Google Merchant вече е докладвал проблем. Така една проверка помага и на скоростта, и на рекламите.
Как да следите скоростта с AI асистент вместо ръчно
AI асистент като Claude Code, ChatGPT/Codex или Gemini CLI може да пуска PageSpeed Insights вместо вас и да връзва резултата с продажбите. Google дава отворен достъп до PageSpeed Insights през API (PageSpeed Insights API), а асистентът, свързан с магазина в CloudCart, чете продуктите и поръчките през ключ за достъп (PAT токен).
Примерни изречения, които търговците пишат на асистента:
- „Вземи 10-те най-продавани продукта за последните 30 дни, пусни адресите им в PageSpeed Insights на мобилен и ми дай таблица с оценката, LCP, CLS и теглото.“
- „Сравни мобилния резултат на началната страница днес с този от миналия понеделник и ми кажи какво се е променило.“
- „Кои от 50-те продукта с най-много приходи имат по-малко от 3 снимки?“
Разликата е в това, че асистентът вижда едновременно скоростта и продажбите. PageSpeed Insights не знае кой продукт носи приходите, а админът на магазина не знае колко бавно зарежда страницата му.
| Задача | Ръчно | С AI асистент, свързан с магазина |
|---|---|---|
| Месечна проверка на 10 продукта по 3 пускания | 30 теста в PSI, преписани в таблица | Едно изречение, таблицата идва готова |
| Кои бавни страници да оправите първо | Отделно сравнение с отчета за продажбите | Подредени по приходите за периода |
| Дали промяната е помогнала | Търсите старата таблица и пускате всичко отново | Сравнение с предишния замер по дата |
| Нов продукт с тежка или малка снимка | Забелязвате го, когато Google Shopping го отхвърли | Седмичен списък с продуктите за поправка |
Започнете с ключ „Само четене“, а за промени искайте от асистента първо да покаже какво ще смени и потвърждавайте, защото промените в магазина нямат бутон „отмени“. Как се прави седмичен отчет с метриките е в статията метриките на онлайн магазина през AI агент, а колко часа спестява агентът при имейли, реклами и Search Console е в статията AI агент за онлайн магазин: колко часа и пари спестява.
Грешки, които гонят 100 точки и губят поръчки
Най-скъпата грешка е да махнете нещо, което продава, само за да вдигнете оценката. PageSpeed Insights мери само скоростта, а продажбите не влизат в оценката.
- Махнат пиксел за реклама. Meta Pixel и тагът на Google Ads струват няколко точки, но без тях рекламите губят данните за поръчките. Подредете ги през Приложения, вместо да ги махате.
- Снимки, компресирани до каша. Снимка от 20 KB зарежда бързо, но размазаната снимка продава по-малко и Google Shopping може да я отхвърли. Здраве на снимките отчита размазаните снимки като проблем с висока тежест.
- Тест само на десктоп. Резултатът за компютър почти винаги е по-висок. Клиентите ви са на телефон.
- Оценка от едно пускане. Разлика от 3–5 точки между две пускания е обикновен шум.
- Оптимизация само на началната страница. Хората от Google и от рекламите влизат направо в категория и продукт.
- Нов скрипт без замер. Всяко ново приложение във витрината пускайте в PSI преди и след включването.
Комисионната от 0% важи за всеки план и всяка продажба: условията са на страницата онлайн магазин без комисионна. Как се подреждат витрината, темата и модулите е на страницата Дизайн. Въпроси за скоростта на конкретен магазин пишете на support@cloudcart.com.
Често задавани въпроси
Отворете pagespeed.web.dev, поставете адреса на страницата и изберете раздела Mobile. Проверете поне началната страница, една категория и най-продавания продукт и пуснете всеки тест 3 пъти. За целия магазин гледайте отчета Core Web Vitals в Google Search Console.
От 90 до 100 точки е добър резултат, 50–89 е среден, а под 50 е слаб. За Google по-важно е дали страницата минава Core Web Vitals при реалните посетители: LCP до 2,5 секунди, INP до 200 милисекунди и CLS до 0,1. Онлайн магазин с 75 точки и преминати Core Web Vitals е в добро състояние.
Да. Според проучване на Deloitte за Google (2020) мобилен сайт, по-бърз с 0,1 секунди, е вдигнал конверсията в търговията на дребно с 8,4%. Бавната страница губи клиентите още преди да видят продукта, особено от реклами на телефон.
Започнете от първия екран: махнете видеото и слайдера, оставете един лек банер. После намалете размера на снимките, сменете GIF с JPEG и махнете забравените скриптове и приложения. В CloudCart снимките проверявате с Приложения → Здраве на снимките, а модулите изключвате в Дизайн → Модули.
Основното съдържание трябва да се вижда до 2,5 секунди на телефон (LCP), а страницата да реагира на докосване до 200 милисекунди (INP). Това са праговете на Google за добро изживяване. Мерете на мобилен, защото там е по-голямата част от посещенията.
Lighthouse е лабораторният тест, а PageSpeed Insights го пуска от сървър на Google и добавя данните от реални посетители (CrUX). Lighthouse в Chrome мери от вашия компютър и връзка, затова оценката често е различна. Резултатът се мени с няколко точки и между две пускания на един инструмент, затова записвайте средното от 3 теста.
Полевите данни идват от Chrome User Experience Report и се показват само когато страницата има достатъчно посещения от Chrome за последните 28 дни. При нов магазин или страница с малко трафик виждате само лабораторния тест. Понякога PSI показва данните за целия домейн (Origin) вместо за отделната страница.
Да, Google използва Core Web Vitals в системите си за класиране, но съдържанието и релевантността тежат повече. Бързината решава между две еднакво добри страници. По-голямата полза от бързия магазин е повече поръчки от същия трафик.
Източници
- pagespeed.web.devpagespeed.web.dev
- Google for Developersdevelopers.google.com
- Chrome for Developersdeveloper.chrome.com
- GTmetrixgtmetrix.com
- WebPageTestwww.webpagetest.org
- StatCountergs.statcounter.com
- Search Console Helpsupport.google.com
- Chrome for Developersdeveloper.chrome.com
- web.devweb.dev
- web.devweb.dev
- Think with Googlewww.thinkwithgoogle.com
- Google Search Centraldevelopers.google.com
- Page experiencedevelopers.google.com
- PageSpeed Insights APIdevelopers.google.com



