Böngésző gyorsítótárazási (Browser Caching) időtartamok beállítása lépésről lépésre

A böngésző gyorsítótárazás (böngésző cache) időtartamai olyan HTTP gyorsítótár-szabályokkal állíthatók be, amelyek meghatározzák, hogy webhelye statikus fájljai mennyi ideig tárolódjanak a látogató böngészőjében. A gyakorlatban CSS, JavaScript, kép, betűkészlet és ikon fájlok esetében Cache-Control, illetve bizonyos környezetekben Expires fejléceket definiálunk; például verziózott CSS és JS fájloknál 1 év, képeknél 30 nap-1 év, HTML oldalaknál pedig rövid időtartam vagy újraérvényesítés javasolt. A megfelelő beállítás megakadályozza ugyanazon fájlok ismételt letöltését, felgyorsítja az oldalbetöltést és javítja a Core Web Vitals mutatókat.

Ebben az útmutatóban lépésről lépésre elmagyarázzuk, hogyan működik a böngésző gyorsítótárazás, melyik fájltípushoz hány másodpercet érdemes rendelni, valamint hogyan valósítható meg Apache, Nginx, LiteSpeed, WordPress és CDN környezetben. A cél nem csupán egy zöld pontszám elérése egy sebességtesztelő eszközben; hanem az, hogy miközben friss fájlokat szolgálunk ki a felhasználónak, hatékonyan használjuk a szerver erőforrásokat, csökkentsük a TTFB-t és a sávszélesség-fogyasztást, és érezhető sebességnövekedést érjünk el a visszatérő látogatások során. Különösen megosztott tárhely, WordPress tárhely és vállalati webes projektek esetében a megfelelő gyorsítótár-stratégia az egyik leghatékonyabb teljesítményjavítás, amit alacsony költséggel el lehet érni. Hostragons web hosting csomagok

Mi az a Böngésző Gyorsítótárazás?

A böngésző gyorsítótárazás az a folyamat, amikor egy weboldal megnyitásakor letöltött statikus erőforrások ideiglenesen tárolódnak a felhasználó eszközén. Amikor egy látogató megnyitja a kezdőlapját, a logó, a CSS fájl, a JavaScript fájlok, a betűkészletek és a képek letöltődnek. Ha ezekhez a fájlokhoz megfelelő gyorsítótár fejlécek vannak társítva, a látogató a második oldalra lépve vagy később visszatérve a webhelyre, a böngésző ezek egy részét nem kéri le újra a szervertől. Így az oldal gyorsabban töltődik be.

Vegyünk például egy 2 MB méretű kezdőlapot. Ha ennek 1,4 MB-ja képekből, 300 KB-ja CSS és JS fájlokból, 100 KB-ja pedig betűkészletekből áll, ezek az erőforrások az első látogatáskor letöltődnek. A második látogatáskor azonban, amikor a böngésző ezeket a statikus erőforrásokat helyileg használja, a hálózaton átvitt adatmennyiség drámaian lecsökken. Ez a különbség mobilkapcsolatok és nagy forgalmú webhelyek esetében még hangsúlyosabbá válik.

A böngésző gyorsítótárazást nem szabad összekeverni a szerveroldali gyorsítótárazással. A szerveroldali cache a PHP kimenetet vagy az adatbázis-lekérdezéseket tárolja a szerveren. A böngésző cache ezzel szemben a látogató eszközén lévő erőforrások újrafelhasználását teszi lehetővé. A legjobb teljesítmény érdekében a két réteget együtt kell megtervezni. WordPress-t használó webhelyeken az oldal cache, az objektum cache, a CDN cache és a böngésző cache általában ugyanannak az optimalizálási stratégiának a részei. WordPress tárhely és teljesítmény optimalizálás

Miért Fontos a Böngésző Gyorsítótárazás a SEO Szempontjából?

