A webhely gyorsítótár-vezérlési beállításainak bevált gyakorlata

Lehet, hogy észrevette, hogy néha, amikor egy webhelyre másodszor lép fel, az nem úgy néz ki, ahogy várták, és egyes stílusok megsérülnek, így minden furcsanak tűnik. Általában a probléma oka a rosszul definiált gyorsítótár-kezelési házirendek, amelyek megakadályozzák, hogy a legfrissebb módosításokat megkapja a legutóbbi telepítés után. Ebben a cikkben megmutatom a megfelelő gyorsítótár-beállításokat és technikákat, amelyek segítenek webhelyének minden felhasználói telepítés utáni naprakészen tartásában.

Azoknak, akik csak a legjobb gyakorlatokat szeretnék megismerni és elkezdenek használni, kövesse az itt található linket a cikk végéhez.

Hogyan működik a gyorsítótár a színfalak mögött?

A böngésző minden egyes weboldalra / erőforrásra vonatkozó kéréskor megpróbálja a lehető legkevesebb adatot betölteni azáltal, hogy a helyi memóriából tárolja a gyorsítótárazott információkat. Ez csak akkor lehetséges, ha elegendő utasítást adunk a böngészőnek, hogy elmagyarázzuk, milyen erőforrásokat kell megőriznie és mennyi ideig.

Ezek az utasítások irányelvekként szolgálnak; Hogy elmondhassa böngészőjét róluk, hozzá kell adnia őket a válasz HTTP fejléc információihoz. A gyorsítótár-folyamatban leggyakrabban használt irányelvek a “Cache-Control”, “Expires”, “Etag” és “Last-Modified”.

Szinte minden webszerver alapértelmezés szerint tartalmaz néhány gyorsítótár-beállítást a fejlécválaszokban, de nem egyértelmű, hogy mit kapunk, ha nincs cache-irányelv.

Gyorsítótár-vezérlő beállítások nélkül a böngésző minden erőforrás-igényléshez a webkiszolgálóra lép, és beolvassa az információkat. Ez megnöveli az érintett webhely betöltési idejét, extra terhelést jelent a webkiszolgálóra az információk átvitelekor, és növeli a háttérhívások számát.

Folytatást kér gyorsítótár-beállítások nélkül

A böngésző dönti el, hogy mit kell tennie és hogyan tárolhatja az információkat a kiszolgáló utasításai nélkül. Jelenleg a Chrome és a Safari minden alkalommal tölti le az adatokat a háttérrendszerről, gyorsítótár-utasítások nélkül. Ez változhat, és eltérő viselkedéshez vezethet, főleg más platformon.

Annak pontos meghatározása érdekében, hogy mit kell tenni bizonyos fájlokkal, mélyebbre merüljünk a gyorsítótár-vezérlő irányelvek megismerésében, lépésről lépésre adva a válaszfejlécekhez, és figyelve az eredményt.

Etag (Entity tag)

Az Etag az egyik gyorsítótár-beállítás. Ennek a HTTP fejlécnek az a fő gondolata, hogy lehetővé tegye böngészőjének, hogy a teljes fájlok letöltése nélkül tisztában legyen a releváns erőforrások módosításával. A szerver kiszámíthat valami hasonlót az egyes fájlok hash összegével, majd elküldi ezt a hash összeget az ügyfélnek. A következő alkalommal, amikor az ügyfél megpróbálja hozzáférni ehhez az erőforráshoz, a fájl letöltése helyett, a böngésző ehhez hasonlót küld a HTTP fejlécben: Ha nincs-egyezés: W / “1d2e7–1648e509289”. A szerver ezt követően ellenőrzi ezt a hash-összeget az aktuális fájl hash-összegével szemben, és ha van különbség, arra kényszeríti az ügyfelet, hogy töltsön le egy új fájlt. Ellenkező esetben a klienst értesítik arról, hogy tárolt verziót kell használnia.

Áramlást kér az Etag segítségével - 1. terhelésÁramlást kér az Etag segítségével - 2. terhelés

Bekapcsolt Etag-gyorsítótár-házirend mellett mindig a kiszolgálón megyünk ellenőrizni egy fájl kivonatösszegét, és csak ezután a böngésző úgy dönt, hogy eltávolítja azt a gyorsítótárból, vagy tölti be teljesen. Ha egy erőforrást nem módosítottak, mindössze 80–100 bájt szükséges az ellenőrzéshez, függetlenül attól, hogy mit kér - 10KB vagy 10 MB fájlt.

Utoljára módosítva

