/**
* Exemplu simplu de cache-uire a unui query greu folosind Transients
*/
function get_best_sellers_cached() {
$cache_key = 'wc_best_sellers_homepage';
$products = get_transient($cache_key);
if (false === $products) {
$query = new WP_Query([
'post_type' => 'product',
'posts_per_page' => 8,
'meta_key' => 'total_sales',
'orderby' => 'meta_value_num',
'order' => 'DESC',
'fields' => 'ids', // Luăm doar ID-urile pentru a economisi memorie
]);
$products = $query->posts;
// Salvăm în cache pentru 6 ore (21600 secunde)
set_transient($cache_key, $products, 6 * HOUR_IN_SECONDS);
}
return $products;
}Salutare tuturor. Am lucrat recent la optimizarea unui magazin WooCommerce destul de măricel, cu vreo 12.000 de produse active și destul de multe variații de culoare și mărime. Pe un VPS de 15 euro de la Hetzner, site-ul se mișca execrabil: TTFB de peste 2 secunde pe paginile de categorie și un load total care trecea lejer de 4.5 secunde. Proprietarul pierdea clienți din cauza asta, evident.
Nu am vrut să aruncăm cu bani în hosting mai scump înainte de a face curățenie. Iată pașii exacți prin care am adus site-ul la un timp de încărcare de sub 1.2 secunde.
Pasul 1: Redis Object Cache (Salvarea bazei de date)
Problema principală la WooCommerce este că baza de date este extrem de fragmentată din cauza structurii de tip Entity-Attribute-Value (EAV) din WordPress. Fiecare vizită pe o pagină de produs înseamnă zeci de interogări în wp_postmeta.
Am instalat Redis pe server și am activat pluginul gratuit Redis Object Cache (scris de Till Krüss). Ce face asta? În loc ca WordPress să interogheze baza de date MySQL de fiecare dată când are nevoie de opțiunile site-ului sau de metadatele produselor, le cere direct din memoria RAM (Redis).
Trade-off-ul sincer: Redis este excelent pentru query-uri repetitive, dar dacă ai pluginuri scrise prost care fac update_post_meta la fiecare vizualizare de pagină (de exemplu, un contor de vizualizări), vei umple memoria RAM imediat și vei avea probleme de sincronizare a cache-ului.
Pasul 2: Cloudflare APO (Automatic Platform Optimization)
Pentru 5 dolari pe lună, Cloudflare APO este probabil cea mai bună investiție pe care o poți face pentru un site pe WordPress. Acesta rulează pe edge-ul Cloudflare și servește paginile HTML direct din cache-ul lor global, chiar și pentru utilizatorii neautentificați.
Practic, pentru un vizitator nou, TTFB-ul scade de la 800ms la sub 50ms, pentru că request-ul nu mai ajunge deloc la serverul tău din Germania sau România, ci se oprește la cel mai apropiat nod Cloudflare.
Atenție la dinamică: WooCommerce folosește cookie-uri precum wp_woocommerce_session_ pentru a detecta dacă un utilizator are produse în coș. Cloudflare APO știe să citească aceste cookie-uri și să facă bypass la cache instantaneu când cineva adaugă un produs în coș. Totuși, dacă ai un widget de coș în header generat static, s-ar putea să ai surprize. Soluția a fost să trecem widget-ul pe încărcare via AJAX (fragmentation în WC).
Pasul 3: Curățarea query-urilor din wp_postmeta
După ce am rezolvat cache-ul, tot aveam pagini de filtrare care durau mult prea mult. Am activat Query Monitor și am descoperit că un plugin de filtrare genera un query SQL monstruos cu 8 JOIN-uri pe tabela wp_postmeta pentru a găsi produsele după atribute.
Am renunțat la acel plugin și am trecut pe filtrele native din WooCommerce, care folosesc tabele de lookup optimizate (introduse în versiunile mai noi de WC).
În plus, pentru query-urile custom pe care le aveam în homepage (cum ar fi "produsele cele mai vândute din categoria X"), am implementat un sistem simplu de caching folosind Transient API. În loc să rulăm WP_Query la fiecare accesare, rulăm interogarea o singură dată la 6 ore și salvăm rezultatul.
Cum gestionați voi cache-ul pe magazinele cu trafic mare? Mergeți pe Redis sau preferați Memcached?