Spartinančiosios talpyklos hierarchijos: opkodas, puslapis, naršyklė ir kraštinė - efektyvus visų lygių naudojimas siekiant optimalaus našumo.

Spartinančiosios talpyklos hierarchijos greičiausiai įkeliama, kai naudoju kiekvieną sluoksnį: opkodą, puslapį, naršyklę ir kraštinę. Aiškiai parodysiu, kaip derinu šiuos sluoksnius, vengiu konfliktų ir nustatau tokias konfigūracijas, kad užklausos būtų trumpesnės, o TTFB akivaizdžiai sumažėtų.

Centriniai taškai

Kad apžvalga būtų aiški, pirmiausia apibendrinsiu pagrindines temas ir tiesiogiai suderinsiu jas su veiklos tikslais. Paaiškinu visus lygius su konkrečiais nustatymais, kad įgyvendinimas pavyktų be nukrypimų. Aiškiai atriboju dinamines dalis, kad būtų išsaugotas personalizavimas. Optimizuoju antraštes ir talpyklos raktus, kad talpykloje nebūtų nereikalingų atliekų. Galiausiai viską sujungiu į griežtą grandinę, kad kiekviena paieška vyktų greičiausiu keliu.

• Operacinis kodas pagreitina PHP
• Puslapio talpykla sutrumpintas TTFB
• Naršyklė Taupomas dažnių juostos plotis
• Kraštas Sumažina vėlavimą
• Orkestravimas Užkerta kelią konfliktams

Ką iš tikrųjų reiškia „spartinančiosios talpyklos hierarchijos“?

Aš suprantu, kad Hierarchija pakopinis spartinimas nuo serverio branduolio iki galutinio įrenginio. Kiekvienas sluoksnis atsako į skirtingus klausimus: ar serveris turi iš naujo kompiliuoti kodą, ar PHP turi iš naujo atvaizduoti puslapį, ar naršyklė turi iš naujo įkelti turinį, ar kraštinis mazgas pateikia paruoštą turinį arti vartotojo. Suderindamas lygmenis ir priskirdamas aiškią atsakomybę vengiu darbo dubliavimo. Taip sumažinu procesoriaus apkrovą, užklausas galinei sistemai ir tinklo vėlavimą, neprarasdamas funkcionalumo. Šiame kompaktiškame vadove galiu rasti trumpą lygių pristatymą: Paprasti spartinimo lygiai.

Operacinių kodų spartinimas: iš karto pagreitinkite PHP

Svetainėje Operacinis kodas-caching, aš saugau kompiliuotą PHP baitkodą RAM atmintyje ir sutaupau pakartotinį parsavimą. Tai pagreitina kiekvieną su PHP susijusią užklausą, ypač CMS, pavyzdžiui, "WordPress". Įjungiu "OPcache" ir pakankamai dosniai išmatuoju atmintį, kad dažnai naudojami skriptai niekada nebūtų išstumiami. Nustatau vidutinį pakartotinį patvirtinimą, kad pakeitimai išliktų matomi greitai, per dažnai netikrinant. Taip pastebimai sumažinu procesoriaus apkrovą ir atsako laiką.

Sąmoningai konservatyviai nustačiau tipinius OPcache parametrus php.ini, stebiu pataikymo rodiklį ir prireikus koreguoju. Palaikau pakankamai didelį pagreitintų failų skaičių, kad projektas visiškai tilptų. Naudoju išankstinį centrinių klasių įkėlimą, kad net šaltas paleidimas vyktų greičiau. Pakeitimus diegiu iš naujo nustatydamas talpyklą, kad išvengčiau nesuderinamų būsenų rizikos. Konfigūracijos bloką naudoju kaip atspirties tašką, o ne kaip griežtą dogmą.

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

Reguliariai tikrinu OPcache-statistika, nes tik matavimas parodo, ar talpykla yra guolis, ar thrash't. Prieglobos prietaisų skydeliai arba PHP būsenos puslapiai padeda man sumažinti praleidimų skaičių. Vengiu per mažų atminties verčių, dėl kurių įvyksta iškraustymai. Taip pat vengiu reto patvirtinimo, kad produktyvūs pakeitimai neužstrigtų. Pasiekęs tokią pusiausvyrą, dirbu efektyviai ir saugiai.

