Zapytaj o produkt

OPcache to rozszerzenie PHP, które przechowuje skompilowany kod PHP w pamięci, dzięki czemu PHP nie musi go rekompilować przy każdym żądaniu. Zdecydowanie warto go włączyć — może poprawić wydajność PrestaShop o 30–50% bez żadnych negatywnych skutków na produkcji. Większość hostingodawców ma go domyślnie włączonego. Ważne ustawienie to opcache.validate_timestamps: ustaw na 1 w środowisku deweloperskim, ale wiele serwerów produkcyjnych ustawia go na 0 dla maksymalnej wydajności (co oznacza, że musisz ręcznie zresetować OPcache po wdrożeniu zmian w kodzie).

See our full guide on PHP optimization

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

Jak dzialaja szablony e-mail PrestaShop

PrestaShop wysyla e-maile transakcyjne w kazdym kluczowym momencie sciezki klienta: utworzenie konta, potwierdzenie zamowienia, powiadomienie o wysylce, reset hasla i inne. Te e-maile sa generowane z plikow szablonow przechowywanych na serwerze i sa w pelni konfigurowalne. Zrozumienie dzialania systemu szablonow to pierwszy krok do tworzenia profesjonalnych, markowych e-maili z potwierdzeniem zamowienia, ktore wzmacniaja tozsamosc Twojego sklepu.

Kazdy e-mail PrestaShop sklada sie z dwoch plikow szablonow: wersji HTML dla klientow pocztowych obslugujecych formatowanie oraz wersji tekstowej (TXT) dla klientow, ktore tego nie obsluguja. Oba pliki musza istniec, aby e-mail zostal wyslany poprawnie. Wersje HTML zobaczy zdecydowana wiekszosc klientow. Wersja TXT sluzy jako rozwiazanie awaryjne i jest rowniez uzywana przez narzedzia dostepnosci oraz niektore firmowe filtry pocztowe.

Szablony e-mail znajduja sie w strukturze katalogow mails/. Dokladna lokalizacja zalezy od tego, czy uzywasz e-maili rdzenia, e-maili nadpisanych przez motyw, czy e-maili specyficznych dla modulow. Zrozumienie tej hierarchii jest kluczowe, poniewaz PrestaShop sprawdza wiele lokalizacji dla kazdego szablonu i uzywa pierwszego znalezionego.

Struktura katalogow szablonow e-mail

PrestaShop organizuje szablony e-mail w specyficznej hierarchii katalogow. Gdy musi wyslac e-mail, przeszukuje te lokalizacje w kolejnosci priorytetu:

Nadpisania na poziomie motywu (najwyzszy priorytet)

Szablony w /themes/twoj-motyw/mails/pl/ (gdzie pl to kod ISO jezyka) maja priorytet nad wszystkimi innymi lokalizacjami. Jesli chcesz dostosowac szablon e-mail bez modyfikowania plikow rdzenia, tutaj powinny trafic Twoje niestandardowe szablony. Takie podejscie przetrwa aktualizacje PrestaShop, poniewaz pliki motywu nie sa nadpisywane podczas aktualizacji rdzenia.

Szablony rdzenia (domyslne)

Domyslne szablony znajduja sie w /mails/pl/ w katalogu glownym PrestaShop. Sa to szablony dostarczane z PrestaShop i uzywane, gdy nie istnieje nadpisanie motywu. Bezposrednia edycja tych plikow dziala, ale nie jest zalecana, poniewaz zmiany zostana utracone po aktualizacji PrestaShop.

Szablony specyficzne dla modulow

Moduly wysylajace wlasne e-maile przechowuja szablony w /modules/nazwa-modulu/mails/pl/. Na przyklad e-maile z powiadomieniami o zamowieniach wysylane przez rdzennie moduly platnosci sa przechowywane w ich odpowiednich katalogach modulow. Mozesz je nadpisac, umieszczajac zmodyfikowane kopie w katalogu mails/ motywu z ta sama nazwa pliku.

Podkatalogi jezykowe

Kazdy katalog mails/ zawiera podkatalogi dla kazdego zainstalowanego jezyka, uzywajac kodu ISO jezyka: en dla angielskiego, fr dla francuskiego, de dla niemieckiego i tak dalej. Gdy PrestaShop wysyla e-mail, uzywa szablonu z katalogu odpowiadajacego preferencji jezykowej klienta. Jesli szablon nie istnieje w jezyku klienta, PrestaShop wraca do jezyka domyslnego.

Anatomia szablonu potwierdzenia zamowienia

E-mail z potwierdzeniem zamowienia to najwazniejszy e-mail transakcyjny wysylany przez Twoj sklep. To plik o nazwie order_conf.html (i towarzyszacy mu order_conf.txt) w katalogu mails. Przyjrzyjmy sie jego strukturze.

Struktura szablonu HTML

Szablony e-mail PrestaShop sa samodzielnymi dokumentami HTML. Nie uzywaja zewnetrznych plikow CSS, poniewaz wiekszosc klientow pocztowych usuwa zewnetrzne arkusze stylow. Wszystkie style musza byc inline CSS. Typowy szablon potwierdzenia zamowienia zawiera nastepujace sekcje:

Dokument zaczyna sie od standardowego doctype HTML i sekcji head. Body zawiera uklad oparty na tabelach (poniewaz klienty pocztowe maja slaba obsluge nowoczesnych metod ukladu CSS jak flexbox i grid). W tym ukladzie znajdziesz sekcje naglowka z logo sklepu, glowny obszar tresci ze szczegolami zamowienia, tabele produktow z kazdym zamowionym produktem, podsumowanie cen z sumami czesciowymi i calkowitymi, informacje o wysylce, szczegoly metody platnosci oraz stopke z danymi kontaktowymi sklepu i informacjami prawnymi.

System zmiennych

PrestaShop uzywa prostego systemu zamiany zmiennych w szablonach e-mail. Zmienne sa ujete w nawiasy klamrowe: {nazwa_zmiennej}. Gdy e-mail jest generowany, PrestaShop zastepuje kazda zmienna jej rzeczywista wartoscia. Szablon potwierdzenia zamowienia uzywa tych kluczowych zmiennych:

{firstname} i {lastname} zawieraja imie i nazwisko klienta. {order_name} to numer referencyjny zamowienia (jak ABCDEF123). {shop_name} to nazwa sklepu skonfigurowana w panelu administracyjnym. {shop_url} to adres URL sklepu. {shop_logo} to sciezka do logo sklepu. {date} to data zamowienia. {payment} to uzyta metoda platnosci. {total_paid} to calkowita zaplacona kwota. {delivery_company} i {delivery_address} zawieraja informacje o przewozniku i adresie dostawy.

Dla listy produktow PrestaShop uzywa specjalnej skladni blokowej. Sekcja elementow produktowych jest opakowana w petle, ktora powtarza sie dla kazdego produktu w zamowieniu: {items} zawiera wstepnie sformatowany HTML dla calej tabeli listy produktow, wlaczajac nazwy produktow, ilosci, ceny i wszelkie szczegoly personalizacji.

Referencja dostepnych zmiennych

Aby zobaczyc wszystkie dostepne zmienne dla konkretnego szablonu e-mail, sprawdz kod PHP wysylajacy e-mail. Dla potwierdzenia zamowienia sprawdz klase PaymentModule (w /classes/PaymentModule.php). Metoda validateOrder() buduje tablice zmiennych szablonu. Kazdy klucz w tablicy odpowiada nazwie zmiennej, ktorej mozesz uzyc w szablonie.

Czesto dostepne zmienne w e-mailach potwierdzenia zamowienia obejmuja: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} i {total_products}.

Personalizacja szablonu potwierdzenia zamowienia

Krok 1: Utworz nadpisanie motywu

Nigdy nie edytuj bezposrednio plikow szablonow rdzenia. Zamiast tego skopiuj szablon do katalogu mails motywu:

Skopiuj /mails/pl/order_conf.html do /themes/twoj-motyw/mails/pl/order_conf.html. Zrob to samo dla order_conf.txt. Jesli katalog mails/pl/ nie istnieje w motywu, utworz go.

Jesli Twoj sklep obsluguje wiele jezykow, skopiuj szablony do kazdego katalogu jezykowego. Twoje angielskie potwierdzenie zamowienia trafia do /themes/twoj-motyw/mails/en/order_conf.html i tak dalej.

Krok 2: Modyfikuj uklad HTML

Otworz szablon HTML w edytorze tekstu (nie w edytorze wizualnym, ktory moze dodac niechciany kod). HTML e-mailowy rozni sie od HTML webowego w kilku waznych aspektach:

Uzywaj tabel do ukladu, nie divow. Klienty pocztowe, szczegolnie Outlook, maja bardzo ograniczona obsluge CSS. Uklad trzech kolumn musi uzywac <table> z trzema elementami <td>, nie kolumn CSS czy flexboxa.

Uzywaj stylow inline na kazdym elemencie. Zamiast <p class="heading"> z oddzielnym arkuszem stylow, uzyj <p style="font-size:18px; font-weight:bold; color:#333333;">. Kazdy stylizowany element potrzebuje wlasnego atrybutu stylu inline.

Ustaw jawne szerokosci na tabelach i komorkach. Klienty pocztowe nie zawsze respektuja szerokosci procentowe. Uzyj stalej szerokosci dla glownej tabeli tresci (600 pikseli to standard) z procentowymi kolumnami wewnetrznymi.

Uzywaj bezpiecznych czcionek webowych. Nie wszystkie klienty pocztowe obsluguja niestandardowe czcionki. Trzymaj sie Arial, Helvetica, Georgia, Times New Roman, Verdana lub Trebuchet MS. Mozesz sprobowac zaladowac niestandardowa czcionke jako fallback, ale zawsze okresl bezpieczna czcionke webowa jako koncowy fallback.

Krok 3: Dodaj swoj branding

