Hosting i performanse
Kako ubrzavamo WordPress: LiteSpeed Enterprise, LSCache i Redis po web-mjestu
Najbrži WordPress zahtjev je onaj koji se nikada ne izvrši — evo kako naš stog odgovara na većinu posjeta iz predmemorije prije nego što se PHP ili MySQL uopće pokrenu, i što to znači za Core Web Vitals.
Najbrži zahtjev je onaj koji se nikad ne izvrši
Standardni WordPress zahtjev je skup. Web poslužitelj ga predaje PHP-u, PHP pokreće WordPress, pokreće dodatke, desetak puta upućuje upite prema MySQL-u, sastavlja HTML i tek tada šalje bajtove natrag. Na opterećenoj stranici cijeli se taj postupak odvija za svakog posjetitelja, i upravo na to odlazi gotovo cijelo vrijeme do prvog bajta.
Naš je odgovor osigurati da se za većinu posjeta ništa od toga uopće ne dogodi. Na stranicama koje udomljavamo — preko 100.000 PBN stranica plus glavnog upravljanog WordPress — velika većina prikaza stranica na sučelju poslužuje se kao unaprijed izrađena cijela stranica izravno iz predmemorije, bez pozivanja PHP-a ili dodirivanja baze podataka. Ostatak ovog posta govori o tome kako se slojevi koji to omogućuju uklapaju zajedno i gdje svaki od njih zaslužuje svoje mjesto.
Važno je shvatiti da to nisu konkurentski predmemorijski sustavi između kojih morate birati. Predmemorija cijele stranice, predmemorija objekata i CDN rubni poslužitelj hvataju različitu vrstu zahtjeva, a vrijednost je u načinu na koji se međusobno nadovezuju.
LiteSpeed Enterprise + LSCache: sloj cijele stranice
Svaka stranica radi na LiteSpeed Enterprise poslužitelju s LSCache-om na razini poslužitelja. Kada je odziv sučelja moguće predmemorirati, web-poslužitelj ga označava zaglavljima LiteSpeed cache-control i tag, a LiteSpeed poslužuje cijelu stranicu izravno pri sljedećem zahtjevu – bez pokretanja PHP procesa i bez izvršavanja MySQL upita. To je najveća poluga za WordPress TTFB jer uklanja cijelo pokretanje aplikacije iz kritičnog puta.
Budući da LSCache živi unutar web poslužitelja, a ne u PHP dodatku, počinje raditi ranije u ciklusu zahtjeva i pohranjuje stranice u obliku koji poslužitelj može trenutno izbaciti. Puzalica predmemorije održava popularne stranice toplima, tako da prvi posjetitelj nakon čišćenja nije taj koji plaća ponovno generiranje stranice. Rezultat je znatno niži i dosljedniji TTFB nego kod predmemorije koja se temelji samo na dodatku i pridodana je općoj stogovnoj arhitekturi, gdje predmemorija i dalje stoji iza PHP-a.
Naš vlastiti predmemorijski dodatak razine repozitorija dolazi unaprijed instaliran i automatski se ažurira na svakoj web-lokaciji, ispravno povezujući WordPress s LSCache iz kutije. Na poslužitelju koji nije LiteSpeed jednostavno ne šalje zaglavlja cijele stranice i miče se s puta, dok predmemorija objekata i pravila izuzeća nastavljaju obavljati svoj posao – tako da migrirana web-lokacija nikada ne ostaje u pokvarenom, polukonfiguriranom stanju.
Ostati brz bez posluživanja zastarjelog: ESI i pametno automatsko čišćenje
Agresivno predmemoriranje cijele stranice ima dva klasična načina zatajenja: posluživanje stranice nekog drugog prijavljenom korisniku i posluživanje stranice koja se trebala promijeniti bilo kome. Oba se problema rješavaju na sloju predmemoriranja umjesto manjim predmemoriranjem.
ESI (Edge Side Includes) omogućuje nam predmemoriranje stranice uz ostavljanje praznina za dijelove koji moraju ostati aktivni. Na WooCommerce trgovini katalog, stranice proizvoda i kategorija poslužuju se iz predmemorije cijele stranice radi najbržeg mogućeg TTFB-a, dok ESI iscrtava ulomak košarice, ukupne iznose mini košarice i stanje računa po zahtjevu. Košarica, naplata, moj račun i sve stranice s noncevima ili sesijama isključeni su prema zadanim postavkama. Kupci uvijek vide svoju košaricu i funkcionalnu naplatu, a svi ostali i dalje dobivaju vitrinu iz predmemorije.
Svježina se održava pametnim automatskim čišćenjem. Kuke za čišćenje aktiviraju se automatski kada se promijene sadržaj, proizvodi, cijene ili narudžbe, tako da se relevantne predmemorirane stranice osvježavaju odmah, a ne prema mjeraču vremena, a čišćenje možete pokrenuti i ručno s nadzorne ploče ili iz sustava WordPress. Čišćenje na temelju oznaka znači da uređivanje jednog posta briše taj post i njegove arhive – ne cijelu predmemoriju – tako da jedno uređivanje ne pokreće cijelu web-lokaciju iznova.
Redis objektna predmemorija po web-mjestu: za ono što ne može biti cijela stranica
Nije svaki zahtjev statična cijela stranica. Prijavljene sesije, WordPress admin, WooCommerce košarice, pretraživanje i dinamički fragmenti koje ESI ostavlja aktivnima – sve to mora pokretati PHP. Za njih se cilj pomiče s „preskoči aplikaciju” na „preskoči bazu podataka”.
Svaka web-stranica dobiva vlastiti namjenski Redis objektni predmemorijski spremnik. WordPress predmemorira rezultate ponovljenih čitanja baze podataka – opcije, prijelazne podatke, pretraživanja objava i pojmova, WooCommerce podatke o proizvodima i sesijama – u memoriji, tako da se isti upit ne izvršava nad MySQL-om pri svakom zahtjevu. Učinak je najvidljiviji upravo tamo gdje predmemoriranje cijelih stranica ne može pomoći: brže nadzorne ploče, brže košarice i znatno manji utovarni zahtjevi na bazu podataka pod prometom.
Predmemorija objekata je po stranici, nije dijeljena, što je važno i za performanse i za izolaciju. U kombinaciji s ograničavanjem propusnosti baze podataka po stranici, teški ili loše napisani upiti jedne stranice ne mogu iscrpiti bazu podataka za njezine susjede. Više o tome kako se cijela višeslojna postava uklapa možete pročitati na našoj stranici s značajkama predmemoriranja, te o granicama između stanara pod izolacijom.
Rub i temeljni prijenos
Predmemorij koji se nalazi na izvorištu još uvijek mora prijeći mrežu. Ispred poslužitelja nalazi se CDN rub, tako da se statički resursi i stranice pogodne za predmemoriranje poslužuju s točke prisutnosti blizu posjetitelja, a izvorište ostaje mirno čak i pod opterećenjem. Za našu liniju hostinga bez tragova isti rub je multi-CDN skup raspoređen na nekoliko pružatelja usluga, koji služi cilju SEO traga, kao i cilju performansi; na uobičajenom WordPress to je jednostavno brz, dobro usklađen sloj koji održava izvorišta neaktivnima.
Ispod toga, na osnovnim se stvarima ne štedi. Web-mjesta rade na NVMe pohrani uz HTTP/3, tako da bajtovi koje predmemorija doista pošalje stižu putem modernog, multipleksiranog prijenosa s brzom pohranom iza svakog promašaja predmemorije. Nijedan od tih slojeva nije dodatak: LiteSpeed, LSCache, Redis po web-mjestu, NVMe i HTTP/3 predstavljaju osnovnu ponudu na svakom paketu, a ne višu tarifu koja se dodatno naplaćuje.
Što zapravo pokreće Core Web Vitals
Isplati se biti precizan jer se hosting često preprodaje na temelju metrike Core Web Vitals. TTFB je dio jednadžbe koji je u nadležnosti poslužitelja, a sloj za predmemoriju iznad njega je ono što ga smanjuje – predmemorirana cijela stranica poslužena preko protokola HTTP/3 s rubne lokacije otprilike je onoliko niska koliko TTFB može biti. Budući da je TTFB početni dio metrike Largest Contentful Paint, brzi izvorišni poslužitelj daje svakoj naknadnoj metrici prednost koju inače ne može imati.
Ali LCP, CLS i INP uglavnom se rješavaju u pregledniku, od strane same stranice: neoptimizirana uvodna slika, CSS i JavaScript koji blokiraju prikaz, izgled koji se pomiče kako se učitavaju fontovi i oglasi te težak rad glavne dretve iz dodataka. Nikakva količina poslužiteljskog predmemoriranja ne može popraviti uvodnu sliku od 2 MB ili temu koja isporučuje megabajte JavaScripta. Iskreno hosting rješenje čini doprinos poslužitelja praktično besplatnim i dosljednim, a na samoj je web-lokaciji da prednji kraj održi laganim.
Ta podjela rada je koristan mentalni model. Jamčimo da zahtjev brzo stiže do preglednika i ostaje brz pod opterećenjem; vi držite sadržaj malim i stabilnim. Mjesto gdje se to dvoje susreće — predzagrijavanje predmemorije, isporuka na rubnoj mreži i održavanje baze podataka brzom kako dinamičke stranice ne bi zastale — upravo je ono na čemu je naš stog prilagođen, i to je ono što upravljani WordPress na ovoj platformi čini bržim od iste web-lokacije na običnom poslužitelju.
Često postavljana pitanja
Trebam li i dalje dodatak za predmemoriranje poput WP Rocketa?
Ne. Predmemoriranje cijelih stranica na web-poslužitelju obavlja LiteSpeedov LSCache, dok naš vlastiti dodatak za predmemoriju – unaprijed instaliran i automatski ažuriran – ispravno povezuje WordPress s njim, uz predmemoriju objekata Redis po web-mjestu u pozadini. Stavljanje drugog dodatka za predmemoriju cijelih stranica obično stvara sukob s predmemorijom na razini poslužitelja umjesto da pomaže, stoga nije potrebno niti se preporučuje.
Hoće li predmemoriranje pokvariti moju WooCommerce košaricu ili stranice za prijavljene korisnike?
Ne. Košarica, naplata, moj-račun i sve stranice s jednokratnim brojevima (nonce) ili sesijama prema zadanim su postavkama izuzete iz predmemorije, a ESI održava ulomak košarice i ukupne iznose aktivnima na stranicama koje se inače predmemoriraju. Kupci uvijek vide svoju košaricu i funkcionalnu naplatu dok se izlog trgovine i dalje učitava iz predmemorije.
Kako predmemorija ostaje svježa kada objavljujem ili uređujem?
Pametno automatsko čišćenje pokreće se na relevantnim WordPress kukama, tako da objavljivanje, uređivanje sadržaja ili promjena proizvoda, cijene ili narudžbe briše samo pogođene stranice i njihove arhive – ne cijelu predmemoriju – a pretraživač ih ponovno zagrijava. Također možete obrisati podatke na zahtjev s nadzorne ploče ili unutar WordPress-a.
Može li samo hosting osigurati savršene Core Web Vitals?
Pruža vam najbolji mogući TTFB, koji predstavlja udio poslužitelja i prednost za Largest Contentful Paint. No, LCP, CLS i INP uvelike ovise o samoj stranici — veličinama slika, resursima koji blokiraju vykrivanje, stabilnosti izgleda i JavaScriptu glavne niti. Naš stog čini doprinos poslužitelja brzim i dosljednim; održavanje front-end paketa laganim ono je što zatvara preostali jaz.
Povezano
Isprobajte besplatno 14 dana
Pokrenite svoje prve web-lokacije besplatno na 14 dana — bez kartice. Selite postojeću mrežu? Vaša prva migracija je na naš trošak.
Započni besplatno