Egy másik gyorsítótár-vezérlő beállítás az „Utoljára módosított” HTTP fejléc. A fő ötlet nagyon hasonlít az Etag-hoz, de a böngésző viselkedése kissé eltér. A kiszolgálók rendelkeznek az egyes fájlok utoljára módosított dátumának időbélyegével; az első fájl betöltése után az ügyfél megkérdezheti a kiszolgálót, hogy az erőforrást módosították-e az a pillanat, mióta a fájlokat az ügyfél utoljára elérte. Ehhez a böngésző If-Modified-Since-től: 2018. július 13., 10:49:23 GMT-t küld a HTTP fejlécbe. Ha az erőforrás módosult, a böngészőnek új fájlt kell letöltenie, különben a gyorsítótárazott változatot használja.

A valóság az, hogy a böngészők meghatározzák a belső gyorsítótár-irányelveiket, és maguk is eldönthetik, hogy vesz-e erőforrást a gyorsítótárból, vagy letölt-e új példányt.

Az utoljára módosított gyenge gyorsítótár-fejléc, mivel a böngésző heurisztikát alkalmaz annak meghatározására, hogy az elemet a gyorsítótárból tölti le, vagy sem, és a heurisztika böngészőkönként eltérő.
A Google gyorsítótárazási bevált gyakorlati útmutatója
Folytatást kér az utoljára módosított - 1. terhelésselFolytatás kérések utoljára módosítva - 2. terhelés (tökéletes forgatókönyv)Folytatás kérések utoljára módosítva - 2. terhelés (általános eset)

Ennek eredményeként nem hagyatkozhatunk csak az utoljára módosított formában, ezért inkább teljesen eltávolítom a szerver beállításairól a forgalom csökkentése érdekében, még akkor is, ha csak néhány bájtnyi.

Cache-Control maximális életkor

Ez az irányelv lehetővé teszi, hogy megmondjuk a böngészőnek, mennyi ideig kell tárolnia a fájlt a gyorsítótárban az első betöltés óta. Azon időt, ameddig a böngészőnek meg kell őriznie a fájlt gyorsítótárban, másodpercben kell meghatározni, tipikusan a következőképpen: Cache-Control: max-age = 31536000. Ezzel a házirenddel a böngésző teljesen kihagyja a kiszolgálóra irányuló kérések benyújtásának folyamatát, és nagyon gyorsan megnyitja a fájlokat. De hogyan lehetünk biztosak benne, hogy a fájl nem változik olyan sokáig? Mi nem.

Tehát annak érdekében, hogy a böngészőt kényszerítsük a szükséges fájl új verziójának letöltésére, sok eszköz-építő eszköz, például a Webpack vagy a Gulp által alkalmazott technikát használunk. Az egyes fájlokat előzetesen összeállítják a szerveren, és a hash összegeket hozzáadják a fájlnevekhez, például „app-72420c47cc.css”. A fájl még apróbb változásai is tükröződnek a hash összegben, ami garantálja, hogy másként is felismerik. Tehát a következő telepítés után megkapja a fájl új verzióját. Ez vonatkozhat minden css, js és image fájlra (max-age = 31536000); miután megváltoztatunk valamit, a böngésző csak új fájlt kér egy új hash-összeggel, amelyet ezután gyorsítótárba helyez.

no-cache

A fenti technika trükkös része az, hogy nem szabad elfelejteni a html fájlokat; Ha alkalmazza ezt a beállítást is ezekre, akkor soha nem kap új hivatkozásokat a css, js vagy képfájlokhoz, amíg nem kényszeríti az újratöltést.

Azt javaslom, hogy alkalmazza a Cache-Control: no-cache fájlt a html fájlokra. A „nem gyorsítótár” alkalmazása nem azt jelenti, hogy egyáltalán nincs gyorsítótár, egyszerűen azt mondja a böngészőnek, hogy érvényesítse a szerver erőforrásait, mielőtt felhasználná a gyorsítótárból. Ezért kell azt használni az Etag-rel, így a böngészők egy egyszerű kérés, és töltsön be további 80 bájtot a fájl állapotának ellenőrzéséhez.

Végső beállítások

  • Használjon Gulp, Webpack vagy hasonló fájlokat, hogy egyedi hash-számjegyeket adjon hozzá a css, js és képfájlokhoz (például app-67ce7f3483.css);
  • Js, css és kép fájlok esetén állítsa be a Cache-Control-ot: nyilvános, maximális életkor = 31536000, nincs Etag, nincs utoljára módosított beállítás.
  • Html fájlokhoz használja a Cache-Control: no-cache és az Etag fájlokat.

Tehát, amint látjuk, még az olyan nyilvánvaló és általános dolgok is, mint például a statikus fájlok gyorsítótárazása, nem feltétlenül egyértelműek, ha mélyebbre merülünk. A jó kutatás megakadályozhatja a hibák elhárítását és csökkentheti a szerver forgalmát, csökkentve ezzel a webhelysebesség betöltési idejét.

Koppintson a gombra, ha hasznosnak találta ezt a cikket!

Van kérdése vagy visszajelzése? Csatlakozás a Pixel Point-on keresztül