Zastap domyslny naglowek PrestaShop brandingiem swojego sklepu. Obejmuje to zazwyczaj aktualizacje logo (zmienna {shop_logo} automatycznie uzywa logo sklepu, ale mozesz chciec specjalnej wersji e-mailowej), zmiane koloru tla naglowka na zgodny z marka, dodanie schematu kolorow marki do naglowkow i linkow oraz dolaczenie sloganu sklepu lub krotkiego komunikatu marketingowego.

Utrzymuj ogolna strukture prosta. Zbyt skomplikowane projekty e-maili rozpadaja sie w roznych klientach pocztowych. Czysty, jednokolumnowy uklad z kolorami marki i logo jest bardziej efektywny i niezawodny niz rozbudowany wielokolumnowy projekt.

Krok 4: Dostosuj tabele produktow

Domyslna tabela produktow w potwierdzeniu zamowienia PrestaShop jest funkcjonalna, ale podstawowa. Mozesz ja ulepszyc, dodajac obrazy produktow (uzyj bezwzglednych URL do obrazow hostowanych na serwerze, nie sciezek wzglednych), dodajac linki do stron produktow, aby klienci mogli latwo zamowic ponownie lub zostawic opinie, dodajac niestandardowe pola jak szacowane daty dostawy lub spersonalizowane wiadomosci, oraz dostosowujac styl tabeli do marki.

Dodajac obrazy produktow, utrzymuj je male (50 do 80 pikseli szerokosci) i zawsze dodawaj atrybut alt. Niektore klienty pocztowe domyslnie blokuja obrazy, a tekst alternatywny zapewnia, ze klienci moga nadal zidentyfikowac produkty.

Dodawanie niestandardowych pol do e-maili zamowien

Domyslne zmienne PrestaShop pokrywaja standardowe informacje o zamowieniu, ale mozesz chciec dolaczyc dodatkowe dane jak zdobyte punkty lojalnosciowe, szacowana date dostawy, spersonalizowane podziekowanie lub rekomendacje produktow powiazanych.

Dodawanie zmiennych przez modul

Najczystszym sposobem dodania niestandardowych zmiennych jest modul podlaczajacy sie do procesu wysylania e-maili. Utworz modul rejestrujacy hook actionEmailSendBefore (dostepny od PrestaShop 1.7.6) lub hook actionGetExtraMailTemplateVars. W handlerze hooka dodaj niestandardowe zmienne do tablicy zmiennych szablonu:

Funkcja hooka otrzymuje tablice zmiennych szablonu przez referencje. Mozesz dodac nowe zmienne do tej tablicy i staja sie one dostepne w szablonie przy uzyciu standardowej skladni {nazwa_zmiennej}. Na przyklad po dodaniu loyalty_points do tablicy w hooku, mozesz uzyc {loyalty_points} w szablonie HTML potwierdzenia zamowienia.

Uzywanie istniejacych danych z bazy

Mozesz pobierac dowolne dane z bazy PrestaShop do zmiennych e-mail. Czeste przyklady obejmuja calkowita liczbe zamowien klienta (aby wyswietlic "Dziekujemy za 5. zamowienie!"), saldo punktow lojalnosciowych klienta, niestandardowe pola produktow przechowywane w cechach lub atrybutach produktow oraz informacje o magazynie lub dostawcy zamowionych produktow.

Konfiguracja wielojezyczna e-maili

Jesli Twoj sklep obsluguje klientow w wielu jezykach, kazdy szablon e-mail potrzebuje wersji dla kazdego jezyka. PrestaShop automatycznie wybiera jezyk na podstawie preferencji klienta, ale musisz dostarczyc szablony.

Tworzenie szablonow specyficznych dla jezyka

Dla kazdego jezyka obslugiwanego przez sklep utworz katalog w folderze mails motywu: /themes/twoj-motyw/mails/en/, /themes/twoj-motyw/mails/fr/, /themes/twoj-motyw/mails/de/ i tak dalej. Skopiuj i przetlumacz kazdy plik szablonu do odpowiedniego katalogu.

Nie uzywaj automatycznego tlumaczenia e-maili transakcyjnych. Te e-maile reprezentuja komunikacje sklepu z klientami, a slabe tlumaczenia podkopuja zaufanie. Kazda wersje jezykowa powinna napisac lub sprawdzic native speaker.

Obsluga jezykow od prawej do lewej

Jesli obslugiwane sa jezyki takie jak arabski lub hebrajski, szablony e-mail potrzebuja wsparcia RTL (od prawej do lewej). Dodaj dir="rtl" do glownego elementu tabeli i dostosuj wyrownanie tekstu oraz padding w stylach inline. Utworz oddzielne szablony dla jezykow RTL zamiast probowac uzywac jednego szablonu dla obu kierunkow.

Formatowanie dat i walut

PrestaShop automatycznie formatuje daty i wartosci walut zgodnie z ustawieniami jezyka i waluty klienta. Zmienne {date}, {total_paid} i inne sformatowane wartosci juz odzwierciedlaja prawidlowa lokalizacje. Jednak jesli dodajesz niestandardowe zmienne z datami lub wartosciami walut, upewnij sie, ze sa prawidlowo sformatowane dla jezyka docelowego.

Konfiguracja SMTP dla niezawodnej dostarczalnosci

Najlepszy szablon e-mail na swiecie jest bezuzyteczny, jesli e-maile nie docieraja do skrzynki odbiorczej. Domyslna konfiguracja e-mail PrestaShop uzywa wbudowanej funkcji PHP mail(), ktora jest nieniezawodna dla e-maili transakcyjnych. Wiekszosc tych e-maili trafia do folderu spam lub jest calkowicie odrzucana przez nowoczesnych dostawcow poczty.

Dlaczego SMTP jest wazne

SMTP (Simple Mail Transfer Protocol) z odpowiednia autoryzacja jest kluczowe dla dostarczalnosci e-maili. Gdy wysylasz e-maile przez funkcje PHP mail(), e-mail pochodzi z adresu IP serwera bez zadnej autoryzacji. Dostawcy poczty jak Gmail, Outlook i Yahoo widza to jako sygnial ostrzegawczy i czesto klasyfikuja takie e-maile jako spam.

Z SMTP e-maile sa wysylane przez uwierzytelniony serwer pocztowy z odpowiednimi rekordami SPF, DKIM i DMARC. To dowodzi serwerom pocztowym, ze e-mail jest legalny i autoryzowany przez Twoja domene.

Konfiguracja SMTP w PrestaShop

Przejdz do Zaawansowane > E-mail w panelu administracyjnym PrestaShop. Zmien metode z "Uzyj funkcji mail() PHP" na "Ustaw wlasne parametry SMTP". Wprowadz dane serwera SMTP: adres serwera, port (typowo 587 dla TLS lub 465 dla SSL), typ szyfrowania, nazwe uzytkownika i haslo.

Popularni dostawcy SMTP dla PrestaShop obejmuja Gmail SMTP (smtp.gmail.com, port 587, TLS, wymaga hasla aplikacji przy wlaczonym 2FA), Amazon SES (przystepny cenowo dla duzych wolumenow), SendGrid (hojny darmowy plan), Mailgun (przyjazny dla programistow z dobrym logowaniem) oraz serwer SMTP Twojego dostawcy hostingu (sprawdz ustawienia u swojego hosta).

Testowanie konfiguracji SMTP

Po skonfigurowaniu SMTP uzyj przycisku "Wyslij testowy e-mail" na dole strony konfiguracji e-mail. Wprowadz wlasny adres e-mail i sprawdz, czy testowy e-mail dotarl do skrzynki (nie do spamu). Jesli testowy e-mail nie dotarl, sprawdz dane SMTP, upewnij sie, ze serwer moze polaczyc sie z serwerem SMTP na skonfigurowanym porcie (niektore firmy hostingowe blokuja porty wychodzace 25 i 587) oraz sprawdz, czy dostawca SMTP wymaga okreslonych ustawien bezpieczenstwa.

Rekordy SPF, DKIM i DMARC

Dla maksymalnej dostarczalnosci skonfiguruj te rekordy DNS dla swojej domeny. SPF (Sender Policy Framework) okresla, ktore serwery sa uprawnione do wysylania e-maili w imieniu domeny. DKIM (DomainKeys Identified Mail) dodaje podpis cyfrowy do e-maili potwierdzajacy, ze zostaly wyslane z Twojej domeny. DMARC (Domain-based Message Authentication, Reporting, and Conformance) informuje serwery odbiorcze, co robic z e-mailami niespelniajacymi sprawdzen SPF lub DKIM.

Dostawca SMTP dostarczy konkretne rekordy DNS do dodania. Na przyklad przy korzystaniu z SendGrid otrzymasz rekordy SPF i DKIM podczas procesu uwierzytelniania domeny. Dodaj je jako rekordy TXT w ustawieniach DNS domeny.

Testowanie szablonow e-mail

Wysylanie testowych e-maili

PrestaShop nie ma wbudowanej opcji podgladu konkretnych szablonow e-mail. Aby przetestowac szablon potwierdzenia zamowienia, musisz zlozyc prawdziwe zamowienie testowe. Utworz testowe konto klienta, dodaj produkty do koszyka i sfinalizuj zamowienie testowa metoda platnosci. Jesli masz skonfigurowany modul platnosci sandbox, uzyj go. W przeciwnym razie metody platnosci przelewem bankowym lub czekiem pozwalaja sfinalizowac zamowienie bez rzeczywistego przetwarzania platnosci.

Testowanie w roznych klientach pocztowych

Renderowanie e-maili dramatycznie rozni sie miedzy klientami pocztowymi. To co wyglada idealnie w Gmail, moze byc uszkodzone w Outlooku. Przetestuj szablony co najmniej w Gmail (web), Outlook (desktop i web), Apple Mail, Yahoo Mail i przynajmniej jednej mobilnej aplikacji pocztowej. Uslugi jak Litmus lub Email on Acid automatyzuja to testowanie, renderujac e-mail w dziesieciach klientow pocztowych jednoczesnie, ale sa to uslugi platne.