Puslapio spartinimas: HTML be laukimo laiko

Svetainėje Puslapio talpykla Išsaugau baigtą HTML, kad PHP ir duomenų bazė nebeveiktų. Tai smarkiai sumažina TTFB ir sukelia didžiausius apkrovos šuolius. Nuosekliai neįtraukiu personalizuotų kelių, pavyzdžiui, pirkinių krepšelio, kasos ir naudotojų paskyrų. Tuo pačiu metu nedideles dinamines dalis uždaromi per AJAX arba edge-side includes, kad likusi dalis galėtų sunkiai ateiti iš talpyklos. Taip svetainė išlieka greita neprarasdama svarbaus individualumo.

Sprendžiu, ar naudoti serverio lygmens spartinančiąją atmintinę, ar dirbti su įskiepiu. Serveryje pasieksiu geriausią rezultatą Vėlavimas, Įskiepiai suteikia man lanksčią TVS kontrolę. Išankstinio įkėlimo mechanizmai iš anksto užpildo talpyklą, kad nereikėtų laukti pradinių skambučių. Atnaujindamas turinį, naudodamasis valymo taisyklėmis, išvalau našlaičius įrašus. Ypač brangiose srityse taip pat derinu objektų talpyklą, kad kreipimaisi į duomenų bazę būtų retesni.

Naršyklės spartinančioji atmintinė: išsaugokite vietinį turtą

Svetainėje Naršyklė-Statinius failus, pavyzdžiui, paveikslėlius, CSS ir JS, palieku vietinėje talpykloje. Tuomet grįžtantys lankytojai beveik nieko neįkelia, o serveris lieka laisvas. Nekeičiamiems ištekliams, kuriems suteikiu failų pavadinimų versijų nustatymą, nustatau ilgas maksimalaus amžiaus vertes. Į dinaminius galinius taškus pridedu trumpus laikus arba must-revalidate, kad programa būtų nuolat atnaujinama. Taip sumažinu pralaidumą ir optimizavau suvokiamą greitį.

Atkreipiu dėmesį į švarų spartinančiosios atminties kontrolės, ETag ir last-modified derinį. Nekeičiamiems failams nustatau immutable, kad naršyklė be reikalo netikrintų. Ištekliams, kurie dažnai atnaujinami, naudoju sąlygines užklausas per ETag. Vengiu dviprasmiškų antraščių, nes prieštaringi signalai sukelia nesusipratimų. Priklausomai nuo aplinkos, kontroliuoju tiesiogiai žiniatinklio serveryje arba per CMS įskiepį.

Kraštinė spartinančioji atmintinė: arti naudotojo

Apie Kraštas-tinkluose, teikiu turinį pasauliniuose taškuose, todėl sumažėja vėlavimas ir išlyginami pikiniai taškai. HTML, paveikslėlius ir API galima pateikti arti vartotojo, atsižvelgiant į taisyklių rinkinį. Dirbu su talpyklos raktais, kuriuose yra tik būtini kintamieji, kad sumažėtų fragmentacija. Tokios taisyklės kaip "stale-while-revalidate" ir "stale-if-error" užtikrina, kad naudotojai iš karto matytų galiojančią kopiją, net jei "Origin" tik įšyla. Tai ypač naudinga tarptautinėms tikslinėms grupėms, nes pastebimai sutrumpėja maršruto parinkimo laikas.

Atskiriu variantus, kai mobilusis ir darbalaukis labai skiriasi. Sąmoningai palieku kraštinę kasos ir paskyros sritį, kad išvengčiau susidūrimų su sesijomis ir slapukais. Reguliariai tikrinu pataikymo rodiklį ir koreguoju TTL, kol pasiekiami optimalūs šansai. Praktinis išsamus žvilgsnis į tai Kraštinės spartinančiosios atmintinės vadovas daugiausia dėmesio skiriant vėlavimui ir tinklo keliams. Po ranka turiu švarias valymo strategijas, kad atnaujinimai iš karto įsigaliotų visame pasaulyje.

