...
logotip spletnega gostovanja

Hierarhije predpomnilnika: opcode, stran, brskalnik in rob - učinkovita uporaba vseh ravni za optimalno delovanje

Hierarhije predpomnilnika najhitrejši čas nalaganja dosežem, če uporabljam vsako plast posebej: kodo opcode, stran, brskalnik in rob. V jasnih korakih prikazujem, kako te plasti združujem, se izogibam konfliktom in nastavljam konfiguracije tako, da so zahtevki krajši, TTFB pa se vidno zmanjša.

Osrednje točke

Da bi bil pregled jasen, najprej povzemam ključne teme in jih neposredno usklajujem z izvedbenimi cilji. Vse ravni razložim s konkretnimi nastavitvami, tako da izvajanje uspe brez ovinkov. Jasno razmejim dinamične dele, da ohranim personalizacijo. Optimiziram glave in ključe predpomnilnika, tako da v predpomnilniku ni nepotrebnih odpadkov. Na koncu vse skupaj združim v strogo verigo, tako da vsako iskanje poteka po najhitrejši poti.

  • Operna koda pospešuje PHP
  • Predpomnilnik strani skrajšano TTFB
  • Brskalnik Varčuje s pasovno širino
  • Rob Zmanjšanje zakasnitve
  • Orkestracija Preprečuje konflikte

Kaj pravzaprav pomeni „hierarhije predpomnilnika“?

Razumem, da Hierarhija postopno predpomnjenje od jedra strežnika do končne naprave. Vsaka plast odgovarja na drugačno vprašanje: ali mora strežnik ponovno sestaviti kodo, ali mora PHP ponovno prikazati stran, ali mora brskalnik ponovno naložiti sredstva ali pa robno vozlišče dostavi pripravljeno vsebino blizu uporabnika. Podvajanju dela se izognem tako, da uskladim ravni in določim jasne odgovornosti. Na ta način zmanjšam obremenitev procesorja, zaledne poizvedbe in omrežno zakasnitev, ne da bi pri tem izgubil funkcionalnost. Kratek uvod v ravni lahko najdem v tem zgoščenem vodniku: Enostavne ravni predpomnilnika.

Predpomnilnik opkod: takojšnje pospeševanje PHP

Na spletni strani Operna koda-caching, hranim sestavljeno PHP bajtokodo v pomnilniku RAM in si prihranim ponavljajoče se razčlenjevanje. To pospeši vse zahteve, ki se dotikajo PHP, zlasti delovne obremenitve CMS, kot je WordPress. Omogočim OPcache in dovolj velikodušno dimenzioniram pomnilnik, tako da pogoste skripte niso nikoli premaknjene. Nastavim zmerno ponovno preverjanje, tako da spremembe ostanejo vidne takoj, brez prepogostega preverjanja. Na ta način opazno zmanjšam obremenitev procesorja in odzivni čas.

Tipične parametre OPcache v php.ini namerno nastavim konzervativno, spremljam stopnjo zadetkov in jih po potrebi prilagodim. Število pospešenih datotek je dovolj veliko, da se projekt v celoti prilega. Za osrednje razrede uporabljam predhodno nalaganje, tako da tudi hladni zagoni tečejo hitreje. Spremembe nameščam s ponastavitvijo predpomnilnika, da se izognem tveganju nekonsistentnih stanj. Konfiguracijski blok uporabljam kot izhodišče in ne kot togo dogmo.

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Redno preverjam OPcache-statistika, saj samo merjenje pokaže, ali je predpomnilnik nosilec ali thrash't. Gostovanje nadzornih plošč ali statusnih strani PHP mi pomaga zmanjšati število pogrešanj. Izogibam se vrednostim pomnilnika, ki so premajhne in vodijo do iztisnitev. Izogibam se tudi redkemu potrjevanju, tako da se produktivne spremembe ne zataknejo. S tem ravnovesjem delam učinkovito in varno.

Predpomnjenje strani: HTML brez čakanja

Na spletni strani Predpomnilnik strani Končani HTML shranim, tako da PHP in podatkovna baza sploh ne delujeta več. To drastično zmanjša TTFB in povzroči največje skoke pri obremenitvi. Dosledno izključujem personalizirane poti, kot so nakupovalna košarica, blagajna in uporabniški računi. Hkrati manjše dinamične dele zapremo prek AJAX-a ali robnih vključkov, tako da lahko preostali del težko pride iz predpomnilnika. Tako spletno mesto ostane hitro, ne da bi izgubilo pomembno individualnost.