Czeste problemy z renderowaniem

Jesli e-mail wyglada zle w Outlooku, jest to prawie na pewno problem CSS. Outlook uzywa silnika renderowania Microsoft Word dla e-maili HTML, ktory ma niezwykle ograniczona obsluge CSS. Nie obsluguje obrazow tla na komorkach tabeli (uzyj kolorow tla), paddingu na elementach blokowych (uzyj paddingu komorek tabeli), max-width (uzyj stalych szerokosci), margin do centrowania (uzyj align="center" na tabelach) ani CSS float.

Dla responsywnosci mobilnej opakuj tabele tresci w kontener z max-width:600px i dodaj media query w bloku stylu head (obslugiwana przez niektore klienty pocztowe), ktora ustawia szerokosci tabel na 100% na malych ekranach. To nie jest idealny responsywny design, ale zapobiega przewijaniu poziomemu na wiekszosci urzadzen mobilnych.

Czeste problemy i rozwiazywanie

Brakujace obrazy w e-mailach

To najczestszy problem z szablonami e-mail. Obrazy w e-mailach musza uzywac bezwzglednych URL (zaczynajacych sie od https://), nie sciezek wzglednych. Jesli szablon odwoluje sie do /img/logo.png, zmien na https://www.twojadomena.pl/img/logo.png. Zmienna {shop_logo} automatycznie generuje bezwzgledny URL, ale wszystkie obrazy dodane recznie musza uzywac pelnych URL.

Sprawdz rowniez, czy obrazy sa dostepne spoza sieci. Jesli sklep jest za zapora lub uwierzytelnianiem HTTP, klienty pocztowe nie moga zaladowac obrazow. Przetestuj otwierajac URL obrazu w prywatnym oknie przegladarki.

Uszkodzony uklad po edycji

HTML e-mailowy jest kruchy. Pojedynczy niezamkniety tag lub brakujaca komorka tabeli moze zniszczyc caly uklad. Zawsze waliduj HTML po edycji. Policz otwierajace i zamykajace tagi table, tr i td. Kazdy <table> potrzebuje </table>, kazdy <tr> potrzebuje </tr>, a kazdy <td> potrzebuje </td>. Upewnij sie, ze kazdy wiersz w tabeli ma taka sama liczbe komorek (lub uzywa colspan).

Zmienne nie sa zastepowane

Jesli w wyslanych e-mailach widzisz literalny tekst {nazwa_zmiennej} zamiast rzeczywistych wartosci, sprawdz nazwe zmiennej pod katem literowek. Nazwy zmiennych sa wrazliwe na wielkosc liter. Sprawdz rowniez, czy zmienna istnieje dla konkretnego typu e-maila. Nie wszystkie zmienne sa dostepne we wszystkich szablonach. Zmienne specyficzne dla zamowien jak {order_name} sa dostepne tylko w e-mailach zwiazanych z zamowieniami.

E-maile nie sa wysylane

Jesli e-maile nie sa wysylane, sprawdz panel administracyjny PrestaShop w Zaawansowane > E-mail. Mozesz tam zobaczyc dziennik wyslanych e-maili. Jesli dziennik pokazuje bledy, sprawdz konfiguracje SMTP. Jesli zaden e-mail nie pojawia sie w dzienniku, e-mail moze nie byc w ogole wyzwalany. Sprawdz, czy przejscia statusow zamowien sa skonfigurowane do wysylania e-maili (Zamowienia > Statusy > edytuj status > zaznacz "Wyslij e-mail do klienta").

Sprawdz rowniez dziennik bledow PHP serwera pod katem bledow zwiazanych z e-mailami. Czeste problemy to wylaczona funkcja PHP mail() przez dostawce hostingu, bledy uwierzytelniania SMTP z powodu zmienionego hasla oraz problemy z polaczeniem sieciowym miedzy serwerem a serwerem SMTP.

E-maile trafiaja do spamu

Nawet przy poprawnej konfiguracji SMTP e-maile moga nadal trafiac do spamu. Najczestsze przyczyny to brakujace lub nieprawidlowe rekordy SPF/DKIM/DMARC, tresc e-maila wyzwalajaca filtry spam (nadmierne uzycie duzych liter, slowa wyzwalajace spam jak "za darmo" czy "dzialaj teraz", zbyt duzo obrazow z mala iloscia tekstu), wysylanie z adresu IP o zlej reputacji (czeste przy hostingu wspoldzielonym) oraz domena adresu nadawcy niezgodna z domena serwera SMTP.

Najpierw napraw rekordy DNS, potem przejrzyj tresc e-maili. Uzyj narzedzia takiego jak mail-tester.com do analizy e-maili pod katem wyzwalaczy spamu. Wyslij testowy e-mail na podany adres, a otrzymasz szczegolowy raport pokazujacy, co moze powodowac klasyfikacje jako spam.

Nadpisania e-maili specyficzne dla motywu

Niektore motywy PrestaShop zawieraja wlasne szablony e-mail pasujace do designu motywu. Jesli motyw ma szablony w /themes/twoj-motyw/mails/, automatycznie nadpisuja one szablony rdzenia.

Sprawdzanie szablonow e-mail motywu

Sprawdz w katalogu aktywnego motywu, czy istnieje folder mails. Jesli istnieje, motyw dostarcza niestandardowe szablony e-mail. Te szablony zazwyczaj pasuja do schematu kolorow i designu naglowka/stopki motywu, zapewniajac wizualna spojnosc e-maili z witryma sklepu.

Dostosowywanie szablonow e-mail motywu

Jesli motyw dostarcza szablony e-mail, edytuj te zamiast kopiowac z katalogu mails/ rdzenia. Szablony motywu moga uzywac innej struktury HTML lub zawierac dodatkowe CSS specyficzne dla systemu designu motywu. Rozpoczecie od wersji motywu zapewnia wizualna spojnosc.

Synchronizacja szablonow z aktualizacjami motywu

Aktualizujac motyw, sprawdz czy aktualizacja zawiera zmiany w szablonach e-mail. Jesli tak, Twoje dostosowania moga zostac nadpisane. Przed aktualizacja zrob kopie zapasowa dostosowanych szablonow. Po aktualizacji porownaj nowe szablony z kopiami i ponownie zastosuj dostosowania do zaktualizowanych wersji. Jest to zmdune, ale konieczne, aby zachowac zarowno dostosowania, jak i ewentualne ulepszenia lub poprawki dewelopera motywu.

Dobre praktyki dla e-maili potwierdzenia zamowienia

Dobrze zaprojektowany e-mail z potwierdzeniem zamowienia robi wiecej niz tylko potwierdza transakcje. Buduje zaufanie, zmniejsza liczbe zapytan do obslugi klienta i tworzy mozliwosci zaangazowania.

Umiesc wyraznie widoczny numer referencyjny zamowienia na gorze. Klienci potrzebuja tego numeru kontaktujac sie z obsluga lub sledzac zamowienie. Wymien kazdy produkt z nazwa, iloscia, cena i wszelkimi opcjami lub personalizacjami. Dolacz pelne zestawienie sumy czesciowej, kosztow wysylki, podatkow, rabatow i sumy calkowitej. Pokaz adres dostawy, aby klienci mogli go zweryfikowac i natychmiast skontaktowac sie w razie bledu. Podaj uzyta metode platnosci i odpowiednie szczegoly transakcji. Udostepnij link do strony sledzenia zamowienia lub historii zamowien w koncie klienta. Dodaj dane kontaktowe obslugi klienta, aby wiedzieli jak sie skontaktowac w razie problemow.

Utrzymuj design czysty i przyjazny dla urzadzen mobilnych. Ponad polowa wszystkich e-maili jest czytana na urzadzeniach mobilnych. Uzyj jednokolumnowego ukladu, duzego czytelnego tekstu (minimum 14px dla tresci) i przyciskow z odpowiednimi celami dotykowymi (minimum 44px wysokosci). E-mail z potwierdzeniem zamowienia odzwierciedla profesjonalizm sklepu. Zainwestuj czas, aby zrobic to dobrze.

Przekierowania .htaccess w PrestaShop: pisanie regul bez psucia sklepu

Plik .htaccess jest jednym z najpotezniejszych i najbardziej niebezpiecznych plikow w Twojej instalacji PrestaShop. Jeden zle umieszczony znak moze wylaczyc caly Twoj sklep. Ale opanowanie przekierowan .htaccess jest niezbedne dla SEO.

Jak PrestaShop uzywa .htaccess

PrestaShop automatycznie generuje i zarzadza plikiem .htaccess. Gdy wlaczysz przyjazne URLe w ustawieniach SEO i URLe, PrestaShop zapisuje reguly przepisywania miedzy dwoma komentarzami znacznikowymi.

Krytyczna zasada - Nigdy nie dodawaj niestandardowych przekierowan wewnatrz tego bloku. PrestaShop nadpisze je przy nastepnej regeneracji. Umieszczaj swoje reguly PRZED blokiem PrestaShop.

Typy przekierowan

301 - Przekierowanie stale

Uzywaj gdy strona zostala trwale przeniesiona. Wyszukiwarki przenoszą wartosc SEO na nowy URL.

302 - Przekierowanie tymczasowe

Uzywaj gdy strona jest tymczasowo niedostepna.

410 - Gone (Usuniety)

Uzywaj gdy strona zostala trwale usunieta bez zamiennika.

Podstawowa skladnia przekierowan

# Przekieruj pojedynczy URL
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# Przekieruj stary URL produktu
Redirect 301 /stary-produkt.html https://twojsklep.com/pl/nowy-produkt.html

Przekierowania oparte na wzorcach z RewriteRule

RewriteEngine On
RewriteRule ^stary-folder/(.*)$ https://twojsklep.com/nowy-folder/$1 [R=301,L]

Typowe scenariusze przekierowan PrestaShop

Scenariusz 1 - Migracja z innej platformy

# WooCommerce do PrestaShop
RewriteRule ^product/stary-slug/?$ https://twojsklep.com/pl/nowy-url.html [R=301,L]

Scenariusz 2 - Wymuszenie HTTPS i WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Reguly ktore moga zepsuc PrestaShop

Nieskonczone petle przekierowan

Najniebezpieczniejszy blad. Zawsze uzywaj warunkow do zapobiegania petlom.

# NIEBEZPIECZNE
RewriteRule ^(.*)$ https://twojsklep.com/$1 [R=301,L]

# BEZPIECZNE
RewriteCond %{HTTP_HOST} !^www\.twojsklep\.com$ [NC]
RewriteRule ^(.*)$ https://www.twojsklep.com/$1 [R=301,L]

Psucie dostepu do back office

# BEZPIECZNE - wyklucz admin i API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteCond %{REQUEST_URI} !^/modules [NC]
RewriteRule ^(.*)$ https://twojsklep.com/pl/$1 [R=301,L]

Bezpieczne testowanie przekierowan

# Zawsze najpierw zrob kopie
cp .htaccess .htaccess.backup

# Testuj z curl
curl -I -L https://twojsklep.com/stara-strona.html

Gdzie umieszczac niestandardowe reguly

# TWOJE PRZEKIEROWANIA TUTAJ (przed blokiem PrestaShop)
Redirect 301 /stara-strona.html https://twojsklep.com/nowa-strona.html

# ~~start~~ Blok PrestaShop
# ... automatycznie generowane reguly ...
# ~~end~~ Blok PrestaShop

Kiedy uzywac modulu

Rozwaz modul przekierowan gdy nietechniczny personel musi zarzadzac przekierowaniami, masz setki przekierowan lub potrzebujesz automatycznego wykrywania 404.

Lazy Loading w 2026: co przeglądarki obsługują natywnie, a co wymaga modułu

Lazy loading to technika optymalizacji wydajności, która odwleka ładowanie zasobów poza ekranem do momentu, gdy użytkownik przewinie w ich pobliże. W 2026 roku natywne wsparcie przeglądarek dla lazy loadingu znacząco dojrzało, ale wciąż istnieją scenariusze, w których właściciele sklepów PrestaShop potrzebują dodatkowych modułów lub niestandardowych implementacji. Ten przewodnik wyjaśnia dokładnie, co przeglądarki obsługują samodzielnie, jakie luki pozostają i jak wdrożyć najlepszą strategię lazy loading dla Twojego sklepu PrestaShop.

Co natywny lazy loading obejmuje w 2026

Atrybut HTML loading="lazy" jest teraz obsługiwany przez ponad 95% przeglądarek na świecie. Obejmuje to Chrome (od v77), Firefox (od v75), Safari (od v15.4), Edge (od v79) i wszystkie przeglądarki oparte na Chromium.

Jak działa natywny lazy loading

Dodanie loading="lazy" do tagu <img> lub <iframe> mówi przeglądarce, aby odroczyła ładowanie tego zasobu do momentu, gdy znajdzie się w określonej odległości od viewportu.

<img src="obraz-produktu.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nazwa produktu">

Co przeglądarki obsługują natywnie

Czego przeglądarki NIE obsługują

Implementacja natywnego lazy loadingu w PrestaShop

Dla motywów PrestaShop 8.x i 9.x

Nowoczesne motywy PrestaShop (jak Hummingbird dla PS 9) często zawierają natywny lazy loading domyślnie. Aby zweryfikować lub dodać go do swojego motywu, edytuj pliki szablonów.

{* Przed - bez lazy loadingu *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Po - z natywnym lazy loadingiem *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Krytyczna zasada: nigdy nie stosuj lazy loading do obrazów above-the-fold

Najczęstszym błędem lazy loadingu jest stosowanie go do obrazów widocznych bez przewijania. To w rzeczywistości pogarsza wydajność, ponieważ przeglądarka opóźnia ładowanie treści, które użytkownik widzi natychmiast.

Obrazy, które NIE powinny być lazy ładowane:

• Logo Twojego sklepu
• Obrazy hero/baner na górze strony
• Pierwsze 1-2 obrazy produktów na stronach kategorii

<img src="hero-baner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Baner letniej wyprzedaży">

Kiedy potrzebujesz modułu: obrazy tła CSS

Motywy PrestaShop często używają obrazów tła CSS dla sliderów, banerów i nagłówków kategorii. Atrybut loading="lazy" nie działa dla teł CSS.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Kiedy potrzebujesz modułu: efekty placeholder

• Efekt blur-up (LQIP) - Załaduj najpierw małą, rozmytą wersję
• Ekrany szkieletowe - Szare bloki placeholder odpowiadające wymiarom
• Placeholdery dominującego koloru - Użyj dominującego koloru obrazu jako tła

Wpływ na wydajność PrestaShop i Core Web Vitals

• LCP - Lazy loading obrazów above-the-fold POGARSZA LCP
• CLS - Obrazy bez atrybutów width/height powodują przesunięcia układu
• INP - Mniej jednocześnie ładowanych zasobów poprawia interaktywność

<!-- ŹLE - powoduje przesunięcie układu -->
<img src="produkt.jpg" loading="lazy" alt="Produkt">

<!-- DOBRZE - rezerwuje miejsce -->
<img src="produkt.jpg" loading="lazy" 
     width="400" height="400" alt="Produkt">

Rekomendacje specyficzne dla PrestaShop

Strony z listą produktów

Lazy ładuj wszystkie obrazy produktów oprócz pierwszego rzędu. Zastosuj fetchpriority="high" do pierwszego rzędu.

Strony szczegółów produktu

Główny obraz produktu powinien być ładowany eager z fetchpriority="high". Miniatury galerii mogą być lazy ładowane.

Strona główna

Obrazy slidera above the fold powinny być ładowane eager. Bloki modułów below the fold powinny używać lazy loadingu.

Podsumowanie: Moduł vs. Natywny

Wydajnosc panelu administracyjnego PrestaShop: dlaczego Back Office jest wolny

Wolny panel administracyjny PrestaShop to jeden z najbardziej frustrujacych problemow. Ten przewodnik identyfikuje najczestsze przyczyny i podaje konkretne rozwiazania.

Najczestsze przyczyny

1. Polaczenie z API PrestaShop Addons

Przyczyna numer jeden. Back office wykonuje zapytania HTTP do addons.prestashop.com. Gdy to API jest wolne, caly back office czeka.

Rozwiazanie - Wyloguj sie z konta Addons lub wylacz wywolania API.

2. Wlaczony tryb debug

Wylacza wszystkie cache i rekompiluje szablony przy kazdym zadaniu.

define('_PS_MODE_DEV_', false);

3. Za duzo zainstalowanych modulow

Kazdy modul dodaje narzut. Odinstaluj nieuzywane moduly, szczegolnie statystyki i gamifikacje.

4. Duza baza danych bez optymalizacji

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Ograniczenia hostingu wspoldzielonego

Rekomendacja: VPS z 2+ CPU, 4 GB RAM, SSD i PHP 8.1+.

6. OPcache nie wlaczony

opcache.enable = 1
opcache.memory_consumption = 256

7. Wolne widgety dashboardu

Uproscisc dashboard. Usunac niepotrzebne widgety.

8. Duzy katalog produktow

Zmniejszyc produkty na strone do 20-50. Uzywac wyszukiwania zamiast przegladania.

Checklista optymalizacji

1. Wylacz tryb debug
2. Kompilacja szablonow: "Nigdy nie rekompiluj"
3. Wlacz cache (Redis preferowany)
4. Wlacz OPcache
5. Odlacz od API Addons
6. Odinstaluj nieuzywane moduly
7. Wyczysc baze danych
8. Uproscisc dashboard
9. Zmien hosting na VPS/dedykowany
10. Uzyj PHP 8.1+

Limitowanie zapytan i ochrona przed botami w PrestaShop bez WAF

Boty stanowia ponad 40% calego ruchu w sieci w 2026. Ten przewodnik pokazuje jak wdrozyc skuteczna ochrone za pomoca konfiguracji serwera, regul .htaccess i lekkich modulow.

Metoda 1 - Rate Limiting Apache .htaccess

RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Metoda 2 - Rate Limiting Nginx

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

Metoda 3 - fail2ban przeciw brute force

fail2ban monitoruje logi serwera i automatycznie blokuje IP z zlosliwym zachowaniem.

Metoda 4 - Rate Limiting na poziomie PHP

Dla hostingu wspoldzielonego: plikowy rate limiter w PHP.

Metoda 5 - robots.txt i kontrola crawlowania

User-agent: SemrushBot
Crawl-delay: 10

Metoda 6 - CAPTCHA na krytycznych formularzach

Dodaj reCAPTCHA na logowaniu, rejestracji, formularzu kontaktowym i newsletterze.

Metoda 7 - Cloudflare Free

Browser Integrity Check, Bot Fight Mode i Rate Limiting sa dostepne za darmo.

Podsumowanie warstw ochrony

Gdy kombinacje PrestaShop zabijaja wydajnosc: limity i obejscia

System kombinacji PrestaShop pozwala tworzyc warianty produktow. Dziala doskonale dla produktow z kilkoma wariantami. Ale gdy produkty maja setki lub tysiace kombinacji, wydajnosc drastycznie spada.

Dlaczego kombinacje powoduja problemy z wydajnoscia

Architektura bazy danych

PrestaShop przechowuje dane kombinacji w wielu tabelach: ps_product_attribute, ps_product_attribute_combination, ps_stock_available, ps_specific_price. Produkt z 5 rozmiarami i 10 kolorami tworzy 50 kombinacji z ponad 350 wierszami w bazie.

Problem wzrostu wykladniczego

Praktyczne limity

Rozwiazanie 1 - Restrukturyzacja katalogu

Zamiast jednego produktu z 50 kombinacjami, stworz oddzielne produkty na kolor z 5 kombinacjami kazdy. Szybsze i lepsze dla SEO.

Rozwiazanie 2 - Optymalizacja bazy danych i serwera

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

Rozwiazanie 3 - Lazy loading kombinacji

Zamiast ladowac wszystkie kombinacje przy wczytywaniu strony, pobieraj dane przez AJAX gdy klient wybiera atrybut.

Rozwiazanie 4 - Strategie cachowania

Cache calej strony (Varnish, LiteSpeed) dla stron produktow. Redis lub Memcached zamiast cachowania plikowego.

Kiedy unikac kombinacji calkowicie

• Produkty konfigurowalne z 4+ atrybutami - Modul konfiguratora produktow
• Produkty wymiarowe - Modul niestandardowych wymiarow
• Produkty print-on-demand - Modul projektanta produktow

Rekomendacje wedlug liczby kombinacji

Macierz kompatybilności wersji PHP dla PrestaShop

Wybór odpowiedniej wersji PHP dla Twojego sklepu PrestaShop to jedna z najważniejszych decyzji infrastrukturalnych, jakie podejmiesz. Uruchomienie niekompatybilnej wersji PHP może spowodować białe ekrany, niedziałające procesy płatności, awarie modułów i luki w zabezpieczeniach. Ten kompleksowy przewodnik obejmuje każdą wersję PrestaShop od 1.6 do 9.x i przyporządkowuje każdą z nich do obsługiwanych wersji PHP, zalecanych konfiguracji i kwestii aktualizacji.

Dlaczego wersja PHP ma znaczenie dla PrestaShop

PHP to serwerowy język programowania, który napędza PrestaShop. Każda główna wersja PHP wprowadza poprawki wydajności, nowe funkcjonalności języka i wycofuje starsze funkcje. Kod źródłowy PrestaShop ewoluuje równolegle z PHP, co oznacza, że nowsze wersje PrestaShop wykorzystują nowoczesne funkcje PHP, jednocześnie rezygnując ze wsparcia dla przestarzałych wersji.

Używanie niewłaściwej wersji PHP powoduje trzy kategorie problemów:

• Błędy fatalne - Funkcje usunięte w nowszych wersjach PHP (np. funkcje mysql_* usunięte w PHP 7.0, each() usunięta w PHP 8.0) powodują natychmiastowe awarie.
• Ostrzeżenia o wycofaniu - Wycofane funkcje generują ostrzeżenia, które mogą uszkodzić odpowiedzi AJAX, wyjście JSON i generowanie PDF, gdy display_errors jest włączone.
• Narażenie na zagrożenia bezpieczeństwa - Wersje PHP, które osiągnęły koniec życia, nie otrzymują już łatek bezpieczeństwa, pozostawiając Twój sklep podatnym na ataki.

Pełna macierz kompatybilności

PrestaShop 1.6.x

Zalecane PHP dla 1.6.x - PHP 7.1. Oferuje najlepszą równowagę między wydajnością a kompatybilnością. Uruchamianie 1.6.x na PHP 7.2+ wymaga modyfikacji plików rdzeniowych, co przerywa ścieżkę aktualizacji i nie jest zalecane.

PrestaShop 1.7.x

Krytyczne ostrzeżenie - Żadna wersja PrestaShop 1.7 nie obsługuje PHP 8.0 ani nowszego. Jeśli uruchomisz PS 1.7.6 na PHP 8, Smarty natychmiast się zawiesi, ponieważ silnik szablonów używa funkcji usuniętych w PHP 8.0. Usunięcie funkcji each() i zmiany w działaniu array_key_exists() z obiektami powodują błędy fatalne.

PrestaShop 8.x

Zalecane PHP dla 8.x - PHP 8.1. Jest to optimum oferujące pełną kompatybilność, aktywne wsparcie bezpieczeństwa i doskonałą wydajność z kompilacją JIT. PHP 8.1 wprowadza Fibers, Enums, właściwości readonly i typy intersection, z których PrestaShop 8 może korzystać.

PrestaShop 9.x

Zalecane PHP dla 9.x - PHP 8.3 lub 8.4. PrestaShop 9 działa na Symfony 6.4 LTS i wymaga PHP 8.1 jako minimum. PHP 8.4 wprowadza Property Hooks i asymetryczną widoczność, które przyszłe aktualizacje PrestaShop będą wykorzystywać.

Daty zakończenia wsparcia PHP, które musisz znać

Jeśli w 2026 roku używasz PHP 7.4 lub 8.0, pracujesz na niewspieranej wersji, która nie otrzymuje już poprawek bezpieczeństwa. Jest to krytyczne ryzyko dla każdego sklepu e-commerce obsługującego dane płatnicze.

Jak sprawdzić aktualną wersję PHP

Metoda 1 - Panel administracyjny PrestaShop

Przejdź do Zaawansowane > Informacje. Sekcja Informacje o serwerze wyświetla Twoją wersję PHP wraz z limitem pamięci, maksymalnym czasem wykonania i innymi istotnymi ustawieniami.

Metoda 2 - Plik PHP Info

Utwórz plik o nazwie phpinfo.php w katalogu głównym sklepu o następującej treści:

<?php phpinfo();

Uzyskaj do niego dostęp przez przeglądarkę pod adresem https://twojsklep.com/phpinfo.php. Usuń ten plik natychmiast po sprawdzeniu - ujawnia wrażliwe szczegóły konfiguracji serwera.

Metoda 3 - Linia poleceń

php -v
php -r "echo PHP_VERSION;"

Pamiętaj, że wersja PHP CLI może różnić się od wersji PHP serwera web. Zawsze weryfikuj przez interfejs webowy lub phpinfo().

Typowe problemy przy nieprawidłowej wersji PHP

Biały ekran śmierci (WSOD)

Najczęstszy objaw niekompatybilności PHP. Sprawdź log błędów PHP (zazwyczaj pod /var/log/php-errors.log lub dostępny przez panel hostingowy). Typowe błędy to:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Ostrzeżenia o wycofaniu psują AJAX

Gdy display_errors = On i aktualizujesz PHP, ostrzeżenia o wycofaniu są dołączane do odpowiedzi AJAX. To psuje parsowanie JSON w panelu administracyjnym, powodując ciche awarie funkcji takich jak wyszukiwanie produktów, wyszukiwanie klientów i tworzenie zamówień. Rozwiązanie:

; php.ini
display_errors = Off
log_errors = On
error_log = /sciezka/do/php-error.log

Niekompatybilność modułów

Moduły firm trzecich mogą nie obsługiwać Twojej wersji PHP. Przed aktualizacją PHP sprawdź kompatybilność każdego zainstalowanego modułu. Typowe problematyczne obszary:

• Moduły używające create_function() - usunięta w PHP 8.0
• Moduły używające funkcji mysql_* - usunięte w PHP 7.0
• Moduły używające pozycyjnego dostępu do ciągów z nawiasami klamrowymi $str{0} - usunięte w PHP 8.0
• Moduły nieobsługujące nullable typów zwracanych - bardziej restrykcyjne od PHP 8.1+

Jak bezpiecznie zaktualizować PHP dla PrestaShop

Krok 1 - Audyt aktualnej konfiguracji

Zanim cokolwiek zmienisz, udokumentuj swoje obecne środowisko:

php -v                    # Aktualna wersja PHP
php -m                    # Załadowane rozszerzenia
php -i | grep memory      # Limit pamięci
php -i | grep max_exec    # Limit czasu wykonania

Krok 2 - Sprawdź kompatybilność modułów

Przejrzyj każdy zainstalowany moduł. Sprawdź dokumentację dewelopera modułu pod kątem obsługi wersji PHP. Jeśli moduł nie był aktualizowany od ponad dwóch lat, prawdopodobnie jest niekompatybilny z PHP 8.x.

Krok 3 - Najpierw przetestuj na stagingu

Nigdy nie aktualizuj PHP na serwerze produkcyjnym bez testów. Utwórz kopię staging swojego sklepu i przetestuj z nową wersją PHP. Sprawdź:

• Strony front office ładują się prawidłowo
• Strony produktów, kategorii, strony CMS
• Proces koszyka i zamówienia kończy się poprawnie
• Moduły płatności przetwarzają transakcje testowe
• Funkcjonalność back office działa (edycja produktów, zarządzanie zamówieniami)
• Wszystkie moduły firm trzecich działają prawidłowo
• Zadania cron wykonują się bez błędów

Krok 4 - Aktualizacja z planem wycofania

Większość dostawców hostingu pozwala na zmianę wersji PHP z panelu sterowania (cPanel, Plesk, DirectAdmin). Zachowaj poprzednią wersję PHP dostępną do szybkiego wycofania, jeśli pojawią się problemy.

Krok 5 - Wyczyść wszystkie cache po aktualizacji

Po zmianie wersji PHP wyczyść każdą warstwę cache:

# Wyczyść cache PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Wyczyść skompilowane szablony Smarty
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Jeśli używasz OPcache, uruchom ponownie PHP-FPM
systemctl restart php8.3-fpm

# Wyczyść cache CDN (Cloudflare, itp.)

Najlepsze praktyki konfiguracji PHP dla PrestaShop

Niezależnie od wybranej wersji PHP, te ustawienia są niezbędne dla optymalnej wydajności PrestaShop:

; Zalecane ustawienia php.ini
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Ustawienia OPcache (krytyczne dla wydajności)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Wymagane rozszerzenia
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Uwagi dla deweloperów modułów

Jeśli rozwijasz moduły PrestaShop, musisz starannie rozważyć kompatybilność PHP:

• Minimalna wersja PHP - Celuj w PHP 7.2 jako minimum dla modułów, które powinny działać na PrestaShop 8.0+, lub PHP 8.1 dla modułów przeznaczonych wyłącznie dla PrestaShop 9.
• Używaj PHPStan lub Psalm - Narzędzia analizy statycznej wykrywają niekompatybilności wersji PHP, zanim zrobią to Twoi użytkownicy.
• Unikaj składni specyficznej dla wersji - Funkcjonalności takie jak wyrażenia match (PHP 8.0), enums (PHP 8.1) i właściwości readonly (PHP 8.1) ograniczają Twój moduł do tych wersji PHP i wyższych.
• Testuj na wielu wersjach - Używaj kontenerów Docker z różnymi wersjami PHP, aby testować moduł na całym zakresie kompatybilności.

Często zadawane pytania

Czy mogę uruchomić PrestaShop 1.7 na PHP 8?

Nie. Żadna wersja PrestaShop 1.7 oficjalnie nie obsługuje PHP 8.0 ani nowszego. Chociaż niektórzy użytkownicy zastosowali łatki, aby częściowo to uruchomić, nie jest to wspierane i będzie powodować problemy przy aktualizacjach. Właściwą drogą jest migracja do PrestaShop 8.x.

Czy powinienem używać PHP 8.4 z PrestaShop 8.1?

Niezalecane. PrestaShop 8.1 został opracowany i przetestowany głównie z PHP 8.1. Chociaż PHP 8.2 jest częściowo obsługiwany w późniejszych wersjach 8.1.x, PHP 8.4 wprowadza zmiany, które mogą powodować problemy ze starszymi komponentami Symfony. Pozostań przy PHP 8.1 dla PrestaShop 8.x.

O ile szybszy jest PHP 8.x w porównaniu z 7.x?

Benchmarki pokazują, że PHP 8.1 jest około 20-30% szybszy niż PHP 7.4 dla typowych obciążeń PrestaShop. Kompilator JIT zapewnia największą korzyść przy zadaniach obliczeniowych. Dla operacji związanych z I/O (zapytania do bazy danych, odczyt plików) poprawa jest mniejsza, ale nadal mierzalna.

Czy aktualizacja PHP wymaga aktualizacji PrestaShop?

Niekoniecznie, ale obie rzeczy idą w parze. Możesz zaktualizować PHP w obsługiwanym zakresie dla swojej wersji PrestaShop bez aktualizacji samego PrestaShop. Jednak jeśli chcesz używać nowoczesnej wersji PHP (8.3+), będziesz potrzebować PrestaShop 8.1 lub 9.x.

Czym jest Varnish i dlaczego ma znaczenie dla PrestaShop

Varnish Cache to odwrotne proxy HTTP (reverse proxy), które znajduje się pomiędzy serwerem www a internetem i serwuje zbuforowane kopie stron bez jakiegokolwiek kontaktu z PHP czy MySQL. Gdy odwiedzający żąda strony, którą Varnish ma w cache, odpowiedź pochodzi bezpośrednio z pamięci operacyjnej w ciągu mikrosekund. PHP nie jest uruchamiane. MySQL nie otrzymuje żadnego zapytania. Serwer WWW praktycznie nie zauważa, że żądanie miało miejsce.

To podejście jest zasadniczo różne od tego, jak działają moduły pełnego buforowania stron (FPC) oparte na PHP w PrestaShop. Moduł FPC nadal działa w ramach PHP. Żądanie trafia do Apache lub Nginx, PHP się uruchamia, PrestaShop inicjalizuje się (ładuje konfigurację, nawiązuje połączenia z bazą danych, parsuje trasy), a następnie moduł FPC przechwytuje żądanie zanim pełna logika kontrolera zostanie uruchomiona, serwując buforowany plik HTML. Choć jest to znacznie szybsze niż renderowanie strony od zera, nadal wymaga uruchomienia PHP i załadowania frameworka PrestaShop. Ten narzut, wynoszący zazwyczaj 50-200 milisekund nawet przy trafieniu w cache, kumuluje się pod obciążeniem.

Varnish całkowicie eliminuje ten narzut. Trafienie w cache Varnish jest serwowane w 1-5 milisekund. Przy dużym ruchu różnica jest dramatyczna. Sklep PrestaShop, który z trudem obsługuje 100 jednoczesnych użytkowników z modułem FPC, może obsłużyć tysiące jednoczesnych użytkowników z Varnishem, ponieważ zdecydowana większość żądań nigdy nie dociera do backendu PHP.

Kiedy moduły PHP Full Page Cache są wystarczające

Zanim zainwestujesz w Varnish, warto zrozumieć, kiedy moduł FPC oparty na PHP jest wystarczająco dobry. Dla wielu sklepów PrestaShop tak właśnie jest.

Jeśli Twój sklep generuje mniej niż 50 000 dziennych wyświetleń stron, dobrze skonfigurowany moduł FPC poradzi sobie z obciążeniem bez problemów. Dodatkowa złożoność Varnisha nie jest uzasadniona, gdy serwer dysponuje rezerwą mocy obliczeniowej. Jeśli czasy odpowiedzi serwera z FPC są konsekwentnie poniżej 200 milisekund, Twoi odwiedzający już otrzymują szybkie ładowanie stron. Wąskim gardłem w tym momencie jest prawdopodobnie renderowanie po stronie frontendu (CSS, JavaScript, obrazy), a nie czas odpowiedzi serwera.

Moduły FPC radzą sobie z niektórymi scenariuszami specyficznymi dla PrestaShop bardziej elegancko niż Varnish, ponieważ działają wewnątrz aplikacji. Mogą sprawdzić, czy użytkownik jest zalogowany, czy koszyk zawiera produkty i czy pewna dynamiczna treść wymaga personalizacji — wszystko w ramach tego samego procesu PHP. W przypadku Varnisha te sprawdzenia muszą być obsługiwane przez inspekcję ciasteczek i reguły wariacji cache, co dodaje złożoności konfiguracyjnej.

Rozważ Varnish, gdy Twój sklep regularnie obsługuje skoki ruchu (wyprzedaże błyskawiczne, kampanie marketingowe, szczyty sezonowe), które przeciążają moce PHP, gdy potrzebujesz czasów odpowiedzi poniżej 10 ms ze względu na SEO lub doświadczenie użytkownika, gdy budżet na hosting jest ograniczony i musisz obsłużyć większy ruch na tym samym sprzęcie, lub gdy sklep obsługuje wysoki stosunek anonimowego przeglądania (strony kategorii, strony produktów) w stosunku do aktywności koszyka i kasy.

Jak działa Varnish: Przepływ żądań

Zrozumienie przepływu żądań przez Varnish jest kluczowe dla prawidłowej konfiguracji z PrestaShop.

Przychodzące żądanie

Gdy odwiedzający żąda strony, żądanie trafia najpierw do Varnisha (Varnish nasłuchuje na porcie 80 lub 443, jeśli zakończenie SSL jest obsługiwane przez proxy frontendowe). Varnish analizuje żądanie: URL, metodę HTTP, ciasteczka i nagłówki.

Wyszukiwanie w cache

Varnish sprawdza swój cache pod kątem zapisanej odpowiedzi pasującej do tego żądania. Klucz cache jest zwykle oparty na URL i wybranych nagłówkach. Jeśli pasująca odpowiedź istnieje i nie wygasła, Varnish serwuje ją bezpośrednio. To jest trafienie w cache (cache hit). Odpowiedź jest wysyłana do odwiedzającego, a serwer backendowy nie jest w ogóle kontaktowany.

Pudło cache

Jeśli brak pasującej zbuforowanej odpowiedzi, Varnish przekazuje żądanie do serwera backendowego (Apache lub Nginx z PrestaShop). PrestaShop przetwarza żądanie normalnie, generuje odpowiedź HTML i odsyła ją do Varnisha. Varnish zapisuje odpowiedź w swoim cache (jeśli odpowiedź nadaje się do buforowania) i przekazuje ją odwiedzającemu. Kolejne żądania tej samej strony będą serwowane z cache.

Inwalidacja cache

Gdy dane produktu się zmienią, ceny zostaną zaktualizowane lub treść zostanie zmodyfikowana, wersja w cache staje się nieaktualna. Varnish musi zostać poinformowany o konieczności odrzucenia starej wersji z cache, aby pobrał świeżą z backendu. To jest inwalidacja cache, i jest to najtrudniejsza część każdego systemu buforowania do prawidłowego wdrożenia.

Konfiguracja VCL dla PrestaShop

Varnish Configuration Language (VCL) to język specyficzny dla domeny, który kontroluje sposób obsługi żądań przez Varnish. Prawidłowa konfiguracja VCL dla PrestaShop musi obsługiwać kilka zachowań specyficznych dla PrestaShop.

Definicja backendu

Definicja backendu informuje Varnish, dokąd przekazywać pudła cache. Dla typowej konfiguracji PrestaShop, gdzie Apache lub Nginx działa na tym samym serwerze na porcie 8080:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .connect_timeout = 5s;
  .first_byte_timeout = 60s;
  .between_bytes_timeout = 10s;
}

Timeouty są ważne. Strony PrestaShop mogą potrzebować kilku sekund na wygenerowanie przy zimnym cache, szczególnie strony kategorii z wieloma produktami. Ustawienie first_byte_timeout zbyt nisko powoduje, że Varnish zwraca błąd 503 zanim PrestaShop zdąży wygenerować stronę.

Obsługa ciasteczek i sesji

Ciasteczka są największym wyzwaniem przy buforowaniu PrestaShop z Varnishem. PrestaShop ustawia domyślnie kilka ciasteczek, a Varnish traktuje każde żądanie z ciasteczkami jako niebuforowalne, chyba że poinstruujemy go inaczej. Jeśli nie obsłużysz ciasteczek w swoim VCL, Varnish nie będzie buforował praktycznie niczego.

PrestaShop ustawia te ciasteczka przy większości żądań: ciasteczko sesji (zwykle o nazwie PrestaShop-xxxx), ciasteczka związane z koszykiem, ciasteczka Google Analytics (_ga, _gid, _gat) oraz różne ciasteczka śledzące od narzędzi marketingowych. Spośród nich tylko ciasteczko sesji PrestaShop ma znaczenie dla zachowania cache. Ciasteczka analityczne i śledzące powinny być usuwane z żądania przed wyszukiwaniem w cache, aby nie uniemożliwiały buforowania.

W podprocedurze VCL vcl_recv usuń nieistotne ciasteczka:

sub vcl_recv {
  # Usuń ciasteczka Google Analytics i inne śledzące
  set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", "");
  # Usuń pusty nagłówek ciasteczka
  if (req.http.Cookie ~ "^\s*$") {
    unset req.http.Cookie;
  }
}

Decydowanie, co buforować

Nie każda strona PrestaShop powinna być buforowana. VCL musi rozróżniać między żądaniami buforowalnymi i niebuforowalnymi.

Zawsze buforuj: Strony produktów dla anonimowych odwiedzających, strony z listą kategorii, strony CMS (o nas, regulamin, kontakt), stronę główną, strony producentów i dostawców, strony mapy witryny.

Nigdy nie buforuj: Strony koszyka, strony kasy (wszystkie kroki), obszaru konta klienta (zamówienia, adresy, dane osobowe), stron logowania i rejestracji, żadnej strony dla zalogowanego klienta, żądań POST, żądań AJAX modyfikujących stan (dodaj do koszyka, aktualizuj ilość).

Logika VCL do tego celu zwykle sprawdza ścieżkę URL i obecność ciasteczek sesji:

sub vcl_recv {
  # Nie buforuj żądań POST
  if (req.method == "POST") {
    return (pass);
  }
  # Nie buforuj panelu administracyjnego
  if (req.url ~ "^/admin") {
    return (pass);
  }
  # Nie buforuj kasy i koszyka
  if (req.url ~ "(cart|order|login|my-account|module/)" ) {
    return (pass);
  }
  # Nie buforuj, jeśli klient ma produkty w koszyku
  if (req.http.Cookie ~ "PrestaShop-") {
    return (pass);
  }
  return (hash);
}

Ustawianie czasu życia cache

W podprocedurze vcl_backend_response kontrolujesz, jak długo Varnish buforuje każdą odpowiedź. PrestaShop wysyła nagłówki Cache-Control, które zwykle mówią no-cache lub private, ponieważ zakłada, że każda odpowiedź może zawierać spersonalizowaną treść. Musisz je nadpisać dla stron, o których wiesz, że są bezpieczne do buforowania:

sub vcl_backend_response {
  # Buforuj strony produktów i kategorii przez 1 godzinę
  if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") {
    set beresp.ttl = 1h;
    unset beresp.http.Set-Cookie;
  }
  # Buforuj zasoby statyczne przez 1 dzień
  if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") {
    set beresp.ttl = 1d;
    unset beresp.http.Set-Cookie;
  }
}