Teisingai nustatykite HTTP antraštę

Die Antraštė kontroliuoti, kaip toli turinys gali keliauti ir kada jis yra pakartotinai patvirtinamas. Naudoju spartinančiosios atminties valdymą, kad nustatyčiau matomumą, gyvavimo trukmę ir pakartotinio patvirtinimo įsipareigojimus. ETag unikaliai identifikuoja išteklių ir leidžia atlikti užklausas "if-none-match". Last-Modified suteikia atsarginę galimybę klientams, kurie ignoruoja ETag. Kombinacija yra aiški, kad klientas, CDN ir kilmės šalis turėtų tuos pačius lūkesčius.

Naudoju šią apžvalgą kaip praktinę nuorodą konfigūruojant. Kiekvieną eilutę patikrinu pagal išteklių tipą ir pakeitimo elgseną. Statiniams failams nustatau ilgas maksimalias trukmės vertes, naudodamas immutable. Dažnai atnaujinamam turiniui sutrumpinu trukmę ir remiuosi sąlyginėmis užklausomis. Taip duomenų kelias išlieka efektyvus ir teisingas.

Antraštė	Funkcija
Spartinančiosios atmintinės valdymas	kontroliuoja trukmę, matomumą, pakartotinį patvirtinimą (pvz., max-age, public, must-revalidate)
ETag	Unikalus versijos identifikatorius, sąlyginių iškvietimų pagrindas
Paskutinį kartą pakeista	Laiko žyma kaip alternatyva ETag, naudojama patvirtinimui

talpyklos panaikinimo ir šviežumo strategijos

Planuoju Invalidavimas taip pat kruopščiai, kaip ir patį spartinimą. Atrankinis valymas pagal ID, žymą arba kelią padeda išvengti pilno išplaunimo, dėl kurio patiriama išlaidų. Diegdamas išvalau tik tai, kas iš tikrųjų pasikeitė. "Stale-while-revalidate" užtikrina, kad naudotojai būtų greiti, o fone įkeliamos naujos kopijos. Funkcija "Stale-if-error" fiksuoja "Origin" klaidas, nesumažindama naudotojų patirties.

Jei turinys dažnai keičiasi, trumpą TTL derinu su dideliu pataikymo rodikliu. Archyvams, laikmenoms ir bibliotekoms renkuosi ilgą laiką, versijuoju failų pavadinimus ir pašalinu tikrinimo apkrovas. CDN arba serverio pusėje esančios prietaisų skydeliai man parodo, kur talpyklos kibirėliai yra per maži. Tada koreguoju slotų skaičių ir objektų dydžius. Šis nuolatinis derinimas labai svarbus kasdieniame gyvenime.

talpyklos raktai, slapukai ir "Vary

Su plonu Raktai Aš stengiuosi, kad variantų būtų nedaug. Į raktą įtraukiami tik tie parametrai, kurie iš tikrųjų keičia rezultatą. Jei reikia, sąmoningai naudoju Vary antraštes, pavyzdžiui, po Accept-Encoding arba User-Agent klasių. Per daug slapukų rakte suskaldo talpyklą ir sumažina pataikymo rodiklį. Iš rakto išvalau nenaudojamus slapukus ir reguliuoju parametrus, kurie naudojami stebėjimui.

Jei reikia keisti kalbas, valiutas ar išdėstymus, naudoju specialius raktus, pvz., lang=de arba currency=EUR. Tokią įvairovę taikau tik tais atvejais, kurių man tikrai reikia. Atlikdamas A/B bandymus, atskiriu tik tuos segmentus, kurių turinys skiriasi. Visa kita valdau kliento pusėje arba naudodamasis kraštine logika be raktų sprogimo. Taip palaikau visuotinės talpyklos efektyvumą.

Objektų talpykla ir pereinamieji procesai

