Оптимізація PrestaShop: прискорення магазину під ключ

Оптимізація продуктивності PrestaShop

У типовому магазині на PrestaShop 8.x з каталогом 2000+ товарів TTFB коливається від 1.5 до 4 секунд. Це тягне Core Web Vitals у червону зону: LCP вилітає за 4 с, CLS набігає через нестиснені зображення. Власники скаржаться на повільну адмін-панель і зависання при оновленні каталогу. Стандартна конфігурація — Smarty-компіляція без кешу, ORM з N+1 запитами, файловий кеш. Наші фахівці перебудували десятки таких магазинів: правильний стек — Redis, OPcache, оптимізовані індекси MySQL і грамотний nginx — дає TTFB 200–500 мс. За останні роки виконано понад 30 проєктів із прискорення PrestaShop, гарантуємо результат. Проблема ускладнюється зростаючим навантаженням на сервери: кожна додаткова секунда завантаження знижує конверсію на 2% (дослідження Google).

Чому PrestaShop гальмує на стандартній конфігурації?

Стандартна установка PrestaShop орієнтована на універсальність, а не на швидкість. Вузькі місця:

• Smarty-шаблони компілюються без кешу — кожен запит перезбирає шаблони.
• CCC (Combine, Compress, Cache) не включений за замовчуванням — CSS та JS завантажуються окремо.
• Кеш на файлах — повільний при великій кількості товарів.
• Запити до БД — відсутність індексів на ключових таблицях (ps_product_lang, ps_category_product, ps_search_word).

Діагностували магазин з 5000 товарів: сторінка категорії завантажувалася 3.2 с. Після налаштування Redis, включення CCC та додавання індексів час знизився до 0.4 с.

Як ми прискорюємо PrestaShop?

1. Налаштування вбудованого кешу — включити Smarty-кеш, CCC та мініфікацію.
2. Перемикання на Redis — замінити файловий кеш на Redis.
3. Оптимізація БД — додати індекси, налаштувати slow query log.
4. Налаштування OPcache — виділити 256MB та 20000 файлів.
5. Включення WebP — зменшити розмір зображень на 25–40%.
6. Аудит модулів — відключити зайві, особливо SEO та live chat.

Вбудований кеш PrestaShop

Admin > Advanced Parameters > Performance — головна панель оптимізації.

Smarty:

• Template compilation: Never recompile template files
• Cache: Yes
• Multi-front optimizations: Yes
• Clear cache: Never clear cache files

CCC:

• Smart cache for stylesheets: Yes
• Smart cache for JavaScript: Yes
• Apache optimization: Yes (генерує правила .htaccess)
• Minify HTML: Yes

Media servers — вказати CDN-домен для статики, якщо використовується.

Memcache/Redis як бекенд кешу

Перемикання з файлового кешу на Redis дає приріст 30–50%. Налаштування: Admin > Advanced Parameters > Performance > Caching — вибрати систему, додати сервер 127.0.0.1:6379. Для Redis додатково в config/config.inc.php:

define('_PS_CACHE_ENABLED_', '1');
define('_PS_CACHING_SYSTEM_', 'CacheRedis');

CacheRedis в PrestaShop 8 працює через Predis. Якщо використовується розширення phpredis — швидше на 15–20%.

Порівняння способів кешування:

PHP OPcache

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.interned_strings_buffer=32
opcache.fast_shutdown=1

PrestaShop має велику кодову базу — max_accelerated_files=20000 обов'язково, стандартних 10000 не вистачає.

MySQL: індекси та slow log

ALTER TABLE ps_product_lang
  ADD INDEX idx_id_lang (id_lang, id_product);

ALTER TABLE ps_category_product
  ADD INDEX idx_id_category_pos (id_category, position);

ALTER TABLE ps_search_word
  ADD INDEX idx_word (word(50));

Slow query log:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/prestashop-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

Типовий винуватець — запит getProducts() з сортуванням за sales без індексу на ps_product_sale. Додавання індексу скорочує час запиту з 2 с до 10 мс.

Модулі та їх вплив на швидкість

Кожен активний модуль додає хуки. Діагностика: тимчасово включити _PS_DEBUG_PROFILING_ в config/defines.inc.php — з'явиться Debugger bar з часом виконання кожного хука.

Проблемні категорії модулів:

• SEO-модулі — часто роблять 3–10 додаткових запитів на сторінку.
• Модулі живого чату — завантажують зовнішні скрипти синхронно.
• Модулі відгуків — COUNT-запити без кешу для кожного товару в лістингу.

Після відключення непотрібних модулів навантаження на сервер знижується вдвічі.

Nginx конфігурація

# Статика
location ~* \.(jpg|jpeg|png|webp|gif|ico|svg|woff2|css|js)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
    try_files $uri =404;
}

# Gzip
gzip on;
gzip_types text/plain text/css application/json application/javascript image/svg+xml;
gzip_comp_level 5;
gzip_min_length 512;
gzip_vary on;

# Заборона прямого звернення до класів PrestaShop
location ~* \.(log|tpl|twig|sass|yml|lock)$ {
    deny all;
}

WebP та зображення

PrestaShop 1.7.7+ підтримує WebP: Admin > Design > Image settings — включити формати WebP. Розмір зображень знижується на 25–40%. На сторінці лістингу з 24 товарів це економить 500–800 KB. Після включення регенеруйте мініатюри.

Що входить у роботу з оптимізації?

Комплексна оптимізація PrestaShop під ключ включає етапи:

Результат: TTFB знижується до 200–500 мс, LCP входить у зелену зону Core Web Vitals. Ви отримуєте звіт з рекомендаціями та гарантію на виконані роботи.

Досвід та гарантії

Наша команда має багаторічний досвід у веб-розробці, реалізовано понад 50 проєктів оптимізації e-commerce. Використовуємо лише перевірені методики та надаємо письмову гарантію на результат. Зв'яжіться з нами — оцінимо ваш магазин безкоштовно. Замовте аудит прямо зараз та отримайте консультацію.

Терміни та вартість

Терміни робіт: від 2 до 5 днів залежно від складності. Вартість розраховується індивідуально після аудиту. Зв'яжіться з нами — ми підберемо оптимальне рішення під ваш бюджет.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

• Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
• Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
• Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
• Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

• Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
• Важкі event listeners без debounce/throttle
• Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
• Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

• E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
• Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
• Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
• FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Що входить в роботу

• Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
• Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
• Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
• Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.