Core Web Vitals и PrestaShop: Оптимизация на скоростта за повече продажби

Представете си, че харчите стотици левове за реклама, привличате посетители в магазина си, но 40% от тях напускат преди страницата изобщо да се зареди. Точно това се случва, когато Core Web Vitals показателите са в лошата зона. Google не само наказва бавните сайтове в класирането — бавният код директно ерозира конверсиите и приходите.

Какво са Core Web Vitals и защо имат значение?

Core Web Vitals (CWV) са набор от измерими метрики за потребителско изживяване, дефинирани от Google. От май 2021 г. те са официален фактор за класиране в търсачката. За e-commerce магазин това означава едно: лошата производителност се отразява директно на видимостта ви в Google и на приходите ви.

Трите основни метрики са:

LCP — Largest Contentful Paint

Измерва колко бързо се зарежда най-голямото видимо съдържание на страницата — обикновено главната продуктова снимка или банер.

Оценка	Стойност	Значение
Добро	≤ 2.5 сек	Потребителят е доволен
Нуждае се от подобрение	2.5 – 4.0 сек	Риск от изоставяне
Лошо	> 4.0 сек	Висок bounce rate, загуба на продажби

INP — Interaction to Next Paint

INP е официалната метрика за отзивчивост от март 2024 г. Измерва колко бързо реагира страницата при клик, въвеждане на текст или друго взаимодействие. В PrestaShop магазин това включва добавяне в количката, смяна на вариант и търсене на продукт.

Оценка	Стойност
Добро	≤ 200 ms
Нуждае се от подобрение	200 – 500 ms
Лошо	> 500 ms

CLS — Cumulative Layout Shift

Измерва колко „скача" съдържанието на страницата по време на зареждане. Ако клиентът се е прицелил да кликне „Купи" и бутонът изведнъж се е преместил — той е кликнал нещо друго. Резултат: раздразнен клиент и изпусната продажба.

Оценка	Стойност
Добро	≤ 0.1
Нуждае се от подобрение	0.1 – 0.25
Лошо	> 0.25

Цифрите, които трябва да знаете

Не говорим за абстрактни технически показатели. Изследванията на Google и независими анализатори показват конкретна връзка между скоростта на зареждане и бизнес резултатите:

53% от мобилните потребители изоставят сайт, който се зарежда повече от 3 секунди.
Намаляването на времето за зареждане с 0.1 секунди увеличава конверсиите с до 8% при мобилни потребители в retail сектора.
Сайтове, преминаващи праговете на Core Web Vitals, регистрират с 24% по-нисък bounce rate в сравнение с тези, които не ги преминават.
Google потвърди, че страниците с добри CWV получават предимство при равни SEO условия спрямо конкурентите.

Типичните проблеми с производителността в PrestaShop

PrestaShop е мощна платформа, но след добавяне на модули и теми от трети страни, производителността рядко се управлява системно. Ето най-честите проблеми, с които се сблъскваме при одити на реални магазини.

Некомпресирани и неоптимизирани изображения

Продуктовите снимки са основната причина за висок LCP. PrestaShop генерира множество формати на изображенията, но по подразбиране не използва модерни формати като WebP или AVIF. Нередовно се среща и сценарият, при който администраторите качват оригинали от 5–10 MB директно в Back Office без предварителна обработка.

Прекалено много HTTP заявки от модули

Всеки инсталиран модул, добавящ JavaScript и CSS файлове на front-end-а, увеличава броя на заявките. Проблемът се задълбочава при 20–30 активни модула, всеки от тях зарежда собствени assets без комбиниране и минификация. Особено деструктивен е случаят, при който даден модул зарежда собствена версия на jQuery, въпреки че PrestaShop вече е заредил библиотеката.

public function hookDisplayHeader($params)
{
    // Грешно — зарежда jQuery повторно
    $this->context->controller->addJS('modules/mymodule/views/js/jquery.min.js');

    // Правилно — използва вече заредения jQuery
    $this->context->controller->addJS('modules/mymodule/views/js/mymodule.js');
}

