Hosting dhe performanca
Si e bëjmë WordPress të shpejtë: LiteSpeed Enterprise, LSCache dhe Redis për çdo sajt
Kërkesa më e shpejtë e WordPress është ajo që nuk ekzekutohet kurrë – ja se si steku ynë u përgjigjet shumicës së vizitave nga cache para se të thirret PHP ose MySQL, 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. Ueb-serveri ia kalon drejtimin PHP-së, PHP-ja nis WordPress-in, ekzekuton shtojcat, bën pyetje në MySQL disa dhjetëra herë, ndërton HTML-në dhe vetëm atëherë dërgon bajtet mbrapsht. Në një faqe të ngarkuar, i gjithë ky proces ndodh për çdo vizitor dhe aty shkon pothuajse i gjithë koha juaj deri te bajti i parë (time-to-first-byte).
Përgjigjja jonë është të sigurohemi që, për shumicën e vizitave, asnjëra prej tyre të mos ndodhë fare. Në të gjithë faqet që strehojmë — mbi 100,000 faqe PBN plus WordPress të menaxhuar kryesor — pjesa dërrmuese e shikimeve të faqeve të front-end-it shërbehen si një faqe e plotë e parapërgatitur direkt nga cache-i, pa thirrur PHP ose pa prekur databazën. Pjesa tjetër e këtij postimi ka të bëjë me mënyrën se si shtresat që e bëjnë këtë të vërtetë përshtaten me njëra-tjetrën, dhe se ku secila prej tyre fiton vendin e saj.
Korniza e rëndësishme është se këto nuk janë cache konkurruese mes të cilave duhet të zgjidhni. Cache i faqes së plotë, cache i objektit dhe skaji i CDN-së trajtojnë secili një klasë të ndryshme kërkesash, dhe vlera qëndron në mënyrën se si ato ia kalojnë punën njëri-tjetrit.
LiteSpeed Enterprise + LSCache: shtresa e faqes së plotë
Çdo sajt funksionon në LiteSpeed Enterprise me LSCache në nivel serveri. Kur një përgjigje e front-end është e memorizueshme në cache, ueb serveri e vulos atë me kokërgësitë e kontrollit të cache dhe të etiketave të LiteSpeed, dhe LiteSpeed e shërben faqen e plotë direkt në goditjen e radhës — pa asnjë proces PHP të nisur dhe pa asnjë pyetje MySQL të lëshuar. Ky është leva më e madhe e vetme për WordPress TTFB, sepse heq të gjithë nisjen e aplikacionit nga rruga kryesore.
Për shkak se LSCache jeton brenda serverit të uebit dhe jo në një shtojcë PHP, ai fillon të punojë më herët në ciklin jetësor të kërkesës dhe i mban faqet në një formë që serveri mund t'i shkarkojë menjëherë. Një skaner i cache-it i mban faqet e njohura të nxehta, kështu që vizitori i parë pas një pastrimi nuk është ai që paguan për të rigjeneruar faqen. Rezultati është një TTFB dukshëm më i ulët dhe më i qëndrueshëm se një cache vetëm me shtojcë i vendosur mbi një stack gjenerik, ku cache-i ende qëndron pas PHP-së.
Shtojca jonë e cache-it e nivelit repo vjen e para-instaluar dhe përditësohet automatikisht në çdo sajt, duke lidhur WordPress me LSCache në mënyrë korrekte që në fillim. Në një origjinë jo-LiteSpeed, ajo thjesht nuk lëshon kokëza të faqes së plotë dhe largohet, ndërsa cache-i i objekteve dhe rregullat e përjashtimit vazhdojnë të bëjnë punën e tyre — kështu që një sajt i migruar nuk mbetet kurrë në një gjendje të prishur e të konfiguruar përgjysmë.
Të qëndrosh i shpejtë pa shërbyer përmbajtje të vjetruar: ESI dhe pastrimi automatik i zgjuar
Cachingu agresiv i faqeve të plota ka dy mënyra klasike dështimi: shërbyerja e faqes së dikujt tjetër një përdoruesi të kyçur dhe shërbyerja kujtdo e një faqeje që duhet të kishte ndryshuar. Të dyja zgjidhen në shtresën e caching-ut në vend të zvogëlimit të sasisë së caching-ut.
ESI (Edge Side Includes) na lejon të ruajmë faqen në cache, duke lënë hapësira të lira për pjesët që duhet të mbeten aktive. Në një dyqan WooCommerce, faqet e katalogut, produktit dhe kategorisë shërbehen si cache e faqes së plotë për TTFB-në më të shpejtë të mundshme, ndërsa ESI-ja shfaq fragmentin e shportës, totalet e mini-shportës dhe gjendjen e llogarisë për çdo kërkesë. Shporta, arka, llogaria ime dhe çdo faqe nonce ose sesioni përjashtohen si parazgjedhje. Blerësit shohin gjithmonë shportën e tyre dhe një arkë funksionale; të gjithë përfitojnë ende faqen e dyqanit nga cache.
Freskia menaxhohet nga pastrimi automatik i zgjuar. Grepat e pastrimit aktivizohen automatikisht kur ndryshojnë përmbajtja, produktet, çmimet ose porositë, kështu që faqet e ruajtura në memorien cache përkatëse rifreskohen menjëherë në vend të një kohëmatësi, dhe ju mund t'i pastroni ato gjithashtu sipas kërkesës nga paneli i kontrollit ose brenda WordPress. Pastrimi i bazuar te etiketat do të thotë se redaktimi i një postimi pastron atë postim dhe arkivat e tij - jo të gjithë memorien cache - kështu që një redaktim i vetëm nuk e nis nga e para të gjithë faqen.
Cache i 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ë lë mënjanë ESI, të gjitha duhet të ekzekutojnë PHP. Për to, synimi kalon nga 'anashkalimi i aplikacionit' te 'anashkalimi i bazës së të dhënave'.
Çdo sajt merr memorjen e tij të dedikuar të objekteve Redis. WordPress ruan në memorie rezultatet e leximit të përsëritur të bazës së të dhënave — opsionet, tranzientët, kërkimet e postimeve dhe termave, të dhënat e produkteve dhe sesioneve të WooCommerce — në mënyrë që e njëjta pyetje të mos ekzekutohet kundër MySQL në çdo kërkesë. Efekti është më i dukshëm pikërisht aty ku memorja e cache-it të faqes së plotë nuk mund të ndihmojë: panele kontrolli më të shpejta, shporta më të shpejta dhe ngarkesë shumë më e ulët e bazës së të dhënave gjatë trafikut.
Cache-i i objekteve është për çdo sajt, jo i ndarë, 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 sajt, pyetjet e rënda ose të shkruajtura keq të një sajti nuk mund t'ia mohojnë bazën e të dhënave sajteve fqinje. Mund të lexoni më shumë se si funksionon i gjithë ky konfigurim me shumë shtresa në faqen tonë të veçorive të ruajtjes në cache, si dhe rreth kufijve midis qiramarrësve nën izolim.
Skaji dhe transporti nën të
Cache-i që ndodhet në origjinë duhet të kalojë ende përmes rrjetit. Përpara serverit ndodhet skaji i CDN-së, kështu që asetet statike dhe faqet e ruajtshme në cache shërbehen nga një pikë pranie afër vizitorit, dhe origjina mbetet e qetë edhe nën ngarkesë. Për linjën tonë të hostimit pa footprint (footprint-free), i njëjti skaj është një pishinë me shumë CDN e shpërndarë në disa ofrues, e cila shërben si për një qëllim footprint, ashtu edhe për performancë; te WordPress kryesor, ai është thjesht një shtresë e shpejtë dhe e sjellshme që i mban origjinat joaktive.
Nën to, bazat nuk janë shkelur. Faqet funksionojnë në hapësirë ruajtëse NVMe me HTTP/3, kështu që bajtet që dërgon cache mbërrijnë përmes një transporti modern, të multiplexuar, me ruajtje të shpejtë pas çdo dështimi të cache-it. Asnjë prej këtyre shtresave nuk është shtesë: LiteSpeed, LSCache, Redis për çdo faqe, NVMe dhe HTTP/3 janë baza në çdo plan, jo një nivel për shitje shtesë.
Çfarë lëviz realisht Core Web Vitals
Ia vlen të tregoheni të saktë, sepse shpesh herë shërbimet e pritjes (hosting) mbitirgohen në lidhje me Core Web Vitals. TTFB është pjesa e ekuacionit që i takon serverit, dhe steku i memories cache sipër tij është ajo që e ul atë — një faqe e plotë e ruajtur në cache e shërbyer përmes HTTP/3 nga skaji (edge) është afërsisht aq e ulët sa mund të arrijë TTFB. Për shkak se TTFB është pika kryesore e Largest Contentful Paint, një burim i shpejtë i jep çdo metrike pasuese një avantazh fillestar që nuk mund ta ketë ndryshe.
Por LCP, CLS dhe INP vendosen kryesisht në shfletues, nga vetja e faqes: një imazh kryesor i paoptimizuar, CSS dhe JavaScript që bllokojnë rregullimin, faqosja që lëviz kur ngarkohen shkronjat dhe reklamat, si dhe puna e rëndë e fijes kryesore nga shtojcat. Asnjë sasi e memorjes cache të serverit nuk mund të rregullojë një imazh kryesor prej 2 MB ose një temë që sjell megabajt me JavaScript. Pritja e ndershme në server e bën kontributin e serverit efektivisht falas dhe të qëndrueshëm, pastaj i takon faqes që ta mbajë pamjen e parë të lehtë.
Kjo ndarje e punës është modeli mendor i dobishëm. Ne garantojmë që kërkesa të arrijë 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 — nxehja e memorjes cache, dërgimi në skaj (edge delivery) dhe mbajtja e bazës së të dhënave përgjegjësuese në mënyrë që faqet dinamike të mos bllokohen — është pikërisht vendi ku staku ynë është i akorduar, dhe kjo është ajo që e bën WordPress të menaxhuar në këtë platformë më të shpejtë se e njëjta faqe në një host gjenerik.
Pyetjet e bëra më shpesh
A më duhet ende një shtojcë cache si WP Rocket?
Jo. Cache-imi i faqes së plotë trajtohet në serverin e uebit nga LSCache i LiteSpeed, dhe shtojca jonë e cache-it — e parainstaluar dhe e përditësuar automatikisht — e lidh WordPress me të siç duhet, me një object cache Redis për çdo sajt në prapavijë. Vendosja e një shtojce të dytë për cache-imin e faqes së plotë sipër saj zakonisht ndeshet me cache-in e nivelit të serverit në vend që të ndihmojë, ndaj nuk është e nevojshme dhe nuk rekomandohet.
A do ta prishë ruajtja në cache (caching) shportën time të WooCommerce ose faqet e mia të kyçura?
Jo. Shporta, arka, llogaria ime dhe çdo faqe me nonce ose sesion përjashtohen nga memorja cache si parazgjedhje, dhe ESI ruan fragmentin e shportës dhe totalet aktive në faqet e tjera që ruhen në cache. Blerësit shohin gjithmonë shportën e tyre dhe një arkë funksionale ndërkohë që vitrina e dyqanit vazhdon të ngarkohet nga cache.
Si mbetet cache-i i freskët kur publikoj ose redaktoj?
Pastrimi automatik inteligjent aktivizohet në lidhjet përkatëse të WordPress, kështu që publikimi, redaktimi i përmbajtjes, ose ndryshimi i një produkti, çmimi apo porosie pastron vetëm faqet e prekura dhe arkivat e tyre — jo të gjithë memorjen cache — dhe një crawler i ringroh ato përsëri. Ju gjithashtu mund të kryeni pastrimin sipas kërkesës nga paneli i kontrollit ose nga brenda WordPress.
A mund të më japë vetëm strehimi Core Web Vitals perfekte?
Ju jep TTFB-në më të mirë të mundshme, që është pjesa e serverit dhe një avantazh për Largest Contentful Paint. Por LCP, CLS dhe INP vendosen kryesisht nga vetë faqja — madhësitë e imazheve, burimet që bllokojnë renderimin, stabiliteti i strukturës dhe JavaScript i fijes kryesore. Steku ynë e bën kontributin e serverit të shpejtë dhe të qëndrueshëm; mbajtja e ngarkesës së front-end-it të lehtë është ajo që mbyll pjesën tjetër të hendekut.
Të ngjashme
Provoje falas për 14 ditë
Krijo faqet e tua të para falas për 14 ditë — pa kartë. Po zhvendos një rrjet ekzistues? Migrimi yt i parë është falas nga ne.
Fillo falas