Usuwanie Set-Cookie z buforowanych odpowiedzi jest krytyczne. Jeśli buforowana odpowiedź zawiera nagłówek Set-Cookie, Varnish domyślnie jej nie zbuforuje, a nawet jeśli zostanie zmuszony do buforowania, ustawi to samo ciasteczko sesji dla każdego odwiedzającego, powodując przechwycenie sesji (session hijacking).

Inwalidacja cache za pomocą żądań PURGE

Gdy cena produktu się zmienia, nowy produkt jest dodawany lub treść jest aktualizowana, buforowana wersja musi zostać unieważniona. Varnish obsługuje żądania PURGE: specjalną metodę HTTP, która informuje Varnish o konieczności usunięcia konkretnego URL z cache.

Konfiguracja obsługi PURGE

Dodaj obsługę PURGE do swojego VCL:

acl purge {
  "127.0.0.1";
  "localhost";
}

sub vcl_recv {
  if (req.method == "PURGE") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    return (purge);
  }
}

ACL ogranicza żądania PURGE do localhost, uniemożliwiając zewnętrznym użytkownikom czyszczenie Twojego cache.

Wyzwalanie operacji purge z PrestaShop

PrestaShop natywnie nie wysyła żądań PURGE. Potrzebujesz modułu lub niestandardowego hooka, który wykrywa zmiany w treści nadającej się do buforowania i wysyła żądanie PURGE do Varnisha. Moduł podpina się pod zdarzenia PrestaShop takie jak actionProductUpdate, actionCategoryUpdate i actionCMSPageUpdate. Gdy te zdarzenia są wywoływane, moduł wysyła żądanie HTTP PURGE na odpowiedni URL serwera Varnish.