Render-blocking JavaScript и CSS

JavaScript файлове, заредени в <head> без атрибут defer или async, блокират рендерирането на страницата. Браузърът спира да изгражда DOM, докато не изтегли и изпълни скрипта. В PrestaShop 8 това може да се контролира чрез Advanced Parameters → Performance, но много теми и модули заобикалят тези настройки.

Липсваща или неправилна кеш конфигурация

PrestaShop разполага с вграден Smarty кеш и CCC (Combine, Compress, Cache) за CSS/JS. Честа грешка е тези функции да са изключени в производствена среда — обикновено след debugging сесия, от която администраторът е забравил да върне настройките.

Бавни MySQL заявки без индекси

Продуктовите листинги с много филтри, особено тези от модула Faceted Search, могат да генерират изключително сложни SQL заявки. Без правилни индекси в базата данни всяка страница с категория може да отнема секунди само за обработка на заявките.

Изображения без зададени размери

Когато <img> тагове нямат зададени атрибути width и height, браузърът не знае колко място да резервира преди зареждането. Резултатът е визуален shift на съдържанието при зареждане, което директно влошава CLS показателя.

<!-- Без размери — причинява layout shift -->
<img src="product.jpg" alt="Продукт">

<!-- С размери — браузърът резервира пространство предварително -->
<img src="product.jpg" alt="Продукт" width="800" height="600" loading="lazy">

Как да измерите Core Web Vitals на вашия магазин

Преди да оптимизирате, трябва да знаете точно с какво се сблъсквате. Съществуват четири инструмента, с които препоръчваме да започне всеки одит.

Google PageSpeed Insights

Най-прекият начин за бърза оценка. Посетете pagespeed.web.dev и въведете URL на началната страница, най-продавания продукт и най-важната категория. Обърнете внимание на Field Data (реални данни от потребители) — те са по-важни от лабораторните данни, тъй като именно те влияят на класирането.

Google Search Console — Core Web Vitals Report

В Search Console съществува отчет специално за CWV, групиран по URL и тип устройство. Той показва реалните данни от потребителите на вашия сайт, не симулации. Именно тези данни Google използва при вземането на решения за класиране.

Chrome DevTools — Performance Tab

За задълбочен анализ на конкретна страница. Запишете Performance профил при зареждане с throttling на 4G мобилна мрежа — така симулирате реалния сценарий за преобладаващата част от клиентите ви.

WebPageTest.org

По-детайлен инструмент, позволяващ тест от различни локации, включително European сървъри близо до България. Генерира Waterfall диаграма на всички ресурси — изключително полезна за идентифициране на бавни заявки и render-blocking ресурси.

Практически стъпки за оптимизация

Стъпка 1: Активирайте вградените CCC функции

В Back Office → Advanced Parameters → Performance активирайте:

Combine, Compress and Cache (CCC) за CSS и JavaScript
Smart Cache за CSS и JavaScript
Smarty cache с recompile настроено на Never за производствена среда

Стъпка 2: Активирайте WebP изображенията

PrestaShop 8 поддържа WebP нативно. В Back Office → Design → Image Settings активирайте генерирането на WebP изображения, след което регенерирайте всички миниатюри:

# Регенериране на всички изображения чрез CLI
php bin/console prestashop:images:generate-thumbnails --format=webp

Стъпка 3: Добавете lazy loading за изображения извън viewport-а

Изображенията под линията на видимост трябва да се зареждат отложено. Намерете шаблоните за продуктови листинги в темата и добавете атрибутите:

{* themes/вашата-тема/templates/catalog/_partials/miniatures/product.tpl *}

{* Преди *}
<img src="{$product.cover.bySize.home_default.url}" alt="{$product.name|escape:'html':'UTF-8'}">