Ein Objektas-Spartinančioji atmintinė sumažina brangių duomenų bazės užklausų skaičių, nes rezultatai saugomi atmintyje. WordPress atveju renkuosi "Redis" arba "Memcached", kad užtikrintum greitą prieigą prie dažnai prašomų parinkčių, užklausų ir sesijų. Naudoju pereinamuosius parametrus, kad laikinai saugočiau brangius skaičiavimus. Įdiegimo metu išvalau šias reikšmes, kai pasikeičia priklausomybės. Taip puslapis išlieka dinamiškas ir vis dar greitas.

Šis palyginimas man padeda, kai projekto dydis yra didelis, o duomenų apkrovos yra didelės: "Redis" ir "Memcached. Ten aš pripažįstu tipiškus abiejų sistemų privalumus, priklausomai nuo darbo krūvio. Išmatuoju operatyviosios atminties dydį ir patikrinu iškeldinimo strategijas, kad būtų galima užleisti vietą retai naudojamiems objektams. Stebėdamas pataikymo / praleidimo rodiklius, parodysiu, ar konfigūracija veikia. Šis lygis idealiai papildo puslapių talpyklą.

Derinys: optimali grandinė

Aš derinu Lygiai kad kiekviena užklausa eitų trumpiausiu keliu. "OPcache" pagreitina generavimą, kai iš tikrųjų kuriamas HTML. Puslapio talpykloje anoniminiams lankytojams pateikiamos paruoštos žymės. Naršyklės spartinančioji atmintinė apsaugo nuo pakartotinio turinio perkėlimo, o "Edge" paskirsto turinį visame pasaulyje. Pačioje pabaigoje - švaraus valymo ir versijų kūrimo strategija, kad atnaujinimai įsigaliotų iš karto.

Toliau pateiktą lentelę laikau po ranka, kai keičiu nustatymus. Įgyvendindamas projektą, stulpelį „Konfigūracija“ skaitau kaip darbų sąrašą. Įsitikinu, kad lygiai papildo vienas kitą ir nepanaikina vienas kito. Taip bendra architektūra išlieka aiški ir veiksminga. Ši apžvalga padeda išvengti klaidų planavimo metu.

Spartinančiosios atmintinės lygis	Privalumas	Tipinis turinys	Konfigūracija
Operacinis kodas	Greitas PHP vykdymas	PHP baitkodas	php.ini, Serverio skydelis
Puslapis	Žemas TTFB	Baigtas HTML	Serverio lygmuo arba įskiepis
Naršyklė	Vietinis pakartotinis naudojimas	CSS, JS, vaizdai	HTTP antraštė, versijų nustatymas
Kraštas	Visuotinis artumas	HTML ir turtas	CDN taisyklės, raktai, valymas

Matavimas: TTFB, LCP ir pataikymo rodikliai

Aš matuoju TTFB, norėdami pamatyti, kaip greitai gaunamas pirmasis baitas. LCP parodo, ar matomas turinys pasirodo laiku. Naudoju talpyklos analizę, norėdamas patikrinti pataikymo rodiklius ir atpažinti maršrutus, kuriuose kaupiasi praleidimai. Metrikas susieju su diegimu, "crawler" apkrova ir duomenų srauto piku. Tik skaičiai parodo, kur reikia priveržti varžtus.

Registruoju atsakymo antraštes, pvz., amžių ir CF talpyklos būseną, kad galėčiau vizualizuoti krašto sėkmę. Iš serverio žurnalų sužinau, ar puslapio talpykla veikia tinkamai. Jei yra didelių nukrypimų, ieškau slapukų, užklausos parametrų ar kintamųjų, kurie suskaldo talpyklą. Testuoju variantus su prisijungimo būsena ir be jos. Tokiu būdu galiu greitai rasti koregavimus, užtikrinančius stabilų greitį.

Tipinės klaidos ir pataisymai

Per daug Variantai talpykloje yra dažnas stabdys. Sumažinu užklausos parametrus rakte ir neutralizuoju sekimo parametrus. Kita klasika - prieštaringos antraštės, pavyzdžiui, no-store kartu su ilgu max-age. Tuščios arba neteisingai išvalytos talpyklos taip pat gali sudaryti įspūdį, kad talpykla neveikia. Tokias problemas greitai išsprendžiu naudodamas aiškias taisykles ir žurnalus.