Przy aktualizacji produktu moduł powinien wyczyścić URL produktu, URL kategorii, do których produkt należy (ponieważ strony z listą kategorii wyświetlają ceny i dostępność produktów) oraz potencjalnie stronę główną, jeśli wyświetla polecane produkty. Ta kaskada operacji purge jest konieczna, aby zapobiec wyświetlaniu nieaktualnych danych w dowolnym miejscu witryny.

Inwalidacja oparta na BAN

W scenariuszach, gdy wiele URL-i wymaga jednoczesnego wyczyszczenia (aktualizacja cen w całej witrynie, zmiana designu, nowy baner promocyjny), indywidualne żądania PURGE są niepraktyczne. Varnish obsługuje bany, czyli reguły inwalidacji oparte na wzorcach. Ban informuje Varnish o konieczności odrzucenia każdego zbuforowanego obiektu pasującego do wzorca:

sub vcl_recv {
  if (req.method == "BAN") {
    if (!client.ip ~ purge) {
      return (synth(405, "Not allowed."));
    }
    ban("req.url ~ " + req.http.X-Ban-Pattern);
    return (synth(200, "Banned."));
  }
}

Wysłanie żądania BAN z nagłówkiem X-Ban-Pattern: /category/ unieważni wszystkie zbuforowane strony kategorii w jednej operacji.