A Google a gyors és stabil élményt nyújtó webhelyeket a felhasználói elégedettség szempontjából értékesebbnek tartja. A böngésző gyorsítótárazás önmagában nem garantál jobb helyezést; azonban mivel hatással van az oldalsebességre, a késleltetésre és az erőforrás-betöltés hatékonyságára, támogatja a SEO teljesítményt. Különösen a visszatérő látogatások, a kategóriaböngészés, a termékoldalak közötti navigáció és a blogon belüli mozgás során jelent komoly előnyt.

A 2026-os SEO szabványokban a technikai teljesítmény nem csupán a Lighthouse pontszámból áll. A Google által értékelt felhasználói élmény az LCP-hez, INP-hez, CLS-hez, TTFB-hez és valós felhasználói adatokhoz kapcsolódik. A CSS és JS fájlok felesleges ismételt letöltése megnövelheti az LCP időt. A betűkészletek minden oldalon történő újra lekérése befolyásolhatja a vizuális stabilitást. A nagyméretű képek gyorsítótárazásának hiánya lassúság érzetét keltheti a mobilfelhasználóban.

• Gyorsabb visszatérő látogatás: A felhasználó nem tölti le újra ugyanazokat a fájlokat.
• Alacsonyabb sávszélesség-igény: A szerverterhelés csökken, a tárhely erőforrások hatékonyabban hasznosulnak.
• Jobb feltérképezési hatékonyság: A botok és a felhasználók számára a statikus erőforrások kiszolgálása rendezettebbé válik.
• Alacsonyabb visszafordulási arány: A gyorsan betöltődő oldalak növelik a felhasználói interakciót.
• Következetesebb teljesítmény: A CDN és a tárhely oldali terhelési ingadozások jobban kiegyensúlyozhatók.

Alapvető HTTP Gyorsítótár Fejlécek

A böngésző gyorsítótárazási időtartamokat a HTTP válaszfejlécek kezelik. A leggyakoribb fejlécek a Cache-Control, Expires, ETag és Last-Modified. A modern projektekben a fő vezérlési pont a Cache-Control fejléc; az Expires-t inkább a visszafelé kompatibilitás miatt használják.

Cache-Control

A Cache-Control megmondja a böngészőnek és a köztes gyorsítótár-rendszereknek, hogyan tároljanak egy fájlt. A leggyakrabban használt direktívák a következők:

• max-age: Meghatározza, hogy az erőforrás hány másodpercig tekinthető frissnek. Például a max-age=31536000 körülbelül 1 év.
• public: Jelzi, hogy az erőforrás tárolható a böngészőben és megosztott gyorsítótár-rendszerekben, például CDN-ben.
• private: Jelzi, hogy az erőforrást kizárólag a felhasználó böngészőjében szabad tárolni.
• no-cache: Azt jelzi, hogy az erőforrást a felhasználás előtt ellenőriztetni kell a szerverrel; ez nem jelenti a gyorsítótárazás teljes kikapcsolását.
• no-store: Azt jelzi, hogy az erőforrást sehol sem szabad tárolni; fizetési, adminisztrációs és személyes adatokat tartalmazó oldalakhoz ideális.
• immutable: Azt jelzi, hogy az erőforrás a lejáratáig nem fog megváltozni; ideális verziózott fájlnevű elemekhez.

Egy példa statikus fájl fejléc így nézhet ki: Cache-Control: public, max-age=31536000, immutable. Ez azt mondja a böngészőnek, hogy a fájlt 1 évig tárolhatja, és amíg a fájlnév nem változik, nem szükséges újra ellenőriznie.

Expires

Az Expires fejléc meghatározza, hogy az erőforrás mely dátumig és időpontig érvényes. Például egy képhez rendelhető egy 30 nappal későbbi dátumot mutató Expires érték. Azonban mivel az Expires abszolút dátumot használ, nem olyan rugalmas, mint a Cache-Control. A modern konfigurációkban a Cache-Control élvez elsőbbséget; az Expires pedig a régebbi böngészők számára adható hozzá.

ETag és Last-Modified

Az ETag és a Last-Modified érvényesítési mechanizmusok. A böngésző megkérdezheti a szervertől, hogy a birtokában lévő fájlverzió naprakész-e. Ha a fájl nem változott, a szerver 304 Not Modified választ küld vissza, és a fájl törzse nem töltődik le újra. Ez a módszer különösen hasznos a gyakran változó tartalmak, például HTML esetében, vagy olyan fájloknál, amelyekhez nem szeretne hosszú gyorsítótár-időt rendelni.