Kita problema - tai įskiepiai, kurie į HTML įrašo dinaminį turinį, užkoduotą standžiai. Tokius elementus perkeliu į fragmentiškus galinius taškus, kurie talpinami į talpyklą arba įkeliami atskirai. Slapukai dažnai netyčia užblokuoja kraštinę talpyklą; anksti pašalinu nereikalingus slapukus. Prastas versijų nustatymas verčia naršykles vis iš naujo įkrauti; nuosekliai numeruoju failus. Tai užtikrina, kad vamzdynas būtų švarus ir atsparus.

Sprendimų medis: kas atsako į užklausą?

Nustatau aiškų sprendimų priėmimo būdą, kad būtų galima nustatyti, kurį lygį leidžiama pristatyti. Taip išvengiama nereikalingų kilmės smūgių ir atkuriamai sumažinamas TTFB.

• 1) Ar išteklius yra nekintamas (failas su versija)? Naršyklės talpykla su ilgu maksimaliu amžiumi ir nekeičiama.
• 2) Ar užklausa yra anoniminė, GET ir be slaptųjų slapukų? Edge/puslapio talpykla su public, s-maxage ir stale-while-revalidate.
• 3) Ar užklausoje yra "Auth-Cookies", "Authorisation-Header", ar ji yra POST? Origin, pasirinktinai su Object-Cache.
• 4) Ar URL turi tik kosmetinius parametrus (utm, fbclid)? Aš juos pašalinu iš talpyklos rakto.
• 5) Ar jums reikia mažų gyvų dalių (pvz., pirkinių krepšelių skaičiaus)? Suskaidoma per AJAX arba ESI.

// pseudo logika
if (immutable_asset) return browser_cache;
if (is_get && is_anonymous && cacheable) return edge_or_page_cache;
if (needs_fragment) return cache_html + dynamic_fragment;
return origin_with_object_cache;

Fragmentacijos valdymas: ESI, AJAX ir dalinis atvaizdavimas

Išskiriu dinamiškas salas, kad likusios galėtų sunkiai įsidėti į talpyklą. ESI tinka serverio pusės injekcijoms (pvz., personalizuotiems blokams), AJAX - kliento pusės perkrovimo taškams. Svarbu, kad fragmentai gautų savo, trumpus TTL, kad jie išliktų aktualūs ir nepanaikintų viso dokumento.

• Statinė pagrindinė sistema: ilgas TTL, viešas, s-maxage, stale-while-revalidate.
• Dinaminis fragmentas: trumpas TTL, must-revalidate arba no-store, jei pritaikyta asmeniškai.
• Klaidos atvejis: "stale-if-error" HTML apvalkale apsaugo nuo baltų puslapių.

// HTML voko antraštės pavyzdys
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60, stale-if-error=86400

// Asmeninio fragmento antraštės pavyzdys
Cache-Control: private, no-store

Venkite talpyklų antplūdžio ir kontroliuokite apšilimą

Taip užkertamas kelias bandos efektui, kai vienu metu daugybė praleistų klaidų užplūsta Pradžią. Mano įrankiai - minkštas TTL / kietas TTL, užklausų sujungimas ir blokavimas. Naudoju išankstinius įkroviklius, kurie cikliškai pašildo svetainių žemėlapius arba svarbius kelius, ir išdėstau TTL, kad ne viskas baigtųsi vienu metu.

• Minkštas TTL: darbuotojas gali atnaujinti objektus, kurių galiojimo laikas pasibaigęs, o kiti vartotojai vis dar gauna pasenusius objektus.
• Sujungimas: vienu metu pateiktos to paties rakto užklausos sujungiamos.
• Pakopomis išdėstyti TTL: Kritiniams puslapiams suteikiamas išskaidytas vykdymo laikas, kad būtų išlygintos valymo bangos.