Edge Side Includes (ESI) dla bloków dynamicznych

Wiele stron PrestaShop zawiera mieszankę treści statycznej i dynamicznej. Lista produktów na stronie kategorii jest taka sama dla każdego odwiedzającego, ale nagłówek pokazujący liczbę produktów w koszyku jest spersonalizowany. Bez ESI nie można buforować strony w ogóle, ponieważ dynamiczny nagłówek sprawia, że cała odpowiedź jest specyficzna dla odwiedzającego.

Edge Side Includes rozwiązują to, pozwalając na oznaczenie sekcji strony jako osobno pobieranych fragmentów. Varnish składa finalną stronę z fragmentów buforowanych i niebuforowanych.

Jak działa ESI

W szablonie Smarty, zamiast renderować widget koszyka bezpośrednio, umieszczasz tag ESI:

<esi:include src="/module/cartwidget/ajax" />

Gdy Varnish przetwarza buforowaną stronę, napotyka tag ESI i wysyła osobne żądanie do backendu po ten fragment. Główne ciało strony jest serwowane z cache, podczas gdy widget koszyka jest pobierany świeżo z PrestaShop. Złożona odpowiedź zawiera zarówno buforowane ciało, jak i świeży widget koszyka.

Włącz przetwarzanie ESI w swoim VCL:

sub vcl_backend_response {
  set beresp.do_esi = true;
}

Aspekty ESI dla PrestaShop

Wdrożenie ESI wymaga modyfikacji szablonów PrestaShop w celu oddzielenia dynamicznej treści na fragmenty kompatybilne z ESI. Każdy fragment potrzebuje własnego endpointu URL, który zwraca tylko HTML dla tego bloku. Fragmenty, które są zwykle dynamiczne i wymagają obsługi ESI, to: widget podsumowania koszyka (liczba produktów, suma), powitanie klienta ("Cześć, Jan"), wszelkie spersonalizowane rekomendacje produktów, link logowania/wylogowania oraz ostatnio przeglądane produkty.

Nakład pracy wymagany do prawidłowego wdrożenia ESI jest znaczny. Każdy dynamiczny fragment potrzebuje dedykowanego kontrolera, szablony wymagają restrukturyzacji, a reguły buforowania dla każdego fragmentu wymagają indywidualnego dostrojenia. To jeden z powodów, dla których Varnish jest uważany za zaawansowaną optymalizację — działa najlepiej, gdy aplikacja jest projektowana z myślą o nim.

Kontrole zdrowia backendu

Varnish może monitorować stan serwera backendowego i podejmować działania, gdy staje się niedostępny. Konfiguruje się to w definicji backendu:

backend default {
  .host = "127.0.0.1";
  .port = "8080";
  .probe = {
    .url = "/ping.php";
    .timeout = 2s;
    .interval = 5s;
    .window = 5;
    .threshold = 3;
  }
}

Varnish wysyła żądanie do /ping.php co 5 sekund. Jeśli 3 z ostatnich 5 sprawdzeń zakończy się niepowodzeniem, Varnish oznacza backend jako chory. Gdy backend jest chory, Varnish może serwować nieaktualną treść z cache (tryb grace) zamiast zwracać błędy odwiedzającym. Oznacza to, że Twój sklep pozostaje częściowo dostępny nawet gdy backend PHP ulega awarii lub jest restartowany.

Konfiguracja trybu grace określa, jak długo Varnish będzie serwował nieaktualną treść:

sub vcl_backend_response {
  set beresp.grace = 6h;
}

Z 6-godzinnym grace, jeśli Twój backend padnie, odwiedzający zobaczą buforowane strony (nawet jeśli mają do 6 godzin) zamiast stron błędów. Ceny produktów mogą być nieznacznie nieaktualne, ale sklep pozostaje funkcjonalny, dopóki naprawiasz problem z backendem.

Benchmarki wydajności

Różnica wydajności między brakiem cache, PHP FPC i Varnishem jest znaczna i mierzalna.