Melyik Fájltípushoz Milyen Gyorsítótárazási Időtartamot Használjunk?

A leggyakoribb hiba az, hogy minden fájltípushoz ugyanazt az időtartamot rendelik. Pedig a HTML, CSS, JS, képek, betűkészletek és API válaszok eltérő frissítési viselkedéssel rendelkeznek. Az alapszabály egyszerű: Ha a fájlnév megváltoztatható, hosszú gyorsítótár-idő adható; ha a fájlnév változatlan, de a tartalma gyakran változik, rövid időtartamot vagy érvényesítést kell használni.

Ez a táblázat egy általános kiindulási pont. Egy e-kereskedelmi webhelyen a készlet- és árinformációkat tartalmazó HTML oldalakat nem szabad agresszíven gyorsítótárazni. Ezzel szemben a termékképek a fájlnév megváltoztatása mellett 1 évig gyorsítótárazhatók. Egy vállalati webhelyen a logó, betűkészlet és témafájlok hosszú ideig tárolhatók; azonban ha a kampánybannerek gyakran változnak, 7-30 nap biztonságosabb lehet.

Hogyan Tervezzük Meg a Böngésző Gyorsítótárazási Időtartamokat?

A sikeres gyorsítótár-stratégiához először osztályozza a webhelyén lévő fájlokat. Technikailag fájlkiterjesztések alapján kell szabályokat írni; stratégiailag pedig a frissítési gyakoriság alapján kell meghatározni az időtartamot.

1. Válassza szét a statikus és dinamikus erőforrásokat

A CSS, JS, JPG, PNG, WebP, SVG, WOFF2 fájlok statikus erőforrások. A HTML, kosár, felhasználói fiók, keresési eredmények és API válaszok dinamikusnak tekintendők. A statikus erőforrások hosszú ideig gyorsítótárazhatók, míg a dinamikus tartalmakat körültekintőbben kell kezelni. Különösen a felhasználóra szabott tartalmaknál nem szabad public gyorsítótárat használni.

2. Használjon fájlverziózást

A hosszú gyorsítótár-idő biztonságos módja a fájlverziózás. Ha például a style.css fájlt 1 évre gyorsítótárazza, majd megváltoztatja a tartalmát, néhány felhasználó továbbra is a régi dizájnt láthatja. Ehelyett, ha olyan elnevezést használ, mint a style.2026.01.css, app.v12.js vagy a fájl hash-ét tartalmazó app.8f3a2.js, a frissítés pillanatában az új fájlnév kerül közzétételre, és a böngésző letölti az új erőforrást.

A WordPress témák és a modern build eszközök ezt automatikusan elvégezhetik. Ha témát fejleszt, a wp_enqueue_style és wp_enqueue_script függvényekben a version paraméter használata megkönnyíti a verziókezelést query string vagy fájlnév segítségével. Egyes CDN konfigurációkban azonban a query string gyorsítótár-viselkedése eltérő lehet, ezért a hash fájlnévhez adása robusztusabb módszer.

3. Ne viselkedjen agresszíven a HTML-lel

A HTML oldalak, mivel a felhasználó számára látható tényleges tartalmat hordozzák, általában rövid távú gyorsítótárral vagy újraérvényesítéssel kezelendők. Blogbejegyzéseknél 5-10 perc gyorsítótár elegendő lehet; hír-, kampány- vagy ároldalaknál rövidebb idő szükséges. Ha WordPress-ben oldal gyorsítótárat használ, a böngésző gyorsítótár fejlécét a szerver cache-szel és a CDN purge mechanizmussal együtt kell átgondolnia.

4. Kapcsolja ki a gyorsítótárat a biztonságot igénylő oldalakon