Odločim se, ali bom uporabil predpomnilnik na ravni strežnika ali vtičnik. V strežniku dosežem najboljše Zakasnitev, Vtičniki mi omogočajo prilagodljiv nadzor v sistemu CMS. Mehanizmi za predhodno nalaganje vnaprej napolnijo predpomnilnik, tako da začetni klici ne čakajo. Osirotele vnose ob posodabljanju vsebine očistim s pravili za čiščenje. Za posebej draga področja združim tudi objektni predpomnilnik, tako da so dostopi do podatkovne zbirke manj pogosti.

Predpomnilnik brskalnika: sredstva naj bodo lokalna

Na spletni strani Brskalnik-statične datoteke, kot so slike, CSS in JS, puščam v lokalnem predpomnilniku. Obiskovalci, ki se vračajo, ne naložijo skoraj ničesar, strežnik pa ostane prost. Za nespremenljiva sredstva, ki jih zagotavljam z različicami imen datotek, določim dolge vrednosti največje starosti. Dinamičnim končnim točkam dodam kratke čase ali must-revalidate, tako da aplikacija ostane posodobljena. Na ta način zmanjšam pasovno širino in optimiziram zaznavno hitrost.

Pozoren sem na čisto kombinacijo nadzora predpomnilnika, ETag in last-modified. Za nespremenljive datoteke nastavim nespremenljivo, da brskalnik ne preverja po nepotrebnem. Za vire s pogostimi posodobitvami uporabljam pogojne zahteve prek oznake ETag. Izogibam se dvoumnim glavi, saj nasprotujoči si signali povzročajo nesporazume. Nadzor ohranjam neposredno v spletnem strežniku ali prek vtičnika CMS, odvisno od okolja.

Predpomnilnik na robu: bližina uporabnika

O Rob-omrežja, dostavljam vsebino v globalnih točkah dostopa, kar zmanjšuje zakasnitve in blaži konice. HTML, slike in API-je lahko glede na nabor pravil postrežem v bližini uporabnika. Delam s ključi predpomnilnika, ki vsebujejo le potrebne spremenljivke, da se zmanjša razdrobljenost. Pravila, kot sta stale-while-revalidate in stale-if-error, zagotavljajo, da uporabniki takoj vidijo veljavno kopijo, tudi če se Izvor šele ogreva. Predvsem mednarodne ciljne skupine imajo koristi, saj se čas usmerjanja opazno skrajša.

Ločujem različice, kadar se mobilni in namizni računalnik zelo razlikujeta. Območje blagajne in računa namenoma izpustim na robu, da bi se izognil trkom s sejami in piškotki. Redno preverjam stopnjo zadetkov in prilagajam TTL, dokler ne dosežem optimalnih možnosti. Praktičen poglobljen pogled na to Vodnik za predpomnjenje na robu s poudarkom na zakasnitvah in omrežnih poteh. Pri roki imam čiste strategije čiščenja, tako da posodobitve takoj začnejo veljati po vsem svetu.

Pravilno nastavite glavo HTTP

Spletna stran Naslov nadzor nad tem, kako daleč lahko vsebina potuje in kdaj je ponovno potrjena. Nadzor predpomnilnika uporabljam za določanje vidnosti, življenjske dobe in obveznosti ponovnega preverjanja. ETag edinstveno identificira vir in omogoča zahtevke if-none-match. Last-Modified zagotavlja rezervno možnost za odjemalce, ki ne upoštevajo oznak ETag. Kombinacija je jasna, tako da imajo odjemalec, CDN in izvor enaka pričakovanja.

Naslednji pregled uporabljam kot praktično referenco pri konfiguraciji. Vsako vrstico preverim glede na vrsto vira in obnašanje spremembe. Pri statičnih datotekah nastavim dolge vrednosti največjega trajanja s funkcijo immutable. Za pogosto posodobljeno vsebino skrajšam trajanje in se zanašam na pogojne zahteve. S tem ohranjam učinkovito in pravilno podatkovno pot.

Naslov Funkcija
Nadzor predpomnilnika nadzoruje trajanje, vidnost in ponovno potrjevanje (npr. max-age, public, must-revalidate)
ETag Enolični identifikator različice, podlaga za pogojne klice
Nazadnje spremenjeno Časovni žig kot alternativa oznaki ETag, ki se uporablja za potrjevanje.