{* След *}
<img
    src="{$product.cover.bySize.home_default.url}"
    alt="{$product.name|escape:'html':'UTF-8'}"
    width="{$product.cover.bySize.home_default.width}"
    height="{$product.cover.bySize.home_default.height}"
    loading="lazy"
    decoding="async"
>

Важно: не добавяйте loading="lazy" към основното изображение на продуктовата страница. То е LCP елементът и трябва да се зарежда с приоритет чрез fetchpriority="high".

Стъпка 4: Отложете некритичен JavaScript

При регистриране на JavaScript в PrestaShop модули използвайте параметъра $bottom, за да заредите скриптовете преди затварящия </body> таг:

public function hookActionFrontControllerSetMedia()
{
    // true = зарежда преди </body>, не блокира рендерирането
    $this->context->controller->addJS(
        $this->_path . 'views/js/mymodule.js',
        true
    );
}

Стъпка 5: Конфигурирайте HTTP кеширане на ниво сървър

Статичните ресурси трябва да се кешират агресивно в браузъра. Добавете следните правила в .htaccess (Apache) или конфигурацията на Nginx:

# Apache .htaccess
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp              "access plus 1 year"
    ExpiresByType image/jpeg              "access plus 1 year"
    ExpiresByType image/png               "access plus 1 year"
    ExpiresByType text/css                "access plus 1 month"
    ExpiresByType application/javascript  "access plus 1 month"
    ExpiresByType font/woff2              "access plus 1 year"
</IfModule>

# Nginx
location ~* \.(webp|jpg|jpeg|png|svg|ico)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
location ~* \.(css|js)$ {
    expires 1M;
    add_header Cache-Control "public";
}
location ~* \.(woff2|woff|ttf)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Стъпка 6: Добавете Preload за LCP изображението

Ако е ясно кое е LCP изображението — обикновено главният банер на началната страница — добавете <link rel="preload"> в <head>:

{* themes/вашата-тема/templates/_partials/head.tpl *}
<link
    rel="preload"
    as="image"
    href="{$urls.img_url}banners/main-banner.webp"
    type="image/webp"
    fetchpriority="high"
>

Чеклист за одит на производителността

CCC (Combine, Compress, Cache) за CSS/JS е активирано
Smarty кеш е активиран и настроен на „Never recompile"
Всички изображения се сервират в WebP формат
Продуктовите изображения имат зададени атрибути width и height
Изображенията под fold-а имат loading="lazy"
LCP изображението има fetchpriority="high" и съответния preload link
JavaScript се зарежда с defer или в края на <body>
Неизползваните модули са деактивирани
Browser caching е конфигуриран на ниво сървър
Хостингът поддържа HTTP/2 или HTTP/3
PHP OPcache е активиран на сървъра
Redis или друг механизъм за обектно кеширане е конфигуриран
Google Search Console CWV репортът се преглежда редовно

Заключение

Core Web Vitals не са просто технически показатели за разработчиците. Те са директна връзка между кода на вашия сайт и приходите от него. Всяка секунда забавяне означава изгубени клиенти. Добрата новина е, че повечето проблеми в PrestaShop магазините са известни и решими — понякога правилното конфигуриране на вградените функции и няколко промени в темата правят разликата между оценка 40 и оценка 90 в PageSpeed Insights.

Ако искате да знаете точно къде стои вашият магазин и какво трябва да се направи, свържете се с нас. Правим технически одит на производителността и предоставяме конкретен план за действие.

Източници

Google Web Dev — Web Vitals: Essential metrics for a healthy site, 2024
Google / SOASTA — Find out how you stack up to new industry benchmarks for mobile page speed, Think with Google, 2018
Deloitte Digital / Mobify — Milliseconds Make Millions, 2020
Google Search Central — Understanding Core Web Vitals and Google Search results, 2024
Google Web Dev — Interaction to Next Paint (INP), 2024
PrestaShop Developer Documentation — Smarty templating engine, версия 8.x
HTTP Archive — Web Almanac 2023: Performance, Chapter 4

Core Web Vitals и PrestaShop: Защо бавният код убива Вашите продажби?