Găzduire și performanță
Cum facem ca WordPress să fie rapid: LiteSpeed Enterprise, LSCache și Redis per site
Cea mai rapidă cerere WordPress este cea care nu rulează niciodată – iată cum stiva noastră răspunde la majoritatea vizitelor din cache înainte ca PHP sau MySQL să fie apelate vreodată și ce înseamnă asta pentru Core Web Vitals.
Cea mai rapidă cerere este cea care nu rulează niciodată
O solicitare standard WordPress este costisitoare. Serverul Web predă controlul către PHP, PHP pornește 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 dans are loc pentru fiecare vizitator și reprezintă momentul în care se consumă aproape tot timpul până la primul octet (time-to-first-byte).
Soluția noastră este să ne asigurăm că, pentru cele mai multe vizite, nimic din toate acestea nu se întâmplă. Pe site-urile pe care le găzduim — peste 100.000 de site-uri PBN, plus servicii uzuale WordPress administrat — marea majoritate a vizualizărilor de pagini front-end sunt livrate ca pagini complete pre-randate direct din memoria cache, fără a rula PHP sau a accesa baza de date. Restul acestei postări descrie modul în care straturile care fac acest lucru posibil se îmbină și unde își merită locul fiecare.
Cadrul important este că acestea nu sunt cache-uri concurențiale între care să alegi. Cache-ul de pagină întreagă, cache-ul de obiecte și marginea CDN interceptează fiecare o altă clasă de cereri, iar valoarea constă în modul în care se predau ștafeta una alteia.
LiteSpeed Enterprise + LSCache: stratul pentru pagini complete
Fiecare site rulează pe LiteSpeed Enterprise cu LSCache la nivel de server. Când un răspuns front-end poate fi cache-uit, serverul web îl marchează cu anteturi de control al cache-ului și etichete LiteSpeed, iar LiteSpeed servește pagina completă direct la următoarea accesare — fără proces PHP inițiat, fără interogare MySQL emisă. Aceasta este cea mai importantă pârghie pentru WordPress TTFB, deoarece elimină întreaga pornire a aplicației din calea critică.
Deoarece LSCache funcționează în interiorul serverului web, și nu într-un plugin PHP, acesta începe să acționeze mai devreme în ciclului cererii și stochează paginile într-o formă pe care serverul o poate trimite instantaneu. Un crawler de cache menține paginile populare active, astfel încât primul vizitator de după o golire a cache-ului nu este cel care suportă timpul de regenerare a paginii. Rezultatul este un TTFB vizibil mai mic și mai consistent decât în cazul unui cache bazat exclusiv pe un plugin adăugat peste o stivă generică, unde cache-ul se află tot în spatele PHP-ului.
Modulul nostru de cache de nivel repo vine preinstalat și actualizat automat pe fiecare site, conectând WordPress la LSCache corect, din cutie. Pe o origine non-LiteSpeed, acesta pur și simplu nu emite anteturi pentru pagina întreagă și se dă la o parte, în timp ce cache-ul de obiecte și regulile de excludere își continuă treaba — astfel încât un site migrat nu este lăsat niciodată într-o stare defectuoasă și jumătate configurată.
Rămâi rapid fără a servi conținutvechi: ESI și auto-golirea inteligentă
Cachingul agresiv pentru întreaga pagină are două moduri clasice de eșec: servirea paginii altcuiva unui utilizator autentificat și servirea oricărei persoane a unei pagini care ar fi trebuit să se modifice. Ambele sunt rezolvate la nivelul de caching, în loc să se facă un caching mai redus.
ESI (Edge Side Includes) ne permite să cache-uim pagina în timp ce lăsăm goluri pentru părțile care trebuie să rămână dinamice. Pe un magazin WooCommerce, paginile de catalog, de produs și de categorie sunt servite ca și cache de pagină completă pentru cel mai rapid TTFB posibil, în timp ce ESI randează fragmentul coșului, totalurile din mini-coș și starea contului per cerere. Coșul, finalizarea comenzii, contul meu și orice pagini cu nonce sau de sesiune sunt excluse în mod implicit. Cumpărătorii își vad întotdeauna propriul coș și o pagină funcțională de finalizare a comenzii; toată lumea primește în continuare magazinul din cache.
Prospețimea este gestionată de auto-curățarea inteligentă. Declanșatoarele de curățare rulează automat atunci când conținutul, produsele, prețurile sau comenzile se modifică, astfel încât paginile stocate în cache relevante se reîmprospătează imediat și nu pe bază de cronometru, iar dumneavoastră puteți curăța și la cerere din panoul de control sau din interiorul WordPress. Curățarea bazată pe etichete înseamnă că editarea unei postări șterge acea postare și arhivele sale — nu întregul cache — astfel încât o singură editare nu repornește de la zero întregul site.
Cache de obiecte Redis per site: pentru ceea ce nu poate fi o pagină completă
Nu orice cerere poate fi o pagină complet statică. Sesiunile autentificate, panoul de administrare WordPress, coșurile WooCommerce, căutarea și fragmentele dinamice lăsate de ESI trebuie să ruleze PHP. Pentru acestea, obiectivul se schimbă de la „sărirea peste aplicație” la „sărirea peste baza de date”.
Fiecare site are propriul său cache de obiecte Redis dedicat. WordPress stochează în memorie rezultatele citirilor repetate din baza de date — opțiuni, tranzitorii, 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 cache-ul de pagină întreagă nu poate ajuta: panouri de control mai rapide, coșuri mai rapide și o sarcină mult mai mică asupra bazei de date în timpul traficului.
Cache-ul de obiecte este per site, nu partajat, ceea ce contează atât pentru performanță, cât și pentru izolare. Combinat cu limitarea resurselor bazei de date per site, interogările grele sau prost scrise ale unui singur site nu pot epuiza baza de date pentru site-urile vecine. Poți citi mai multe despre cum se îmbină întreaga configurare multicstrat pe pagina noastră cu funcționalități de caching și despre limitele dintre chiriași în secțiunea dedicată izolării.
Marginea și transportul de dedesubt
Cache-ul care se află pe serverul de origin trebuie totuși să traverseze rețeaua. În fața serverului se află nodul periferic al CDN-ului, astfel încât resursele statice și paginile care pot fi salvate în cache sunt livrate dintr-un punct de prezență apropiat vizitatorului, iar serverul de origin rămâne liber chiar și în condiții de trafic intens. Pentru gama noastră de găzduire fără footprint, același nod periferic reprezintă un grup multi-CDN distribuit între mai mulți furnizori, care servește atât un obiectiv legat de footprint, cât și unul de performanță; pe WordPress clasic, este pur și simplu un strat rapid și eficient care menține serverele de origin inactive.
Dedesubt, elementele fundamentale nu sunt tratate superficial. Site-urile rulează pe stocare NVMe cu HTTP/3, astfel încât octeții trimiși de cache sosesc printr-un transport modern, multiplexat, cu o stocare rapidă în spatele oricărei ratări a cache-ului. Niciunul dintre aceste niveluri nu este un supliment: LiteSpeed, LSCache, Redis per site, NVMe și HTTP/3 reprezintă baza pentru fiecare plan, nu o treaptă superioară contra cost.
Ce influențează de fapt Core Web Vitals
Merită să fim preciși, deoarece găzduirea web este adesea supraestimată în ceea ce privește Core Web Vitals. TTFB este partea din ecuație de care serverul este responsabil, iar stiva de caching de deasupra este cea care îl reduce — o pagină completă în cache livrată prin HTTP/3 de la edge reprezintă cel mai scăzut nivel pe care îl poate atinge TTFB. Deoarece TTFB este elementul principal pentru Largest Contentful Paint, o origine rapidă oferă fiecărui metric subsecvent un avans pe care altfel nu l-ar putea avea.
Dar LCP, CLS și INP sunt decise în mare parte în browser, de însăși pagina: o imagine principală neoptimizată, CSS și JavaScript care blochează randarea, un layout care se deplasează pe măsură ce fonturile și reclamele se încarcă, și multă muncă pe firul principal din partea pluginurilor. Nicio cantitate de cache pe server nu repară o imagine principală de 2 MB sau o temă care livrează megabiți de JavaScript. O găzduire onestă face ca contribuția serverului să fie practic gratuită și constantă, iar apoi revine site-ului sarcina de a menține interfața optimizată.
Această diviziune a muncii este un model mental util. Noi garantăm că cererea ajunge rapid la browser și rămâne rapidă în condiții de trafic; tu menții conținutul mic și stabil. Exact acolo unde cele două se întâlnesc — preîncălzirea cache-ului, livrarea la nivel de edge și menținerea bazei de date receptive, astfel încât paginile dinamice să nu se blocheze — este optimizată stiva noastră și tocmai acest lucru face ca soluția 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 cache precum WP Rocket?
Nu.Caching-ul pentru pagina întreagă este gestionat la nivelul serverului web de LSCache de la LiteSpeed, iar propriul nostru plugin de cache — preinstalat și actualizat automat — conectează corect WordPress la acesta, având în spate un cache de obiecte Redis per site. Instalarea unui al doilea plugin de cache pentru pagina întreagă intră de obicei în conflict cu cache-ul de la nivelul serverului, în loc să ajute, așa că nu este necesar și nu este recomandat.
Va strica cache-ul coșul meu WooCommerce sau paginile pentru utilizatorii conectați?
Nu. Coșul, casa, contul meu și orice pagini cu nonce sau de sesiune sunt excluse din cache în mod implicit, iar ESI menține fragmentul coșului și totalurile active pe paginile care altfel ar fi memorate în cache. Cumpărătorii își văd întotdeauna propriul coș și o pagină de finalizare a comenzii funcțională, în timp ce vitrina magazinului se încarcă în continuare din cache.
Cum rămâne cache-ul actualizat când public sau editez?
Curățarea automată inteligentă se declanșează pe hook-urile relevante din WordPress, astfel încât publicarea, editarea conținutului sau modificarea unui produs, preț sau comandă șterge doar paginile afectate și arhivele lor — nu întregul cache — iar un crawler le reîncălzește. De asemenea, puteți efectua o curățare la cerere din panoul de control sau din interiorul WordPress.
Poate găzduirea singură să îmi ofere Core Web Vitals perfecte?
Îți oferă cel mai bun TTFB posibil, care reprezintă contribuția serverului și un avans pentru Largest Contentful Paint. Însă LCP, CLS și INP sunt determinate în mare parte de însăși pagina web — dimensiunile imaginilor, resursele care blochează randarea, stabilitatea layoutului și JavaScript-ul de pe firul principal de execuție. Stiva noastră face ca aportul serverului să fie rapid și stabil; menținerea unui payload front-end redus este ceea ce acoperă restul diferenței.
Aferente
Încearcă gratuit timp de 14 zile
Lansează primele tale site-uri gratuit timp de 14 zile — fără card. Muți o rețea existentă? Prima ta migrare este din partea noastră.
Începe gratuit