-- Găsește cele mai mari opțiuni autoloaded care îți încetinesc site-ul
SELECT option_name, length(option_value) AS option_size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_size DESC
LIMIT 20;Am avut recent pe mână un magazin WooCommerce cu vreo 15.000 de produse active și variații fără număr. Se mișca execrabil. TTFB-ul era undeva la 3-4 secunde pe paginile de categorie, iar când se dădea un „add to cart”, serverul pur și simplu gâfâia.
Clientul voia să schimbe hostingul și să arunce cu bani în instanțe mai mari de VPS. I-am zis să stea potolit. Cu trei modificări targetate, am adus TTFB-ul la sub 200ms pentru paginile statice și sub 1.2 secunde pe checkout. Iată cum am făcut-o, fără povești nemuritoare.
1. Redis Object Cache: Salvarea bazei de date
Toată lumea știe de cache de pagină (WP Rocket, LiteSpeed etc.). Dar cache-ul de pagină moare instant când un user se loghează sau adaugă ceva în coș. WooCommerce dezactivează cache-ul pe pagină pentru acești useri, ca să nu le arate coșul altcuiva. Aici intervine Redis.
În loc ca WordPress să interogheze MySQL-ul de 200 de ori la fiecare încărcare de pagină pentru a lua opțiuni, metadate de produse și termeni, Redis ține aceste obiecte direct în memoria RAM.
Cum am făcut-o: Am instalat extensia Redis pe server și pluginul „Redis Object Cache” (cel gratuit, de Till Krüss, e arhisuficient).
Trade-off-ul sincer: Redis consumă RAM. Dacă ai un VPS de 2GB și baza de date e deja mare, s-ar putea ca Redis să îți dea crash dacă nu îi limitezi memoria (maxmemory în redis.conf) și nu setezi o politică de evacuare corectă (cum ar fi allkeys-lru).
2. Cloudflare APO (Automatic Platform Optimization)
Pentru vizitatorii anonimi, Cloudflare APO este pur și simplu genial. Costă 5$ pe lună (dacă ești pe planul free de Cloudflare) și face cache la tot HTML-ul direct în serverele lor de edge global.
Diferența față de cache-ul clasic Cloudflare e că APO știe nativ de WordPress. Când modifici un produs, Cloudflare șterge cache-ul doar pentru acea pagină și pentru arhivele aferente. De asemenea, știe să facă bypass la cache instant când detectează cookie-urile de sesiune WooCommerce (woocommerce_items_in_cart sau cele de login).
Problema de care m-am lovit: Unele pluginuri de marketing sau de tracking (gen cele de Pixel) setau cookie-uri inutile pe fiecare vizită, ceea ce făcea ca Cloudflare să creadă că userul e logat și să dea bypass la cache. A trebuit să curățăm scripturile astea ca să vedem beneficiul real.
3. Query Optimization: Curățenia în wp_options
Cea mai mare problemă la WooCommerce-urile vechi sunt datele „autoloaded” din tabela wp_options. WordPress încarcă aceste date la ABSOLUT fiecare request. Pe proiectul ăsta, aveam peste 120MB de date care se încărcau în memorie la fiecare accesare. Multe erau de la pluginuri șterse acum 3 ani.
Am rulat un query SQL ca să identificăm vinovații și am dezactivat autoload-ul pentru opțiunile transient care nu mai aveau sens sau pentru setările de la pluginuri vechi.
După ce am rulat query-ul de mai jos, am redus dimensiunea opțiunilor autoloaded de la 120MB la doar 1.8MB. Serverul a început să respire instant.
Ce părere aveți? Mai merită bătălia de optimizat WooCommerce pe bucăți sau vi se pare că Shopify a câștigat deja segmentul ăsta tocmai din cauza durerilor de cap cu performanța?