Strategije razveljavitve predpomnilnika in svežine

Načrtujem Invalidacija tako skrbno kot samo predpomnjenje. Selektivno čiščenje po ID, oznaki ali poti preprečuje popolno izpiranje, ki povzroča stroške. Pri nameščanju čistim samo tisto, kar se je res spremenilo. Stale-while-revalidate ohranja uporabnike hitre, medtem ko se v ozadju nalagajo sveže kopije. Funkcija Stale-if-error (Ustavi, če je napaka) zajema napake v Izvoru, ne da bi poslabšala uporabniško izkušnjo.

Če se vsebina pogosto obrača, kombiniram kratek TTL z visoko stopnjo zadetkov. Za arhive, medije in knjižnice izberem dolge čase, različice imen datotek in odstranim kontrolne obremenitve. Nadzorne plošče na strani CDN ali strežnika mi pokažejo, kje so vedra predpomnilnika premajhna. Nato prilagodim število rež in velikosti objektov. To nenehno prilagajanje je v vsakdanjem življenju zelo pomembno.

Ključi predpomnilnika, piškotki in Vary

S tanko Ključi Število različic je majhno. V ključu so samo tisti parametri, ki resnično spremenijo rezultat. Glave Vary uporabljam namenoma, na primer po razredih Accept-Encoding ali User-Agent, če je to potrebno. Preveč piškotkov v ključu razbije predpomnilnik in zmanjša stopnjo zadetkov. Neuporabljene piškotke počistim in parametre, ki se uporabljajo za sledenje, uredim iz ključa.

Če moram spreminjati jezike, valute ali postavitve, uporabim posebne ključe, kot sta lang=de ali currency=EUR. To raznolikost omejujem na primere, ki jih resnično potrebujem. Pri testih A/B ločim samo segmente, ki se razlikujejo po vsebini. Vse drugo upravljam na strani odjemalca ali prek robne logike brez eksplozije ključev. Tako ohranjam učinkovitost globalnega predpomnilnika.

Predpomnilnik objektov in prehodni pojavi

Ein Objekt-Predpomnilnik zmanjša drage poizvedbe po zbirki podatkov, saj hrani rezultate v pomnilniku. Za WordPress izberem Redis ali Memcached, da zagotovim hiter dostop do pogosto zahtevanih možnosti, poizvedb in sej. Za začasno shranjevanje dragih izračunov uporabljam prehodne elemente. Te vrednosti počistim med uvajanjem, ko se odvisnosti spremenijo. Tako ohranim dinamičnost strani, ki je še vedno hitra.

Ta primerjava mi pomaga pri velikostih projektov z intenzivnimi obremenitvami podatkov: Redis proti Memcachedu. V njem sem prepoznal značilne prednosti obeh sistemov glede na delovno obremenitev. Izmerim pomnilnik RAM in preverim strategije izločanja, da naredim prostor za redko uporabljene predmete. Spremljanje stopnje zadetkov/izgub pokaže, ali konfiguracija deluje. Ta raven idealno dopolnjuje predpomnilnik strani.

Kombinacija: optimizirana veriga

Združujem Ravni tako da vsaka zahteva opravi najkrajšo pot. Predpomnilnik OPcache pospeši generiranje, ko se HTML dejansko ustvari. Predpomnilnik strani zagotavlja pripravljene oznake za anonimne obiskovalce. Predpomnilnik brskalnika preprečuje ponavljajoče se prenose sredstev, brskalnik Edge pa globalno porazdeli vsebino. Na samem koncu je strategija čistega čiščenja in različic, tako da posodobitve začnejo veljati takoj.

Naslednjo tabelo imam pri roki kot preglednico, ko spreminjam nastavitve. Stolpec „Konfiguracija“ med izvajanjem berem kot seznam opravil. Poskrbim, da se ravni med seboj dopolnjujejo in se ne izničujejo. Tako ohranjam celotno arhitekturo jasno in učinkovito. Ta pregled preprečuje napake med načrtovanjem.

Raven predpomnilnika Prednost Tipična vsebina Konfiguracija
Operna koda Hitro izvajanje PHP Bajtokoda PHP php.ini, Strežnik-Panel
Stran Nizka vrednost TTFB Končan HTML Raven strežnika ali vtičnika
Brskalnik Lokalna ponovna uporaba CSS, JS, slike Glava HTTP, izdajanje različic
Rob Globalna bližina HTML in sredstva Pravila CDN, Ključi, Čiščenje