A bejelentkezési oldalon, ügyfélfiókban, fizetési lépéseknél, rendelési összesítőn, számlán és személyes adatokat tartalmazó oldalakon a Cache-Control: no-store, private fejléceket kell előnyben részesíteni. A böngésző gyorsítótárazás a teljesítményt szolgálja; de nem veszélyeztetheti a személyes adatok biztonságát. Az SSL használata ezen a ponton alapvető követelmény. Hostragons SSL tanúsítványok

Böngésző Gyorsítótárazás Beállítása Apache .htaccess Segítségével

Apache szervereken a böngésző gyorsítótárazás általában az .htaccess fájlon keresztül állítható be. A megosztott tárhelyet használó webhelytulajdonosok többsége számára ez a legpraktikusabb módszer. Először a mod_expires és mod_headers moduloknak aktívnak kell lenniük. A legtöbb minőségi tárhelykörnyezetben ezek a modulok alapértelmezetten elérhetők.

A következő logikát használhatja: képekhez és betűkészletekhez hosszú idő, CSS-hez és JS-hez hosszú idő, HTML-hez rövid érvényesítés. Az .htaccess fájlhoz hozzáadandó szabályokban a fájltípusok szerint ExpiresByType és Header set Cache-Control definíciókat kell megadni. Például image/webp, image/jpeg, image/png, image/svg+xml fájlokhoz 1 év; text/css és application/javascript fájlokhoz 1 év; text/html fájlokhoz no-cache alkalmazható.

A végrehajtás előtt készítsen biztonsági másolatot az .htaccess fájlról. Egy hibásan megírt szabály 500 Internal Server Error hibát okozhat. A módosítás után nyissa meg a webhelyet inkognitó ablakban, majd a DevTools Network fülén ellenőrizze az adott fájl response headers szakaszát. Ha a Cache-Control nem látható, lehet, hogy a szervermodul ki van kapcsolva, a CDN felülírja a fejlécet, vagy egy másik bővítmény írja felül a fejléceket.

Apache oldalon példa időtartamok: CSS és JS esetén max-age=31536000, képeknél max-age=31536000, PDF-nél max-age=2592000, HTML-nél max-age=0 és no-cache. Ezek az értékek jók kiindulásnak; a webhelye tartalomfrissítési ütemétől függően felül kell vizsgálni. A Hostragons tárhely infrastruktúráján az .htaccess-en keresztül elvégezhető teljesítménybeállítások használatakor ajánlott ellenőrizni, hogy nincs-e ütközés a téma és a bővítmények gyorsítótár-beállításaival. Apache .htaccess teljesítménybeállítások

Böngésző Gyorsítótár Beállítások Nginx-szel

Nginx-et használó szervereken a gyorsítótár fejléceket a server vagy location blokkokon belül kell definiálni. Az Nginx-et nagy teljesítményű statikus fájlkiszolgálása miatt különösen a nagy forgalmú projekteknél részesítik előnyben. Az alapelv itt az, hogy kiterjesztés-alapú location szabállyal határozzuk meg az expires és add_header Cache-Control értékeket.

Egy példa megközelítés a következő: a statikus erőforrásokhoz, mint CSS, JS, WebP, JPG, PNG, SVG, WOFF2, expires 1y és Cache-Control public, immutable kerül megadásra. A HTML kimenetekhez expires off vagy no-cache javasolt. Ha CDN-t használ, tesztelnie kell azt is, hogy az origin szerverről érkező Cache-Control fejléceket hogyan értelmezi a CDN.

Az Nginx beállításoknál figyelni kell arra, hogy az add_header direktíva bizonyos esetekben csak meghatározott válaszkódokra vonatkozik. A modern Nginx konfigurációkban az always paraméter használható. Továbbá, ha ugyanazt a fejlécet az alkalmazás, az Nginx és a CDN is hozzáadja, ütköző vagy duplikált Cache-Control értékek keletkezhetnek. Ebben az esetben az elsőbbségi láncot tisztázni kell, és egyetlen forrást kell mérvadóként kijelölni.

Gyorsítótárazás LiteSpeed és WordPress Webhelyeken

