Az utóbbi években egyre több előtér-projektek optimalizálására szolgáló platform kínál lehetőséget harmadik féltől származó erőforrások saját üzemeltetésére vagy proxyra. Az Akamai lehetővé teszi a beállítást saját generált URL-ekhez. A Cloudflare Edge Workers technológiával rendelkezik. Fasterzine tud URL-ek az oldalakon, hogy azok a webhely fő domainjében található, harmadik féltől származó forrásokra mutassanak.
Ha tudja, hogy a projektben használt harmadik féltől származó szolgáltatások nem változnak túl gyakran, és ezeknek az ügyfelekhez való eljuttatásának folyamata még javítható, akkor valószínűleg az ilyen szolgáltatások proxyszolgáltatásán gondolkodik. Ezzel a megközelítéssel nagyon jól közelebb hozhatja ezeket az erőforrásokat a felhasználókhoz, és teljesebb ellenőrzést szerezhet a gyorsítótárazásuk felett a kliens oldalon. Ez emellett lehetővé teszi a felhasználók védelmét a harmadik féltől származó szolgáltatások „összeomlása” vagy teljesítményének romlása által okozott problémáktól.
Jó: jobb teljesítmény
Valaki más erőforrásainak saját üzemeltetése nyilvánvaló módon javítja a teljesítményt. A böngészőnek nem kell újra hozzáférnie a DNS-hez, nem kell TCP-kapcsolatot létesítenie és TLS-kézfogást végrehajtania egy harmadik féltől származó tartományon. Az alábbi két ábra összehasonlításával láthatja, hogy valaki más erőforrásainak öntárolása hogyan befolyásolja a teljesítményt.
A harmadik féltől származó források letöltése külső forrásokból történik (a )
A harmadik féltől származó erőforrások ugyanazon a helyen vannak tárolva, mint a webhely többi anyaga (a )
A helyzetet javítja az is, hogy a böngésző a fődomainnel már kialakított HTTP/2 kapcsolat adatainak multiplexelésének és priorizálásának lehetőségét fogja használni.
Ha nem tárol harmadik féltől származó erőforrásokat, akkor mivel a fő tartománytól eltérő tartományból töltődnek be, nem adhatók prioritásnak. Ez arra készteti őket, hogy versenyezzenek egymással az ügyfél sávszélességéért. Ez az oldal felépítéséhez kritikus tartalom betöltési idejét eredményezheti, amely sokkal hosszabb, mint ami ideális körülmények között elérhető lenne. beszéljünk a HTTP/2 prioritásról, ami mindezt nagyon jól megmagyarázza.
Feltételezhető, hogy az attribútumok használata külső erőforrásokra mutató hivatkozásokban preconnect segít a probléma megoldásában. Ha azonban túl sok ilyen hivatkozás van a különböző tartományokra, az valójában a legfontosabb pillanatban túlterhelheti a kommunikációs vonalat.
Ha saját maga tárolja a harmadik féltől származó erőforrásokat, szabályozhatja, hogy ezeket az erőforrásokat pontosan hogyan kapja meg az ügyfél. Mégpedig a következőkről beszélünk:
- Biztosíthatja, hogy az egyes böngészőknek leginkább megfelelő adattömörítési algoritmust használja (Brotli/gzip).
- Növelheti az általában nem túl hosszú erőforrások gyorsítótárazási idejét, még a legismertebb szolgáltatóknál is (például a GA címke megfelelő értéke 30 percre van állítva).
Akár egy erőforrás TTL-jét is meghosszabbíthatja, mondjuk egy évre, ha a releváns tartalmat beépíti a gyorsítótárazás-kezelési stratégiájába (URL-kivonatok, verziókezelés stb.). Az alábbiakban erről fogunk beszélni.
▍A harmadik féltől származó szolgáltatások működésének megszakítása vagy leállása elleni védelem
A harmadik féltől származó erőforrások saját üzemeltetésének másik érdekessége, hogy lehetővé teszi a harmadik féltől származó szolgáltatások kiesésével kapcsolatos kockázatok mérséklését. Tegyük fel, hogy az Ön által használt, harmadik féltől származó A/B tesztelési megoldás blokkoló szkriptként van megvalósítva, amely az oldal fejrészében töltődik be. Ez a szkript lassan töltődik be. Ha a megfelelő szkript nem töltődik be, az oldal üres lesz. Ha nagyon sokáig tart a betöltődés, az oldal nagy késéssel jelenik meg. Vagy tegyük fel, hogy a projekt egy harmadik féltől származó CDN-erőforrásból betöltött könyvtárat használ. Képzeljük el, hogy ez az erőforrás meghibásodott vagy blokkolva volt egy bizonyos országban. Egy ilyen helyzet a webhely logikájának megsértéséhez vezet.
Ha meg szeretné tudni, hogyan működik webhelye, amikor valamilyen külső szolgáltatás nem érhető el, használja a következő SPOF szakaszt .
SPOF rész a webpagetest.org oldalon
▍ Mi a helyzet az anyagok gyorsítótárazásával kapcsolatos problémákkal a böngészőkben? (tipp: ez egy mítosz)
Azt gondolhatnánk, hogy a nyilvános CDN-ek használata automatikusan jobb erőforrás-teljesítményhez vezet, mivel ezek a szolgáltatások meglehetősen jó minőségű hálózatokkal rendelkeznek, és az egész világon el vannak terjesztve. De valójában minden egy kicsit bonyolultabb.
Tegyük fel, hogy több különböző webhelyünk van: website1.com, website2.com, website3.com. Ezek a webhelyek mindegyike a jQuery könyvtárat használja. Csatlakoztatjuk hozzájuk egy CDN segítségével, például - googleapis.com. Elvárhatja, hogy a böngésző egyszer letöltse és gyorsítótárba helyezze a könyvtárat, majd mindhárom webhelyen használja. Ez csökkentheti a hálózat terhelését. Talán ez lehetővé teszi, hogy pénzt takarítson meg valahol, és javítsa az erőforrások teljesítményét. Gyakorlati szempontból minden másképp néz ki. Például a Safari rendelkezik egy ún : A gyorsítótár kettős kulcsot használ a dokumentum forrása és a harmadik féltől származó erőforrás forrása alapján. jó cikk ebben a témában.
régi tanulmányok и , valamint újabbak Paul Calvano, mutassa meg, hogy az erőforrások nem tárolódnak a böngésző gyorsítótárában, ameddig várnánk: „Súlyos szakadék van a projekt saját és harmadik féltől származó erőforrásainak gyorsítótárazási ideje között. CSS-ről és webes betűtípusokról beszélünk. Ugyanis a natív betűtípusok 95%-ának a gyorsítótár élettartama egy hétnél hosszabb, míg a harmadik féltől származó betűtípusok 50%-ának kevesebb, mint egy hét! Ez nyomós okot ad a webfejlesztőknek arra, hogy maguk tárolják a fontfájlokat!”
Ennek eredményeként, ha mások tartalmait tárolja, nem fog észrevenni a böngésző gyorsítótárazása által okozott teljesítményproblémákat.
Most, hogy áttekintettük a harmadik féltől származó öntárhelyszolgáltatás erősségeit, beszéljünk arról, hogyan lehet megkülönböztetni ennek a megközelítésnek a jó megvalósítását a rossztól.
A rossz: Az ördög a részletekben rejlik
Harmadik féltől származó erőforrások saját tartományába történő áthelyezése nem hajtható végre automatikusan anélkül, hogy nem biztosítaná, hogy ezek az erőforrások megfelelően tárolva legyenek.
Az egyik fő probléma itt a gyorsítótárazási idő. Például a verzióinformációkat harmadik féltől származó szkriptnevek tartalmazzák, például: jquery-3.4.1.js. Egy ilyen fájl a jövőben nem változik, és ennek eredményeként ez nem okoz gondot a gyorsítótárazásában.
Ha azonban nem használunk bizonyos verziószámítási sémákat a fájlokkal való munka során, a gyorsítótárazott szkriptek, amelyek tartalma megváltozik, miközben a fájlnév változatlan marad, elavulttá válhatnak. Ez komoly probléma lehet, mivel például nem teszi lehetővé automatizált biztonsági javítások hozzáadását a szkriptekhez, amelyeket az ügyfeleknek a lehető leggyorsabban meg kell kapniuk. A fejlesztőnek erőfeszítést kell tennie, hogy frissítse az ilyen szkripteket a gyorsítótárban. Ezenkívül ez alkalmazáshibákat okozhat, mivel az ügyfélen a gyorsítótárból használt kód eltér annak a kódnak a legújabb verziójától, amelyre a projekt szerver részét tervezték.
Igaz, ha gyakran frissülő anyagokról beszélünk (címkekezelők, megoldások A/B tesztelésre), akkor ezek gyorsítótárazása CDN eszközökkel megoldható, de sokkal összetettebb feladat. Az olyan szolgáltatások, mint a Commanders Act, egy címkekezelő megoldás, webhookot használnak az új verziók közzétételekor. Ez lehetővé teszi a gyorsítótár-öblítés kényszerítését a CDN-en, vagy ami még jobb, a hash- vagy URL-frissítés kényszerítését.
▍Adaptív anyagok szállítása az ügyfelekhez
Ezen túlmenően, amikor a gyorsítótárazásról beszélünk, figyelembe kell vennünk azt a tényt is, hogy a CDN-en használt gyorsítótárazási beállítások nem biztos, hogy alkalmasak egyes harmadik féltől származó erőforrásokhoz. Az ilyen erőforrások például felhasználói ügynökszippelő (adaptív kiszolgálás) technológiát használhatnak, hogy meghatározott böngészőket kiszolgáljanak a kifejezetten ezekre a böngészőkre optimalizált tartalomverziókkal. Ezek a technológiák reguláris kifejezésekre vagy HTTP-fejléc-információk adatbázisára támaszkodnak a böngésző képességeinek meghatározásához. User-Agent. Miután tudják, hogy melyik böngészővel van dolguk, átadják a számára készült anyagokat.
Itt két szolgáltatásra emlékezhet. Az első a googlefonts.com. A második a polyfill.io. A Google Fonts szolgáltatás bizonyos erőforrásokhoz különböző CSS-kódokat biztosít, a böngésző képességeitől függően (hivatkozásokat ad a woff2 erőforrásokhoz a unicode-range).
Íme néhány Google Fonts-lekérdezés eredménye, amelyek különböző böngészőkből készültek.
A Google Fonts lekérdezési eredménye a Chrome-ból
Az IE10-ből végrehajtott Google Fonts lekérdezés eredménye
A Polyfill.io csak azokat a többkitöltéseket adja meg a böngészőnek, amelyekre szüksége van. Ez teljesítmény okokból történik.
Például nézzük meg, mi történik, ha a következő kérést különböző böngészőkből futtatja:
Az IE10-ből végrehajtott ilyen kérésre válaszul 34 KB adat érkezik. A Chrome-ból végrehajtott válasz pedig üres lesz.
Dühös: Néhány adatvédelmi megfontolás
Ez a pont a sorrendben utolsó, de nem utolsósorban fontos. A lényeg az, hogy a harmadik féltől származó erőforrások saját üzemeltetése a projekt fő domainjén vagy annak aldomainjén veszélyeztetheti a felhasználók magánéletét, és negatívan befolyásolhatja a fő webprojektet.
Ha CDN-rendszere nincs megfelelően konfigurálva, előfordulhat, hogy a domain cookie-jait egy harmadik féltől származó szolgáltatásnak küldi el. Ha a megfelelő szűrés nincs megszervezve CDN-szinten, akkor a munkamenet cookie-jait, amelyek általában nem használhatók JavaScriptben (a httponly), elküldhető külföldi fogadónak.
Pontosan ez történhet olyan nyomkövetőkkel, mint az Eulerian vagy a Criteo. Lehetséges, hogy a harmadik fél nyomkövetői egyedi azonosítót állítottak be a cookie-ban. Ha részei voltak a webhely anyagainak, akkor saját belátásuk szerint elolvashatták az azonosítót, miközben a felhasználó különböző webes erőforrásokkal dolgozik.
Manapság a legtöbb böngésző tartalmaz védelmet az ilyen típusú nyomkövető viselkedés ellen. Ennek eredményeként a nyomkövetők ma már technológiát használnak , saját forgatókönyvüknek álcázva magukat különböző projektekhez. A trackerek ugyanis felajánlják a webhelytulajdonosoknak, hogy adjanak hozzá egy CNAME-t a beállításaikhoz egy bizonyos domainhez, amelynek címe általában véletlenszerű karakterkészletnek tűnik.
Bár nem ajánlott a webhely cookie-jait minden aldomain számára elérhetővé tenni (például - *.website.com), sok webhely megteszi ezt. Ebben az esetben az ilyen cookie-kat a rendszer automatikusan elküldi egy álcázott külső nyomkövetőnek. Ennek eredményeként többé nem beszélhetünk semmilyen magánéletről.
Ugyanez történik a HTTP-fejlécekkel is , amelyek csak a fő tartományba kerülnek elküldésre, mivel ezek létrehozására használhatók felhasználó. Győződjön meg arról, hogy az Ön által használt CDN-szolgáltatás megfelelően szűri ezeket a fejléceket.
Eredményei
Ha hamarosan harmadik féltől származó erőforrások saját üzemeltetését tervezi, hadd adjak néhány tippet:
- Hozd a legfontosabb JS-könyvtárakat, betűtípusokat és CSS-fájlokat. Ez csökkenti a webhely meghibásodásának vagy teljesítményromlásának kockázatát, ha a webhely számára létfontosságú erőforrás egy harmadik féltől származó szolgáltatás hibája miatt nem érhető el.
- Mielőtt harmadik féltől származó erőforrásokat gyorsítótárazna egy CDN-n, győződjön meg arról, hogy valamilyen verziószámító rendszert használ a fájlok elnevezésekor, vagy hogy a CDN-gyorsítótár kézi vagy automatikus alaphelyzetbe állításával kezelheti ezeknek az erőforrásoknak az életciklusát, amikor új verziót tesz közzé. A script.
- Legyen nagyon óvatos a CDN, a proxyszerver és a gyorsítótár beállításaival kapcsolatban. Ezzel megakadályozhatja, hogy a projektje vagy a fejlécek cookie-kat küldjenek
Client-Hintsharmadik fél szolgáltatásai.
Kedves olvasók! Tárol mások olyan anyagokat a szerverein, amelyek rendkívül fontosak projektjei működése szempontjából?
Forrás: will.com