Merjenje: TTFB, LCP in število zadetkov

Merim TTFB, in preverite, kako hitro prispe prvi bajt. LCP mi pokaže, ali se vidna vsebina pojavi pravočasno. S pomočjo analitike predpomnilnika preverjam stopnjo zadetkov in prepoznavam poti, kjer se kopičijo zgrešeni podatki. Metrike povezujem z namestitvami, obremenitvijo pajkov in prometnimi konicami. Samo številke pokažejo, kje moram zategniti vijake.

Prijavim glave odziva, kot sta starost in stanje predpomnilnika CF, da vidim uspehe robov. Strežniški dnevniki mi povedo, ali predpomnilnik strani pravilno deluje. Če so odstopanja velika, poiščem piškotke, parametre poizvedb ali spremenljivke, ki razdvajajo predpomnilnik. Preizkusim različice s prijavljenim stanjem in brez njega. Na ta način lahko hitro poiščem prilagoditve za stabilno hitrost.

Tipične napake in popravki

Preveč Variante v predpomnilniku so pogosta ovira. Zmanjšam parametre poizvedb v ključu in nevtraliziram parametre sledenja. Druga klasika so nasprotujoče si glave, kot je prepoved shranjevanja skupaj z dolgim maksimalnim trajanjem. Tudi prazna ali nepravilna čiščenja lahko dajejo vtis, da predpomnilnik ne deluje. Takšne težave hitro odpravim z jasnimi pravili in dnevniki.

Druga težava so vtičniki, ki zapisujejo dinamično vsebino, ki je trdno zakodirana v HTML. Takšne elemente prenesem na razdrobljene končne točke, ki so v predpomnilniku ali se ponovno nalagajo neodvisno. Piškotki pogosto nenamerno blokirajo robni predpomnilnik; nepotrebne piškotke odstranim že na začetku. Zaradi slabega določanja različic morajo brskalniki vedno znova nalagati datoteke; datoteke dosledno oštevilčim. S tem ohranjam čistost in odpornost cevovoda.

Drevo odločanja: Kdo se odzove na poizvedbo?

Določim jasno pot odločanja, da določim, katera raven je dovoljena za dostavo. S tem se izognemo nepotrebnim zadetkom izvora in reproduktibilno zmanjšamo TTFB.

  • 1) Ali je vir nespremenljiv (datoteka z različicami)? Predpomnilnik brskalnika z dolgim maksimalnim trajanjem in nespremenljiv.
  • 2) Ali je zahteva anonimna, GET in brez občutljivih piškotkov? Predpomnilnik Edge/strani z javno, s-maxage in stale-while-revalidate.
  • 3) Ali zahteva vsebuje Auth-Cookies, Authorisation-Header ali je POST? Origin, po želji z Object-Cache.
  • 4) Ali URL vsebuje samo kozmetične parametre (utm, fbclid)? Odstranim jih iz ključa predpomnilnika.
  • 5) Ali potrebujete majhne žive dele (npr. število nakupovalnih košaric)? Razdrobljeno prek AJAX-a ali ESI.
// psevdo logika
if (immutable_asset) return browser_cache;
if (is_get && is_anonymous && cacheable) return edge_or_page_cache;
if (needs_fragment) return cached_html + dynamic_fragment;
return origin_with_object_cache;

Obvladovanje razdrobljenosti: ESI, AJAX in delno upodabljanje

Dinamične otoke izoliram, da lahko ostali močno predpomnijo. ESI je primeren za vbrizgavanje na strani strežnika (npr. personalizirani bloki), AJAX pa za točke ponovnega nalaganja na strani odjemalca. Pomembno je, da imajo fragmenti svoje lastne, kratke TTL, tako da ostanejo posodobljeni, ne da bi razveljavili celoten dokument.

  • Statično osnovno ogrodje: dolg TTL, javno, s-maxage, stale-while-revalidate.
  • Dinamični fragment: kratek TTL, must-revalidate ali no-store, če je prilagojen.
  • Primer napake: stale-if-error v ovoju HTML preprečuje nastanek belih strani.
// Primer glave za ovojnico HTML
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60, stale-if-error=86400

// Primer glave za osebni fragment
Cache-Control: private, no-store

Izogibajte se stampedu v predalih in nadzorujte ogrevanje