A LiteSpeed szerverek, különösen WordPress projektekben, a LiteSpeed Cache bővítménnyel erőteljes teljesítményelőnyt kínálnak. A böngésző gyorsítótárazást és az oldal gyorsítótárat azonban el kell különíteni egymástól. A LiteSpeed Cache bővítményben a Browser Cache opció aktiválásakor a statikus fájlok gyorsítótár-fejlécei automatikusan alkalmazhatók. Ennek ellenére fontos ellenőrizni az időtartamokat.

WordPress-ben a javasolt gyakorlat a statikus elemek hosszú távú gyorsítótárazása és a fájlverziózás aktívan tartása. Amikor témát frissít, CSS-t vagy JS-t módosít, a bővítmény gyorsítótárát üríteni kell, és ha CDN-t használ, a CDN purge műveletet is végre kell hajtani. Ellenkező esetben néhány felhasználó régi dizájnnal vagy hibás JavaScript viselkedéssel találkozhat.

A népszerű gyorsítótár bővítményekben olyan lehetőségek találhatók, mint a Browser Cache, Minify, Combine, Critical CSS, CDN integráció és Object Cache. Nem mindig helyes mindet egyszerre, agresszíven bekapcsolni. Először a böngésző gyorsítótár fejléceit állítsa be, majd tesztelje a minify és combine beállításokat. 2026-ban, mivel a HTTP/2 és HTTP/3 elterjedt, minden fájl összekapcsolása nem annyira kritikus, mint a régebbi időkben; sőt, bizonyos esetekben csökkentheti a gyorsítótár hatékonyságát.

Ha WordPress webhelye lassú, a probléma nem csupán a böngésző cache hiánya lehet. Az adatbázis felduzzadása, a nehéz téma, a túl sok bővítmény, a nem optimalizált képek és az alacsony erőforrású tárhely szintén befolyásolják a teljesítményt. Ezért a gyorsítótárazási beállításokat minőségi tárhellyel, naprakész PHP verzióval és megfelelő SSL konfigurációval együtt értékelje. Hostragons WordPress hosting

Hogyan Állítsuk Be a Gyorsítótár Időtartamokat CDN Használatakor?

A CDN a statikus fájljait a felhasználóhoz földrajzilag közel eső edge szerverekről szolgálja ki. A böngésző cache pedig a fájlt a felhasználó böngészőjében tárolja. Amikor ez a két réteg együtt dolgozik, a teljesítménynövekedés még szembetűnőbb. A CDN panelen beállított edge cache időtartamnak és az origin szerveren lévő Cache-Control fejléceknek azonban összhangban kell lenniük.

Az általános megközelítés a következő lehet: Az origin szerveren adjon a statikus fájlokhoz 1 év Cache-Control-t, és a CDN-ben is definiáljon egy azonos vagy kontrollált TTL-t. Fájlváltozások esetén verziózza a fájlnevet, vagy végezzen CDN purge-ot. HTML oldalaknál, ha CDN gyorsítótárat használ, hozzon létre egyedi szabályokat; a kosár, fiók, fizetés és adminisztrációs panel területeit feltétlenül zárja ki a gyorsítótárból.

A CDN-t használó webhelyeken gyakori probléma, hogy a frissítés után a régi fájlok látszanak. Ennek oka általában az, hogy a fájlnév megváltoztatása nélkül módosul a tartalom, vagy nem történik CDN purge. A legbiztosabb módszer a build folyamat során hash-elt fájlok előállítása és az új fájlnév meghívása a HTML-ben. Így még ha a böngésző és a CDN a régi fájlt tárolja is, az új oldal az új fájlt fogja kérni.

Lépésről Lépésre Alkalmazási Ellenőrzőlista

Az alábbi ellenőrzőlista egy gyakorlati alkalmazási tervet kínál a böngésző gyorsítótárazási időtartamokhoz. Egy kis vállalati webhelyen 30-60 perc alatt megvalósítható; e-kereskedelmi vagy egyedi szoftver projekteknél a tesztelési idő hosszabb lehet.

