Găzduire și performanță
Cum facem WordPress rapid: LiteSpeed Enterprise, LSCache și Redis pentru fiecare site
Cea mai rapidă solicitare WordPress este cea care nu rulează niciodată — iată cum răspunde stiva noastră la majoritatea vizitelor din memoria cache înainte de a fi apelat PHP sau MySQL, și ce înseamnă acest lucru pentru Core Web Vitals.
Cea mai rapidă solicitare este cea care nu se execută niciodată
O solicitare standard WordPress este costisitoare. Serverul web predă sarcina către PHP, PHP inițializează WordPress, rulează pluginurile, interoghează MySQL de câteva zeci de ori, asamblează codul HTML și abia apoi trimite octeții înapoi. Pe un site aglomerat, tot acest proces are loc pentru fiecare vizitator și reprezintă locul unde se consumă aproape tot time-to-first-byte-ul dumneavoastră.
Răspunsul nostru este să ne asigurăm că, pentru majoritatea vizitelor, nimic din toate acestea nu se întâmplă deloc. Pe toate site-urile pe care le găzduim — peste 100.000 de site-uri PBN, plus instalări gestionate convenționale de WordPress —, marea majoritate a afișărilor de pagină de pe front-end sunt servite ca o pagină completă prerenderizată direct din memoria cache, fără a invoca PHP sau a accesa baza de date. Restul acestei postări este despre modul în care se îmbină nivelurile care fac acest lucru posibil și despre locul pe care fiecare dintre ele îl merită.
Cadrul important este că acestea nu sunt memorii cache concurente între care trebuie să alegeți. Memoria cache de pagină completă, memoria cache de obiecte și marginea CDN capturează fiecare o clasă diferită de solicitări, iar valoarea constă în modul în care se succed reciproc.
LiteSpeed Enterprise + LSCache: stratul de pagină întreagă
Fiecare site rulează pe LiteSpeed Enterprise cu LSCache la nivel de server. Când un răspuns front-end poate fi stocat în cache, serverul web îl marchează cu anteturi de etichete și cache-control LiteSpeed, iar LiteSpeed livrează pagina completă direct la următoarea accesare — fără a genera vreun proces PHP și fără a lansa vreo interogare MySQL. Aceasta este cea mai importantă pârghie individuală pentru TTFB în WordPress, deoarece elimină întreaga inițializare a aplicației din calea critică.
Deoarece LSCache se află în interiorul serverului web și nu într-un modul PHP, acesta începe să funcționeze mai devreme în ciclul de viață al solicitării și păstrează paginile într-o formă pe care serverul o poate goli instantaneu. Un crawler de memorie cache menține paginile populare active, astfel încât primul vizitator de după o curățare să nu fie cel care plătește costul regenerării paginii. Rezultatul este un TTFB considerabil mai redus și mai constant decât în cazul unui modul exclusiv de memorie cache atașat unei stive generice, unde memoria cache se află în continuare în spatele PHP.
Propriul nostru modul de cache de nivel repo vine preinstalat și actualizat automat pe fiecare site, conectând corect WordPress la LSCache încă de la început. Pe o sursă non-LiteSpeed, acesta pur și simplu nu emite anteturi de pagină completă și nu interferează, în timp ce memoria cache pentru obiecte și regulile de excludere continuă să funcționeze — astfel încât un site migrat nu este lăsat niciodată într-o stare defectuoasă, configurată doar pe jumătate.
Rămâneți rapid fără a livra conținut învechit: ESI și golire automată inteligentă
Memorarea în cache agresivă a întregii pagini prezintă două moduri clasice de eroare: servirea paginii altcuiva unui utilizator conectat și servirea către oricine a unei pagini care ar fi trebuit să fie modificată. Ambele se rezolvă la nivelul stratului de cache, nu prin reducerea memorării în cache.
ESI (Edge Side Includes) ne permite să stocăm pagina în memoria cache, lăsând spații libere pentru părțile care trebuie să rămână dinamice. Pe un magazin WooCommerce, paginile de catalog, produse și categorii sunt livrate ca memorie cache pentru întreaga pagină pentru cel mai rapid TTFB posibil, în timp ce ESI randează fragmentul de coș, totalurile din mini-coș și starea contului per solicitare. Paginile pentru coș, finalizare comandă, contul meu și orice pagini de tip nonce sau sesiune sunt excluse în mod prestabilit. Cumpărătorii își văd întotdeauna propriul coș și o finalizare a comenzii funcțională; toată lumea primește în continuare vitrina magazinului din memoria cache.
Actualitatea conținutului este gestionată prin curățare automată inteligentă. Cârligele de golire se declanșează automat atunci când conținutul, produsele, prețurile sau comenzile se modifică, astfel încât paginile relevante din cache se reîmprospătează imediat, nu pe baza unui cronometru, și puteți, de asemenea, să goliți memoria cache la cerere din panoul de control sau direct din WordPress. Golirea bazată pe etichete înseamnă că editarea unei postări curăță acea postare și arhivele sale — nu întreaga memorie cache —, astfel încât o singură modificare nu repornește la rece întregul site.
Memorie cache pentru obiecte Redis per site: pentru ceea ce nu poate fi o pagină întreagă
Nu orice solicitare poate fi o pagină completă statică. Sesiunile conectate, panoul de administrare WordPress, coșurile WooCommerce, căutarea și fragmentele dinamice lăsate live de ESI trebuie să ruleze toate PHP. Pentru acestea, obiectivul trece de la „săriți peste aplicație” la „săriți peste baza de date”.
Fiecare site primește propriul cache de obiecte Redis dedicat. WordPress stochează în memorie rezultatele citirilor repetate din baza de date — opțiuni, transients, căutări de articole și termeni, date despre produse și sesiuni WooCommerce —, astfel încât aceeași interogare să nu fie rulată în MySQL la fiecare accesare. Efectul este cel mai vizibil exact acolo unde memoria cache a întregii pagini nu poate ajuta: panouri de control mai rapide, coșuri de cumpărături mai rapide și o încărcare mult mai redusă a bazei de date în condiții de trafic intens.
Memoria cache a obiectelor este alocată fiecărui site în parte, nu este partajată, ceea ce contează atât pentru performanță, cât și pentru izolare. În combinație cu limitarea bazei de date per site, interogările mari sau scrise necorespunzător ale unui site nu pot epuiza resursele bazei de date pentru site-urile învecinate. Puteți citi mai multe despre modul în care întreaga configurație multistrat funcționează împreună pe pagina noastră cu funcționalități de stocare în cache și despre limitele dintre locatari în condiții de izolare.
Marginea și transportul de dedesubt
Memoria cache care se află pe originea serverului trebuie totuși să traverseze rețeaua. În fața serverului se află marginea CDN, astfel încât resursele statice și paginile care pot fi stocate în cache sunt livrate dintr-un punct de prezență apropiat de vizitator, iar originea rămâne neîncărcată chiar și sub trafic intens. Pentru linia noastră de găzduire fără amprentă (footprint-free), aceeași margine este un ansamblu multi-CDN distribuit între mai mulți furnizori, care servește atât unui obiectiv legat de amprenta SEO (footprint), cât și unuia de performanță; pe WordPress-ul tradițional, este pur și simplu un strat rapid și eficient care menține originile inactive.
La bază, nu s-a făcut rabat de la elementele fundamentale. Site-urile rulează pe stocare NVMe cu HTTP/3, astfel încât octeții trimiși de cache ajung printr-un transport modern, multiplexat, susținut de stocare rapidă în cazul oricărui cache miss. Niciunul dintre aceste niveluri nu este un supliment contra cost: LiteSpeed, LSCache, Redis per site, NVMe și HTTP/3 constituie standardul de bază pentru fiecare abonament, nu un nivel comercial superior.
Ce influențează cu adevărat Core Web Vitals
Merită să fim preciși, deoarece găzduirea este adesea supraevaluată în privința Core Web Vitals. TTFB este partea din ecuație pe care o deține serverul, iar stiva de memorare în cache de mai sus este cea care îl reduce — o pagină completă stocată în cache, livrată prin HTTP/3 de la edge, reprezintă cel mai scăzut nivel posibil pentru TTFB. Deoarece TTFB este punctul de plecare pentru Largest Contentful Paint, o origine rapidă oferă fiecărei metrici din aval un avantaj de pornire pe care altfel nu l-ar putea avea.
Însă LCP, CLS și INP sunt determinate în mare parte în browser, de pagina însăși: o imagine principală (hero) neoptimizată, fișiere CSS și JavaScript care blochează redarea, o structură care se deplasează pe măsură ce se încarcă fonturile și reclamele, precum și o activitate intensă pe firul principal de execuție cauzată de module. Niciun nivel de stocare în memoria cache a serverului nu rezolvă o imagine principală de 2 MB sau o temă care livrează megabiți de JavaScript. O găzduire onestă face ca aportul serverului să fie practic insesizabil și constant; mai departe, ține de site să mențină interfața grafică ușoară.
Această împărțire a sarcinilor reprezintă modelul mental util. Noi garantăm că solicitarea ajunge rapid în browser și rămâne rapidă în condiții de trafic; dumneavoastră păstrați sarcina utilă mică și stabilă. Punctul în care cele două se întâlnesc — preîncălzirea memoriei cache, livrarea edge și menținerea bazei de date receptive astfel încât paginile dinamice să nu se blocheze — este exact locul în care stiva noastră este optimizată, și este ceea ce face ca WordPress administrat pe această platformă să fie mai rapid decât același site pe o găzduire generică.
Întrebări frecvente
Mai am nevoie de un modul de stocare în memoria cache precum WP Rocket?
Nu. Memoria cache pentru pagini întregi este gestionată la nivelul serverului web de LSCache de la LiteSpeed, iar propriul nostru modul de cache — preinstalat și actualizat automat — conectează corect WordPress la acesta, având în spate un cache de obiecte Redis pentru fiecare site. Suprapunerea unui al doilea modul de cache pentru pagini întregi intră de regulă în conflict cu memoria cache de la nivelul serverului în loc să ajute, prin urmare nu este necesară și nu este recomandată.
Memorarea în cache va afecta coșul meu WooCommerce sau paginile pentru utilizatorii conectați?
Nu. Paginile cart, checkout, my-account și orice pagini de tip nonce sau session sunt excluse din cache în mod prestabilit, iar ESI menține fragmentul de coș și totalurile active pe paginile care altfel sunt stocate în cache. Cumpărătorii își văd întotdeauna propriul coș și o finalizare a comenzii funcțională, în timp ce vitrina magazinului se încarcă în continuare din cache.
Cum rămâne memoria cache actualizată atunci când public sau editez?
Golirea automată inteligentă se declanșează pe hook-urile relevante din WordPress, astfel încât publicarea, editarea conținutului sau modificarea unui produs, a unui preț sau a unei comenzi șterge doar paginile afectate și arhivele acestora — nu întreaga memorie cache — iar un crawler le reîncălzește. De asemenea, puteți efectua golirea la cerere din panoul de control sau din interiorul WordPress.
Poate doar găzduirea să îmi ofere Core Web Vitals perfecte?
Acesta vă oferă cel mai bun TTFB posibil, reprezentând contribuția serverului și un avantaj inițial pentru Largest Contentful Paint. Totuși, LCP, CLS și INP sunt determinate în mare măsură de pagina în sine — dimensiunile imaginilor, resursele care blochează randarea, stabilitatea aspectului și codul JavaScript de pe firul principal de execuție. Stiva noastră face ca aportul serverului să fie rapid și constant; menținerea unei încărcături reduse pe front-end este ceea ce acoperă restul diferenței.
Conexe
Încercați gratuit timp de 14 zile
Lansați primele dumneavoastră site-uri gratuit timp de 14 zile — fără card. Mutați o rețea existentă? Migrările sunt gratuite, fără limită.
Începeți gratuit