// Laipsniškų paleidimo laikų pavyzdys
/home, /category/* -> s-maxage=900
/article/* -> s-maxage=1800
/search -> s-maxage=120, stale-while-revalidate=30

Švarus TTL konstrukcijos suderinimas grandinėje

Nustatau naršyklės, krašto ir kilmės TTL taip, kad pakartotinis patvirtinimas vyktų ten, kur jis palankiausias. HTML atveju pasikliauju s-maxage krašte ir palaikau mažą max-age naršyklėje, kad būtų užtikrintas greitas išvalymas. Turtui - atvirkščiai: labai ilgas naršyklės TTL, nes versijavimas užtikrina atnaujinimą.

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

// Versijuotas turtas
Cache-Control: public, max-age=31536000, immutable

Vengiu prieštaringų specifikacijų, pavyzdžiui, no-cache kartu su immutable. Aiškios taisyklės sukuria nuoseklius rezultatus visoje hierarchijoje.

Suspaudimas, HTTP/2/3 ir prioritetų nustatymas

Įjungiu "Gzip/Brotli" ir teisingai nustatau "Vary" antraštę, kad variantai būtų švariai atskirti. Naudodamasis HTTP/2/3, naudojuosi multipleksavimo ir prioritetų nustatymo galimybėmis; tai sumažina eilutės blokavimą, kai lygiagrečiai įkeliama daug išteklių.

# NGINX pavyzdys
gzip įjungtas;
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" visada;

# Ilgas naršyklės turto TTL
vieta ~* .(css|js|svg|woff2|jpg|png)$ {
  galioja 1m;
  add_header Cache-Control "public, max-age=31536000, immutable";
}

Autentiškumo nustatymas, slapukai ir saugumas

Niekada viešai neskelbiu asmeninio turinio. Užklausas su autorizavimo antraštėmis arba sesijos slapukais žymiu kaip privačias arba specialiai apeinu kraštinę talpyklą. Tuo pačiu metu į baltąjį sąrašą įtraukiu tik svarbiausius slapukus, kad talpyklos raktas išliktų taupus.

• Prisijungimo / paskyros sritys: talpyklos valdymas: privatus arba be saugojimo.
• Vieši HTML puslapiai: vieši, s-maxage; vengti nustatyti slapuką.
• Slapukų higiena: pašalinkite iš rakto nereikšmingus slapukus (pvz., sekimo).

// Į VCL panaši logika
if (req.http.Authorisation) { return(pass); }
if (req.http.Cookie ~ "session=") { return(pass); }
// Tik reikalingi slapukai rakte
unset req.http.Cookie: ".*";

Efektyviai talpinkite API ir paieškos galinius taškus į talpyklą

Griežtai skiriu metodus: GET galima talpinti į spartinančiąją atmintinę, o POST - paprastai ne. Dažnoms paieškos užklausoms nustatau trumpas s-maxage reikšmes ir stale-while-revalidate, kad išlygintų atsakymo laiką. Atsakymus su 4xx/5xx klaidomis talpinu į spartinančiąją atmintinę tik trumpai arba iš viso jų nekešu, kad pataisymai įsigaliotų iš karto.

// Viešosios GET API antraštės pavyzdys
Cache-Control: public, max-age=0, s-maxage=120, stale-while-revalidate=30

// Klaidas talpinkite į talpyklą retai
Cache-Control: public, s-maxage=10

Stebimumas: antraštės, žurnalai ir TTFB tikrinimas

Naudoju antraštės patikrinimą ir žurnalus, kad grandinė būtų skaidri. Amžius, pataikymo/nepataikymo rodikliai ir būsena prieš srovę rodo, kur prarandamas laikas. Naudoju paprastas priemones, kad galėčiau pakartotinai patikrinti TTFB ir rasti nukrypimus.

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

Patikrinkite # antraštę
curl -I https://example.org | sed -n '1,20p'

# NGINX žurnalas su talpyklos būkle
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;

Lyginu žurnalo duomenis su diegimais ir valymais. Didelės praleistų duomenų viršūnės iškart po paleidimų rodo, kad trūksta apšilimo arba TTL yra per trumpi. Jei "Age" išlieka nuolat mažas, patikrinu, ar slapukai netyčia neaplenkia kraštinės talpyklos.

Diegimas: versijų kūrimas ir valymas

Į failų pavadinimus įtraukiu versijas (pvz., app.9f3c1.js), kad naršyklės spartinančioji atmintinė būtų agresyvi. HTML atveju naudoju slenkančius valymus, kai pirmiausia atnaujinami svarbiausi puslapiai, o po to - giluminiai ir ilgalaikiai puslapiai. Mėlynos ir žalios spalvos diegimai atskiria kūrimą nuo išleidimo ir suteikia man laiko specialiai apšildyti talpyklas.

// Turto vamzdynas
style.[hash].css
app.[hash].js
// HTML visada nurodo naujas hashes

Planuoju valymo langus ne piko metu ir iškart po to stebiu pataikymo rodiklį. Taip išvengiu "Origin" apkrovos pikų.

Paveikslėlių variantai, DPR ir jautrioji spartinančioji atmintinė

Vaizdų variantus (dydis, formatas) generuoju deterministiškai, kad talpyklos raktas išliktų stabilus. WebP/AVIF variantus aiškiai atskiriu per failo kelią arba parametrus, o ne tik per "Accept" antraštes, kad išvengčiau "Vary" sprogimų. Didelės raiškos ekranams (DPR) naudoju srcset/sizes, todėl naršyklė gali pasirinkti geriausią variantą, o talpykla įsigalioja kiekvienam konkrečiam turtui.

<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="">

Stengiuosi, kad vieno motyvo variantų skaičius būtų nedidelis, o pasenusius dydžius išvalau iš vamzdyno, kad talpykla nebūtų fragmentuota.

Talpos planavimas: talpyklos atmintis ir objektų dydžiai

Dydį kešu pagal realius prieigos modelius: keliems dideliems objektams (paveikslėliams, vaizdo įrašams) reikia kitokių strategijų nei daugeliui mažų objektų (HTML, JSON). Nustatau didžiausio objekto dydžio ribas ir tikrinu, ar populiarūs objektai lieka atmintyje. Didelis pakartotinio naudojimo rodiklis yra svarbesnis už absoliutų dydį; todėl apkarpau raktus, sujungiu variantus ir neleidžiu dubliuotis.

// Pavyzdys: ribos
max_object_size = 10m
numatytasis_ttl = 600
nuke_limit = vidutinio sunkumo (iškeldinimas be stabdžių)

Praktinis įgyvendinimo kontrolinis sąrašas

Aktyvuoju OPcache su pakankamu kiekiu atminties ir patikrinkite pataikymo dažnį. Tada nustatau puslapio spartinančiąją atmintinę, pašalinu kritinius kelius ir iš anksto įkeliu svarbius URL adresus. Tada nustatau naršyklės antraštes su ilgais laikais nekeičiamiems failams ir versijų nustatymui. CDN nustatau talpyklos raktus, TTL ir išvalymo strategijas bei įjungiu funkciją stale-while-revalidate. Galiausiai naudoju matavimo priemones, kad patikrinu, ar TTFB, LCP ir "edge hit rate" pasiekia tikslus.

Trumpa santrauka

Aš naudoju Spartinančioji atmintinė hierarchinis: "OPcache" pagreitina kodą, puslapio talpykla pateikia HTML, naršyklės antraštės išlaiko vietinius išteklius, o "Edge" turinį priartina prie naudotojų. Naudodamas aiškius raktus, tinkamus TTL ir sumanų panaikinimą, mažinu serverio apkrovą, pralaidumą ir vėlavimą. Išmatuotos vertės užtikrina pažangą ir parodo optimizavimo potencialą. Taip sukuriama patikima grandinė nuo kilmės iki galutinio įrenginio. Kiekvienas, ieškantis papildomos informacijos apie visuotinį pristatymą, ras pakankamai praktinių atspirties taškų, kad savo architektūrą padarytų pastebimai greitesnę.