Bez cache (czysty PrestaShop): Typowa strona produktu PrestaShop generuje się w 200-800 milisekund, w zależności od sprzętu serwera, liczby załadowanych modułów i liczby zapytań do bazy danych. Pod obciążeniem czasy odpowiedzi rosną, ponieważ workery PHP są nasycone. Pojedynczy serwer może obsłużyć 20-50 jednoczesnych użytkowników, zanim czasy odpowiedzi staną się nie do zaakceptowania.

Moduł PHP FPC: Trafienia w cache serwowane są w 30-100 milisekund, ponieważ PHP nadal się uruchamia, a framework częściowo inicjalizuje. Pod obciążeniem wydajność jest znacznie lepsza, ponieważ buforowane odpowiedzi wymagają minimalnego czasu przetwarzania PHP. Pojedynczy serwer może obsłużyć 200-500 jednoczesnych użytkowników w zależności od konfiguracji. Pudła cache nadal trwają pełny czas renderowania.

Varnish: Trafienia w cache serwowane są w 1-5 milisekund. Pod obciążeniem sam Varnish może obsłużyć tysiące jednoczesnych połączeń, ponieważ jest napisany w C i zaprojektowany specjalnie do tego obciążenia. Serwer backendowy obsługuje tylko pudła cache, które stanowią niewielki ułamek całkowitego ruchu w prawidłowo skonfigurowanym systemie. Ten sam sprzęt, który z trudem obsługuje 50 jednoczesnych użytkowników bez buforowania, może obsłużyć 5000 lub więcej z Varnishem.

Te liczby ilustrują, dlaczego Varnish jest wart złożoności konfiguracyjnej dla sklepów o dużym ruchu. Poprawa wydajności nie jest przyrostowa — jest o rząd wielkości.

Wymagania hostingowe

Varnish ma specyficzne wymagania hostingowe, których nie każde środowisko hostingowe PrestaShop może spełnić.

Dostęp do serwera

Potrzebujesz dostępu root, aby zainstalować i skonfigurować Varnish. Plany hostingu współdzielonego nie obsługują Varnisha, ponieważ wymaga on własnego procesu nasłuchującego na porcie i przechwytującego cały ruch HTTP. Potrzebujesz VPS, serwera dedykowanego lub instancji chmurowej, gdzie kontrolujesz pełny stos serwerowy.

Pamięć operacyjna

Varnish przechowuje swój cache w RAM. Ilość potrzebnej pamięci RAM zależy od liczby unikalnych stron w Twoim katalogu i rozmiaru każdej buforowanej odpowiedzi. Przybliżony wzór: liczba stron nadających się do buforowania pomnożona przez średni rozmiar strony daje minimalny rozmiar cache. Sklep z 5000 produktami, 200 kategoriami i średnim rozmiarem strony 50 KB potrzebuje około 260 MB pamięci cache. Dodaj narzut na sam Varnish i powinieneś przydzielić co najmniej 512 MB. Dla większych katalogów typowe jest 1-2 GB.

Konfiguracja portów

W standardowej konfiguracji Varnish nasłuchuje na porcie 80 (domyślny port HTTP) i przekazuje pudła cache do serwera www na innym porcie (zwykle 8080). Oznacza to, że musisz przekonfigurować Apache lub Nginx, aby nasłuchiwał na porcie 8080 zamiast 80. Jeśli używasz HTTPS (a powinieneś), zazwyczaj umieszczasz Nginx przed Varnishem do obsługi zakończenia SSL: Nginx na porcie 443 kończy SSL i przekazuje do Varnisha na porcie 80, który przekazuje pudła cache do Apache lub PHP-FPM na porcie 8080.

Przykład konfiguracji Docker

Uruchomienie Varnisha w Dockerze obok kontenera PrestaShop to czysty sposób na dodanie Varnisha do istniejącej konfiguracji bez modyfikowania systemu hosta.

Konfiguracja Docker Compose

Podstawowa konfiguracja Docker Compose z Varnishem, Nginx do SSL i PrestaShop:

services:
  varnish:
    image: varnish:7.4
    ports:
      - "80:80"
    volumes:
      - ./varnish/default.vcl:/etc/varnish/default.vcl:ro
    environment:
      - VARNISH_SIZE=512m
    depends_on:
      - prestashop
  prestashop:
    image: prestashop/prestashop:8
    expose:
      - "80"
    environment:
      - DB_SERVER=db
  db:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=secretpassword
      - MYSQL_DATABASE=prestashop

W tej konfiguracji Varnish jest punktem wejściowym na porcie 80. Kontener PrestaShop nie eksponuje swojego portu na hosta, tylko na sieć Dockera. Hostem backendu VCL byłby prestashop (nazwa usługi Docker) na porcie 80.

VCL dla Dockera

Definicja backendu VCL dla Dockera używa nazwy usługi zamiast localhost:

backend default {
  .host = "prestashop";
  .port = "80";
}

Wewnętrzne DNS Dockera rozwiązuje nazwę usługi na IP kontenera. Reszta konfiguracji VCL pozostaje taka sama jak w konfiguracji bez Dockera.

Przechowywanie cache w Dockerze

Domyślnie obraz Docker Varnish używa przechowywania w pamięci (malloc), co jest idealne dla wydajności. Zmienna środowiskowa VARNISH_SIZE kontroluje, ile pamięci Varnish przydziela na swój cache. Ustaw tę wartość na taką, która mieści się w limitach pamięci kontenera, pozostawiając miejsce na sam proces Varnish.

Dla trwałego cache, który przetrwa restarty kontenera, możesz użyć przechowywania plikowego montując wolumen, ale jest to rzadko konieczne. Cache rozgrzewa się szybko (w ciągu minut od otrzymania ruchu), a przechowywanie plikowe jest wolniejsze niż przechowywanie w pamięci.

Monitorowanie wydajności Varnisha

Varnish zapewnia wbudowane narzędzia do monitorowania wydajności cache.

Polecenie varnishstat pokazuje statystyki w czasie rzeczywistym, w tym współczynnik trafień cache, połączenia z backendem i wykorzystanie pamięci. Najważniejszą metryką jest współczynnik trafień, który powinien wynosić 85% lub więcej dla dobrze skonfigurowanego systemu. Jeśli współczynnik trafień jest poniżej 70%, przejrzyj reguły VCL, ponieważ zbyt wiele żądań przechodzi do backendu.

Polecenie varnishlog pokazuje szczegółowe logi per żądanie, które są nieocenione przy debugowaniu, dlaczego konkretne żądania nie są buforowane. Możesz filtrować po wzorcu URL, kodzie odpowiedzi lub statusie trafienia/pudła cache.

Polecenie varnishtop pokazuje rankingową listę najczęstszych wpisów w logach, pomagając identyfikować wzorce w pudłach cache lub błędach.

Typowe pułapki

Zapominanie o usuwaniu ciasteczek

Najczęstszą błędną konfiguracją Varnisha z PrestaShop jest nieusuwanie ciasteczek analitycznych i śledzących. Te ciasteczka są obecne w praktycznie każdym żądaniu i sprawiają, że każde żądanie jest unikalne z perspektywy Varnisha, co skutkuje 0% współczynnikiem trafień. Zawsze usuwaj ciasteczka, których nie potrzebujesz do wariacji cache.

Buforowanie spersonalizowanej treści

Jeśli Twój VCL jest zbyt agresywny, będzie buforować strony zawierające spersonalizowaną treść (powitanie zalogowanego użytkownika, zawartość koszyka) i serwować je innym odwiedzającym. Powoduje to poważne problemy z użytecznością i potencjalne problemy z prywatnością. Zawsze przekazuj żądania zawierające ciasteczka sesji do backendu.

Brak inwalidacji przy zmianach treści

Bez odpowiedniego mechanizmu czyszczenia cache zmiany treści w panelu administracyjnym nie będą widoczne, dopóki buforowane strony nie wygasną naturalnie. Dla sklepu z aktywnymi zmianami stanów magazynowych oznacza to, że odwiedzający mogą widzieć produkty niedostępne, błędne ceny lub nieaktualne opisy. Wdróż obsługę PURGE lub BAN i zintegruj ją z hookami aktualizacji PrestaShop.

Ignorowanie HTTPS

Varnish natywnie nie obsługuje SSL. Musisz umieścić proxy kończące SSL (Nginx, HAProxy lub chmurowy load balancer) przed Varnishem. Brak zaplanowania tego w architekturze prowadzi do problemów z mieszaną treścią (mixed content), pętli przekierowań lub niemożności serwowania ruchu HTTPS w ogóle.

Czy Varnish jest odpowiedni dla Twojego sklepu

Varnish to potężne narzędzie, ale nie jest właściwym wyborem dla każdego sklepu PrestaShop. Dodaje złożoność operacyjną: kolejną usługę do monitorowania, kolejny język konfiguracyjny do nauki, kolejną warstwę w procesie debugowania. Korzyści są jasne i mierzalne dla sklepów, które ich potrzebują, ale wiążą się z kosztem w postaci czasu konfiguracji, konserwacji i trudności w rozwiązywaniu problemów.

Jeśli Twój sklep obsługuje mniej niż 50 000 wyświetleń stron dziennie, a serwer radzi sobie z obciążeniem komfortowo z modułem FPC, Varnish to niepotrzebna złożoność. Jeśli Twój sklep regularnie mierzy się ze skokami ruchu, które przeciążają serwer, obsługuje dużą ilość anonimowego ruchu przeglądania lub potrzebuje najszybszych możliwych czasów odpowiedzi dla SEO czy doświadczenia użytkownika, Varnish zapewnia poziom wydajności, którego żadne rozwiązanie buforowania oparte na PHP nie jest w stanie dorównać.

Zacznij od właściwej optymalizacji PrestaShop (optymalizacja zapytań, audyt modułów, PHP OPcache, optymalizacja obrazów) i modułu FPC. Jeśli te optymalizacje nie wystarczą, Varnish jest kolejnym krokiem na drabinie skalowania wydajności.