• 1. Készítsen fájlleltárt: Válassza szét a CSS, JS, kép, betűkészlet, PDF, HTML és API válaszokat.
• 2. Határozza meg a frissítési gyakoriságot: Jegyezze fel, mely fájlok változnak naponta, melyek havonta egyszer.
• 3. Válasszon verziózási stratégiát: Használjon fájlnév hash-t, verzió paramétert vagy build számot.
• 4. Adja hozzá a szerver szabályokat: Definiálja a Cache-Control fejléceket az Apache, Nginx, LiteSpeed vagy CDN panelen.
• 5. Zárja ki a biztonságos oldalakat: Használjon no-store-t az admin, fizetési, kosár, felhasználói fiók és személyes adat oldalakon.
• 6. Teszteljen: Ellenőrizze Chrome DevTools, curl -I, WebPageTest, Lighthouse és valós eszközökön végzett tesztekkel.
• 7. Kövesse nyomon a közzététel után: Ellenőrizze, hogy van-e hibás régi fájl, törött dizájn vagy JS hiba.

Hogyan Teszteljük a Böngésző Gyorsítótárazást?

A beállítások működésének leggyorsabb módja a böngésző fejlesztői eszközeinek használata. Chrome-ban nyissa meg az oldalt, lépjen a DevTools Network fülére, kattintson egy CSS vagy kép fájlra, és vizsgálja meg a Cache-Control értéket a Response Headers szakaszban. A második betöltéskor a Status oszlopban a memory cache vagy disk cache kifejezéseket láthatja.

Ha parancssort használ, a curl -I azonositod.hu/fajl.css parancs megmutatja a válaszfejléceket. Itt ellenőrizheti a Cache-Control, Expires, ETag és Last-Modified értékeket. Ha a várt fejléc hiányzik, lehet, hogy az alkalmazás, a webszerver vagy a CDN rétegek egyike megváltoztatta a beállítást.

Teljesítményteszteléshez használható a Lighthouse, a PageSpeed Insights és a WebPageTest. Azonban ezen eszközök javaslatait ne vakon alkalmazza, hanem valós felhasználói forgatókönyv alapján értékeljen. Például a Lighthouse hosszú gyorsítótár-időt javasol a statikus fájlokhoz, de nem várja el ugyanezt az agresszivitást a HTML oldalaktól. Ezenkívül a teszteszközök néha harmadik féltől származó szkriptekre is figyelmeztetnek; a Google Fonts, hirdetési hálózatok vagy közösségi média szkriptek gyorsítótár-idejét Ön nem feltétlenül tudja szabályozni.

Gyakori Hibák

A böngésző gyorsítótárazás egyszerűnek tűnhet, de helytelen konfigurálás esetén frissítési problémákat, biztonsági kockázatokat és felhasználói élménybeli gondokat okozhat. Az alábbi hibák különösen gyakoriak a kezdőknél.

• 1 év gyorsítótár adása minden erőforrásnak: A HTML, API válasz és felhasználóra szabott tartalmak nem tartozhatnak ebbe a körbe.
• Hosszú gyorsítótár használata fájlverziózás nélkül: A felhasználók továbbra is a régi CSS vagy JS fájlokat láthatják.
• A CDN purge folyamat elfelejtése: Még ha az origin frissül is, a CDN a régi fájlt szolgálhatja ki.
• Több gyorsítótár bővítmény egymásra halmozása: Több bővítmény ugyanazokat a fejléceket írhatja, ütközéseket okozva.
• Harmadik féltől származó figyelmeztetések félreértelmezése: A külső forrásból származó szkriptek gyorsítótár-fejlécei nem biztos, hogy az Ön ellenőrzése alatt állnak.
• Biztonságos oldalak gyorsítótárazása: A fizetési és fiók oldalakon no-store-t kell használni.

Javasolt Kiindulási Értékek

Egy új webhely biztonságos kiindulási értékei a következőképpen foglalhatók össze: CSS és JS fájlok, ha verziózottak, 1 év; képek 1 év, a gyakran változó kampányképek 30 nap; betűkészletek 1 év; PDF fájlok a frissítési gyakoriságtól függően 7-180 nap; HTML oldalak pedig no-cache vagy néhány perces rövid időtartam. Ez a megközelítés megőrzi az egyensúlyt a teljesítmény és a frissesség között.