Preprečujem učinek črede, ko veliko hkratnih zgrešenih izidov preplavi Izvor. Moja orodja so mehki TTL/trdi TTL, združevanje zahtevkov in zaklepanje. Uporabljam predpomnilnike, ki ciklično ogrevajo zemljevide spletnih strani ali pomembne poti, in razporedim TTL, tako da se ne izteče vse hkrati.

  • Mehki TTL: delavec lahko obnovi objekte, ki jim je potekel rok trajanja, medtem ko drugi uporabniki še vedno prejemajo zastarele objekte.
  • Združitev: Sočasne zahteve za isti ključ se združijo.
  • Razporejeni TTL-ji: Kritične strani so deležne časovno razporejenih časov izvajanja, da se ublažijo valovi čiščenja.
// Primer stopnjevanih izvajalnih časov
/home, /kategorija/* -> s-maxage=900
/article/* -> s-maxage=1800
/search -> s-maxage=120, stale-while-revalidate=30

Čista poravnava zasnove TTL v verigi

TTL brskalnika, robov in izvora nastavim tako, da se potrditev izvede tam, kjer je najugodnejša. Za HTML se zanašam na s-maxage na robu in ohranjam max-age na nizki ravni v brskalniku, da zagotovim hitro čiščenje. Pri sredstvih je obratno: zelo dolgi TTL brskalnika, ker različicanje zagotavlja ažurnost.

// HTML
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60

// Različica sredstev
Cache-Control: public, max-age=31536000, immutable

Izogibam se nasprotujočim si specifikacijam, kot sta no-cache in immutable. Jasna pravila ustvarjajo dosledne rezultate v celotni hierarhiji.

Stiskanje, HTTP/2/3 in določanje prednosti

Vključim Gzip/Brotli in pravilno nastavim glavo Vary, tako da so različice čisto ločene. Pri HTTP/2/3 imam koristi od multipleksiranja in prednostnega razvrščanja; to zmanjša blokiranje v glavi vrstice, ko se vzporedno nalaga veliko sredstev.

Primer # NGINX
gzip vklopljen;
gzip_types text/css application/javascript application/json image/svg+xml;
brotli on;
brotli_types text/css application/javascript application/json image/svg+xml;
add_header Vary "Accept-Encoding" vedno;

# Dolg TTL brskalnika za sredstva
lokacija ~* .(css|js|svg|woff2|jpg|png)$ {
  poteče 1 leto;
  add_header Cache-Control "public, max-age=31536000, immutable";
}

Preverjanje pristnosti, piškotki in varnost

Osebne vsebine nikoli ne objavljam v predpomnilniku. Zahteve z glavo avtorizacije ali sejnimi piškotki označim kot zasebne ali posebej obidem robni predpomnilnik. Hkrati imam le bele sezname bistvenih piškotkov, tako da ključ predpomnilnika ostane vitek.

  • Področja za prijavo/račun: Predpomnilnik: zasebno ali brez shranjevanja.
  • Javne strani HTML: javno, s-maxage; izogibajte se nastavljanju piškotkov.
  • Higiena piškotkov: odstranite nepomembne piškotke (npr. sledilne) iz ključa.
// VCL podobna logika
if (req.http.Authorisation) { return(pass); }
if (req.http.Cookie ~ "session=") { return(pass); }
// V ključu so samo potrebni piškotki
unset req.http.Cookie: ".*";

Učinkovito predpomnjenje končnih točk API in iskanja

Strogo ločujem med metodami: GET je mogoče shraniti v predpomnilnik, POST običajno ne. Pri pogostih iskalnih poizvedbah nastavim kratke vrednosti s-maxage in stale-while-revalidate, da se odzivni čas izravna. Odgovore z napakami 4xx/5xx shranjujem v predpomnilnik le za kratek čas ali pa sploh ne, tako da popravki začnejo veljati takoj.

// Primer glave za javni API GET
Cache-Control: public, max-age=0, s-maxage=120, stale-while-revalidate=30

// Napake v predpomnilniku obravnavajte poredko
Cache-Control: public, s-maxage=10

Opazljivost: glave, dnevniki in preverjanje TTFB

Za preglednost verige uporabljam pregled glave in dnevnike. Starost, kazalniki zadetkov/pomanjkljivosti in stanje na višji stopnji mi pokažejo, kje se izgublja čas. Uporabljam preprosta orodja za ponovljivo preverjanje TTFB in iskanje odstopanj.

Ukrep # TTFB
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}sn" https://example.org

Preverite glavo #
curl -I https://example.org | sed -n '1,20p'
# Dnevnik NGINX s stanjem predpomnilnika
log_format timed '$remote_addr "$request" $status $body_bytes_sent '
                 '$upstream_cache_status $upstream_response_time $request_time';
access_log /var/log/nginx/access.log timed;

Podatke dnevnika primerjam z namestitvami in čiščenjem. Visoki vrhovi pogrešanosti neposredno po izklopih kažejo na manjkajoče ogrevanje ali prekratke vrednosti TTL. Če starost ostaja trajno nizka, preverim, ali piškotki nenamerno zaobidejo robni predpomnilnik.

Uvajanje: oblikovanje različic in tekoče čiščenje

Različice vgrajujem v imena datotek (npr. app.9f3c1.js), da omogočim agresivno predpomnjenje brskalnika. Za HTML uporabljam tekoče čiščenje, pri katerem najprej posodobim kritične strani, nato pa globinske in dolgotrajne strani. Modre/zelene namestitve ločijo gradnjo od izdaje in mi dajo čas za posebno ogrevanje predpomnilnikov.

// Cevovod za sredstva
style.[hash].css
app.[hash].js
// HTML se vedno nanaša na nove hashe

Okna čiščenja načrtujem zunaj časa največje obremenitve in takoj zatem spremljam stopnjo zadetkov. Na ta način se izognem vrhuncem obremenitve v Izvoru.

Variante slik, DPR in odzivno predpomnjenje

Različice slik (velikost, format) ustvarjam deterministično, tako da ključ predpomnilnika ostane stabilen. Za različice WebP/AVIF izrecno ločujem prek poti do datoteke ali parametrov in ne samo prek glave Accept, da bi se izognil eksplozijam Vary. Za zaslone visoke ločljivosti (DPR) uporabljam srcset/size, kar brskalniku omogoča, da izbere najboljšo različico in da predpomnilnik začne delovati za vsako posamezno sredstvo.

<img src="img/hero-1024.jpg"
     srcset="img/hero-768.jpg 768w, img/hero-1024.jpg 1024w, img/hero-1600.jpg 1600w"
     sizes="(max-width: 768px) 90vw, 1024px" alt="">

Število različic na motiv je majhno, zastarele velikosti pa odstranim iz cevovoda, da se predpomnilnik ne razdrobi.

Načrtovanje zmogljivosti: pomnilnik predpomnilnika in velikosti predmetov

Velikost predpomnilnikov določim glede na dejanske vzorce dostopa: nekaj velikih predmetov (slike, videoposnetki) zahteva drugačne strategije kot veliko majhnih predmetov (HTML, JSON). Določim omejitve za največjo velikost predmeta in preverim, ali priljubljeni predmeti ostanejo v pomnilniku. Visoka stopnja ponovne uporabe je pomembnejša od absolutne velikosti; zato obrezujem ključe, združujem različice in preprečujem podvojitve.

// Primer: Omejitve
max_object_size = 10m
default_ttl = 600
nuke_limit = zmerno (izselitve brez stojišč)

Praktični kontrolni seznam za izvajanje

Aktiviram OPcache z dovolj pomnilnika in preverite stopnjo zadetkov. Nato nastavim predpomnjenje strani, izključim kritične poti in predhodno naložim pomembne URL-je. Nato nastavim glave brskalnika z dolgimi časi za nespremenljive datoteke in različico. V omrežju CDN določim ključe predpomnilnika, TTL in strategije čiščenja ter aktiviram funkcijo stale-while-revalidate. Na koncu z merilnimi orodji preverim, ali TTFB, LCP in stopnja zadetkov na robu dosegajo zastavljene cilje.

Kratek povzetek

Uporabljam Predpomnilnik hierarhično: predpomnilnik OPcache pospešuje kodo, predpomnilnik strani zagotavlja HTML, glave brskalnika ohranjajo sredstva lokalno, brskalnik Edge pa vsebino približuje uporabnikom. Z jasnimi ključi, ustreznimi TTL in pametnim razveljavljanjem zmanjšam obremenitev strežnika, pasovno širino in zakasnitve. Izmerjene vrednosti zagotavljajo napredek in kažejo možnosti optimizacije. S tem se ustvari zanesljiva veriga od izvora do končne naprave. Kdor išče dodatne podrobnosti o globalni dostavi, bo v praksi našel dovolj izhodišč, da bo njegova lastna arhitektura opazno hitrejša.

Aktualni članki