Pritja dhe performanca
Si e bëjmë WordPress të shpejtë: LiteSpeed Enterprise, LSCache dhe Redis për çdo faqe
Kërkesa më e shpejtë e WordPress është ajo që nuk ekzekutohet kurrë — ja se si struktura jonë i përgjigjet shumicës së vizitave nga fshehtina përpara se PHP ose MySQL të thirren ndonjëherë, dhe çfarë do të thotë kjo për Core Web Vitals.
Kërkesa më e shpejtë është ajo që nuk ekzekutohet kurrë
Një kërkesë standarde e WordPress është e kushtueshme. Serveri i uebit ia kalon detyrën PHP-së, PHP nis WordPress, ekzekuton shtojcat, bën disa dhjetëra pyetje në MySQL, monton HTML-në dhe vetëm atëherë kthen bajtët. Në një sajt të ngarkuar, i gjithë ky proces ndodh për çdo vizitor, dhe këtu shkon pothuajse i gjithë time-to-first-byte juaj.
Përgjigja jonë është të sigurohemi që, për shumicën e vizitave, asgjë nga këto të mos ndodhë fare. Në të gjitha faqet që ne presim — mbi 100,000 faqe PBN plus faqet kryesore të menaxhuara WordPress — shumica dërrmuese e shikimeve të faqeve në front-end shërbehen si një faqe e plotë e para-renditur drejtpërdrejt nga memoria e fshehtë, pa thirrur PHP ose pa prekur bazën e të dhënave. Pjesa e mbetur e këtij shkrimi flet për mënyrën se si bashkërendohen shtresat që e bëjnë këtë të mundur, dhe arsyen pse secila prej tyre e meriton vendin e saj.
Kornizimi i rëndësishëm është se këto nuk janë memorie të fshehta konkurruese midis të cilave duhet të zgjidhni. Memoria e fshehtë e faqes së plotë, ajo e objekteve dhe skaji CDN kapin secila një kategori të ndryshme kërkesash, dhe vlera qëndron në mënyrën se si ato bashkëveprojnë dhe ia kalojnë punën njëra-tjetrës.
LiteSpeed Enterprise + LSCache: shtresa e faqes së plotë
Çdo faqe funksionon në LiteSpeed Enterprise me LSCache në nivel serveri. Kur një përgjigje e ballinës mund të ruhet në fshehtinë, serveri i uebit e pajis atë me tituj etiketash dhe kontrolli fshehtine të LiteSpeed, dhe LiteSpeed e ofron faqen e plotë drejtpërdrejt në kërkesën tjetër — pa u hapur asnjë proces PHP, pa u ekzekutuar asnjë pyetësor MySQL. Kjo është leva më e madhe e vetme mbi TTFB-në e WordPress, sepse heq plotësisht ngarkimin e aplikacionit nga rruga kritike.
Meqenëse LSCache funksionon brenda serverit të uebit dhe jo në një shtojcë PHP, ajo fillon të punojë më herët në ciklin e jetës së kërkesës dhe i mban faqet në një formë që serveri mund ta pastrojë menjëherë. Një zvarritës i memories së fshehtë i mban faqet e njohura të ngrohta, kështu që vizitori i parë pas një fshirjeje nuk është ai që përballon rigjenerimin e faqes. Rezultati është një TTFB dukshëm më i ulët dhe më i qëndrueshëm sesa një memorie e fshehtë vetëm me shtojcë e vendosur mbi një strukturë të zakonshme, ku memoria e fshehtë qëndron ende pas PHP-së.
Shtojca jonë e memories së fshehtë e nivelit të depove vjen e para-instaluar dhe përditësohet automatikisht në çdo faqe, duke lidhur saktë WordPress me LSCache që në fillim. Në një server që nuk është LiteSpeed, thjesht nuk lëshon tituj për faqe të plota dhe nuk ndërhyn, ndërsa memoria e fshehtë e objekteve dhe rregullat e përjashtimit vazhdojnë punën e tyre — kështu që një faqe e migruar nuk lihet kurrë në një gjendje të dëmtuar apo të konfiguruar përgjysmë.
Të qëndruarit e shpejtë pa shërbyer përmbajtje të vjetruar: ESI dhe spastrim automatik inteligjent
Ruajtja agresive e të gjithë faqes në memorien e përkohshme ka dy mënyra klasike dështimi: shfaqja e faqes së dikujt tjetër për një përdorues të kyçur, dhe shfaqja për këdo e një faqeje që duhej të kishte ndryshuar. Të dyja zgjidhen në shtresën e memories së përkohshme dhe jo duke ruajtur më pak në memorie.
ESI (Edge Side Includes) na lejon të ruajmë faqen në memorien e përkohshme ndërkohë që hap hapësira për pjesët që duhet të mbeten të drejtpërdrejta. Në një dyqan WooCommerce, faqet e katalogut, produkteve dhe kategorive shërbehen si faqe e plotë në memorien e përkohshme për TTFB-në më të shpejtë të mundshme, ndërsa ESI gjeneron fragmentin e shportës, shumat e mini-shportës dhe gjendjen e llogarisë për çdo kërkesë. Shporta, pagesa, llogaria ime dhe çdo faqe nonce ose sesioni përjashtohen si parazgjedhje. Blerësit shohin gjithmonë shportën e tyre dhe një proces pagese funksional; të gjithë marrin ende ballinën e dyqanit nga memoria e përkohshme.
Freskia menaxhohet përmes pastrimit automatik inteligjent. Grepat e pastrimit aktivizohen automatikisht kur ndryshojnë përmbajtja, produktet, çmimet ose porositë, në mënyrë që faqet përkatëse të ruajtura në memorien e përkohshme të rifreskohen menjëherë dhe jo sipas një kohëmatësi, si dhe ju mund të pastroni sipas kërkesës nga paneli i kontrollit ose nga brenda WordPress. Pastrimi i bazuar në etiketa do të thotë se modifikimi i një postimi pastron atë postim dhe arkivat e tij — jo të gjithë memorien e përkohshme — kështu që një modifikim i vetëm nuk e rinis nga e para të gjithë faqen.
Fshehina e objekteve Redis për çdo faqe: për atë që nuk mund të jetë një faqe e plotë
Jo çdo kërkesë mund të jetë një faqe e plotë statike. Sesionet e kyçura, paneli i administrimit të WordPress, shportat e WooCommerce, kërkimi dhe fragmentet dinamike që ESI lë aktive, të gjitha duhet të ekzekutojnë PHP. Për këto, qëllimi zhvendoset nga 'kapërceni aplikacionin' në 'kapërceni bazën e të dhënave'.
Çdo faqe merr memorjen e saj të dedikuar të objekteve Redis. WordPress ruan në memorie rezultatet e leximit të përsëritur të bazës së të dhënave — opsionet, transients, kërkimet e postimeve dhe termave, të dhënat e produkteve dhe sesioneve të WooCommerce — në mënyrë që i njëjti pyetësor të mos ekzekutohet në MySQL për çdo vizitë. Efekti është më i dukshëm pikërisht aty ku memorja e të gjithë faqes nuk mund të ndihmojë: panele kontrolli më të shpejta, shporta më të shpejta dhe një ngarkesë shumë më e ulët në bazën e të dhënave në kushte trafiku të rënduar.
Kashimi i objekteve bëhet për çdo faqe dhe nuk ndahet, gjë që ka rëndësi si për performancën, ashtu edhe për izolimin. I kombinuar me kufizimin e bazës së të dhënave për çdo faqe, kërkesat e rënda ose të shkruara keq të një faqeje nuk mund të privojnë bazën e të dhënave për fqinjët e saj. Mund të lexoni më shumë rreth mënyrës se si funksionon i gjithë konfigurimi me shumë nivele në faqen tonë të veçorive të kashimit, si dhe rreth kufijve midis qiramarrësve nën izolim.
Skaji dhe transporti poshtë tij
Kash-i që gjendet në serverin bazë (origin) duhet gjithsesi të përshkojë rrjetin. Përpara serverit qëndron skaji i CDN-së, kështu që asetet statike dhe faqet e kashueshme shërbehen nga një pikë prezence afër vizitorit, dhe serveri bazë mbetet i qetë edhe nën ngarkesë. Për linjën tonë të hostimit pa gjurmë (footprint-free), i njëjti skaj është një grup multi-CDN i shpërndarë në disa ofrues, i cili i shërben një qëllimi të fshehjes së gjurmëve (footprint) si dhe një qëllimi performance; në WordPress-in e zakonshëm, ai është thjesht një shtresë e shpejtë dhe e rregullt që i mban serverët bazë joaktivë.
Në brendësi, parimet themelore nuk janë lënë pas dore. Faqet funksionojnë në hapësirë ruajtëse NVMe me HTTP/3, kështu që bajtat që dërgon memoria e përkohshme mbërrijnë përmes një transporti modern dhe të shumëfishtë (multiplexed), me hapësirë të shpejtë ruajtëse pas çdo mungese në memorie (cache miss). Asnjë nga këto shtresa nuk është një shtesë me pagesë: LiteSpeed, LSCache, Redis për çdo faqe, NVMe dhe HTTP/3 janë standardi bazë në çdo paketë, jo një nivel për shitje më të shtrenjtë.
Çfarë ndikon vërtet te Core Web Vitals
Ia vlen të jemi të saktë, sepse hostimi shpesh mbivlerësohet për sa u përket Core Web Vitals. TTFB është pjesa e ekuacionit që zotëron serveri, dhe stogu i ruajtjes së përkohshme më lart është ai që e ul atë — një faqe e plotë e ruajtur në cache, e shërbyer përmes HTTP/3 nga skaji (edge), është përafërsisht aq e ulët sa mund të arrijë TTFB. Meqenëse TTFB është skaji kryesor i Largest Contentful Paint, një origjinë e shpejtë i jep çdo metriku të mëpasshëm një përparësi fillestare që përndryshe nuk mund ta kishte.
Por LCP, CLS dhe INP vendosen kryesisht në shfletues, nga vetë faqja: një imazh kryesor (hero) i paoptimizuar, CSS dhe JavaScript që bllokojnë pasqyrimin, faqosje që lëviz ndërsa ngarkohen shkronjat dhe reklamat, si dhe ngarkesë e rëndë në procesin kryesor nga shtojcat. Asnjë sasi e ruajtjes në memorien e përkohshme (cache) të serverit nuk e rregullon një imazh kryesor prej 2 MB ose një temë që dërgon megabajt të tërë JavaScript. Një shërbim pritës (hosting) i ndershëm e bën kontributin e serverit efektivisht pa kosto dhe të qëndrueshëm, më pas i takon vetë faqes që ta mbajë pjesën e përparme (front end) sa më të lehtë.
Kjo ndarje e punës është modeli mendor i dobishëm. Ne garantojmë që kërkesa të mbërrijë shpejt në shfletues dhe të mbetet e shpejtë nën trafik; ju e mbani ngarkesën të vogël dhe të qëndrueshme. Aty ku takohen të dyja — ngrohja e fshehjes së përkohshme, dërgimi në skaj dhe mbajtja e bazës së të dhënave reaguese në mënyrë që faqet dinamike të mos ngecin — është pikërisht vendi ku stogu ynë është përshtatur, dhe është ajo që e bën WordPress të menaxhuar në këtë platformë më të shpejtë se e njëjta faqe në një pritës të përgjithshëm.
Pyetjet e shpeshta
A më duhet ende një shtojcë për ruajtjen në fshehtinë si WP Rocket?
Jo. Ruajtja e plotë e faqeve në memorien e përkohshme menaxhohet në serverin e uebit nga LSCache i LiteSpeed-it, dhe shtojca jonë e memories së përkohshme — e parainstaluar dhe e përditësuar automatikisht — e lidh saktësisht WordPress-in me të, me një memorie objekti Redis për çdo faqe në prapaskenë. Shtimi i një shtojce të dytë për ruajtjen e faqeve të plota zakonisht bie ndesh me memorien e përkohshme në nivel serveri në vend që të ndihmojë, prandaj nuk është e nevojshme dhe nuk rekomandohet.
A do ta prishë ruajtja e përkohshme shportën time të WooCommerce ose faqet me hyrje të kryer?
Jo. Faqet cart, checkout, my-account dhe çdo faqe nonce ose session përjashtohen nga memorja e përkohshme (cache) si parazgjedhje, dhe ESI e mban fragmentin e shportës dhe shumat totale aktive në faqet që përndryshe ruhen në memorje. Blerësit shohin gjithmonë shportën e tyre dhe një proces pagese funksional, ndërkohë që fasada e dyqanit vijon të ngarkohet nga memorja e përkohshme.
Si mbetet e freskët memoria e fshehtë kur publikoj ose redaktoj?
Pastrimi automatik inteligjent aktivizohet në grepat përkatës të WordPress, kështu që publikimi, modifikimi i përmbajtjes ose ndryshimi i një produkti, çmimi apo porosie pastron vetëm faqet e prekura dhe arkivat e tyre — jo të gjithë memorien e përkohshme — dhe një zvarritës i ngroh ato përsëri. Ju gjithashtu mund të pastroni sipas kërkesës nga paneli i kontrollit ose nga brenda WordPress.
A mund të më japë vetëm hostimi Core Web Vitals të përsosura?
Kjo ju jep TTFB-në më të mirë të mundshme, e cila është pjesa e serverit dhe një avantazh fillestar për Largest Contentful Paint. Por LCP, CLS dhe INP përcaktohen kryesisht nga vetë faqja — përmasat e imazheve, burimet që bllokojnë interpretimin, qëndrueshmëria e paraqitjes dhe JavaScript-i i procesit kryesor. Paketa jonë e bën kontributin e serverit të shpejtë dhe të qëndrueshëm; mbajtja e ngarkesës së front-end-it sa më të lehtë është ajo që mbyll pjesën tjetër të hendekut.
Të ngjashme
Provojeni falas për 14 ditë
Aktivizoni faqet tuaja të para falas për 14 ditë — pa kartë. Po transferoni një rrjet ekzistues? Migrimet janë falas, pa asnjë kufizim.
Filloni falas