Ha webhelye vállalati bemutatkozó oldal, a hosszú gyorsítótár-idők általában problémamentesek. Ha e-kereskedelmi webhelyről van szó, a termékoldalon lévő statikus fájlokhoz adhat hosszú gyorsítótárat, de az árat, készletet, kosarat és felhasználói adatokat ki kell zárnia a gyorsítótárból. Ha hír- vagy blogwebhelyről van szó, a képeket és témafájlokat hosszú ideig tárolhatja, a HTML kimenetet pedig a közzététel gyakoriságától függően rövid távon gyorsítótárazhatja. A domain neve, SSL és tárhely infrastruktúrája is része a teljesítményláncnak. Hostragons domain ellenőrzés Hostragons céges hosting megoldások

Összegzés

A böngésző gyorsítótárazási időtartamok, ha megfelelően vannak megtervezve, jelentősen növelik webhelye visszatérő látogatások alatti teljesítményét. Az alapszabály: a verziózott statikus fájlokhoz hosszú időtartam, a HTML és személyes adatokat tartalmazó oldalakhoz rövid időtartam vagy no-store alkalmazása. Apache, Nginx, LiteSpeed, WordPress és CDN környezetekben ugyanaz a logika érvényes: ismerje fel az erőforrás típusát, határozza meg a frissítési gyakoriságot, tesztelje a Cache-Control fejléceket, és a közzététel után is kövesse nyomon a működést.

Röviden, a böngésző gyorsítótárazás egy alacsony költségű, de nagy hatású sebességoptimalizálás. Ha webhelyét a Hostragons infrastruktúrán üzemelteti, a tárhelytípusának megfelelő gyorsítótár-beállítások kiválasztásával erősítheti mind a felhasználói élményt, mind a technikai SEO teljesítményt. Az igényeinek legmegfelelőbb tárhelymegoldás értékeléséhez tekintse meg a Hostragons tárhely lehetőségeit, vagy lépésről lépésre ellenőrizze meglévő webhelye gyorsítótár-konfigurációját. Hostragons hosting csomagok

Gyakran Ismételt Kérdések

Mennyi legyen a böngésző gyorsítótárazási időtartam?

CSS, JS, kép és betűkészlet típusú verziózott statikus fájlok esetében a 30 nap és 1 év közötti időtartam az ideális. HTML oldalaknál, mivel a tartalom frissessége fontos, a no-cache, max-age=0 vagy néhány perces rövid időtartam javasolt.

Mi a különbség a Cache-Control és az Expires között?

A Cache-Control egy modern és rugalmasabb HTTP fejléc; másodperc alapú szabályokat használ, mint a max-age. Az Expires ezzel szemben egy konkrét dátum-idő értéket ad meg. A jelenlegi projektekben a Cache-Control-t kell előnyben részesíteni, az Expires-t pedig a visszafelé kompatibilitás érdekében lehet hozzáadni.

Hogyan kapcsolható be a böngésző gyorsítótárazás WordPress-ben?

Az olyan bővítményekben, mint a LiteSpeed Cache, WP Rocket, W3 Total Cache, a Browser Cache vagy böngésző gyorsítótár opció aktiválható. Ezenkívül az .htaccess vagy a szerver konfiguráció segítségével fájltípusonként Cache-Control fejlécek adhatók hozzá.

Ha hosszú gyorsítótár-időt adok meg, nem fognak látszani a webhely frissítései?

Ha a fájlnév megváltoztatása nélkül frissíti ugyanazt a CSS vagy JS fájlt, néhány felhasználó a régi fájlt láthatja. Ennek megelőzésére fájlverziózást, hash-elt fájlneveket és CDN purge műveletet kell használni.

A fizetési és felhasználói fiók oldalakat gyorsítótárazni kell?

Nem. A fizetési, kosár, fiók, számla és adminisztrációs panel típusú, személyes adatokat tartalmazó oldalakon olyan biztonságos fejléceket kell használni, mint a Cache-Control: no-store, private. A teljesítményért nem szabad feláldozni a biztonságot.