Az utóbbi években egyre több front-end fejlesztési platform kínál önálló hosztolási vagy harmadik fél erőforrásainak proxizási lehetőségeit. Az Akamai lehetővé teszi megadását az önállóan létrehozott URL-ekhez. A Cloudflare rendelkezik Edge Workers technológiával. A Fasterzine képes az URL-eket az oldalakon úgy, hogy azok a fő domainen található külső erőforrásokra mutassanak.
Ha tudja, hogy a projektben használt harmadik fél szolgáltatások nem változnak túl gyakran, és hogy a kiszolgálásuk folyamatát javítani lehet, akkor valószínűleg gondolkodik az ilyen szolgáltatások proxizásán. Ezzel a megközelítéssel „közelebb” hozhatja ezeket az erőforrásokat a felhasználókhoz, és teljesebb kontrollt szerezhet azok ügyféloldali gyorsítótárazása felett. Ez lehetővé teszi azt is, hogy megvédje a felhasználókat a harmadik fél szolgáltatásának leállásából vagy teljesítményének csökkenéséből adódó problémáktól.
Előny: teljesítmény növelése
Az idegen erőforrások önálló hosztolása nyilvánvaló módon javítja a teljesítményt. A böngészőnek nem kell feleslegesen DNS-hez fordulnia, nem kell TCP-kapcsolatot létesítenie, és TLS-kézfogást végrehajtania egy külső domainen. Az idegen erőforrások önálló hosztolásának teljesítményre gyakorolt hatását a következő két grafikon összehasonlításával lehet megfigyelni.
A harmadik fél erőforrásait külső forrásokból töltik be (forrás: )
A harmadik fél erőforrásait ugyanott tárolják, ahol a webhely többi anyaga is (forrás: )
A helyzetet tovább javítja, hogy a böngésző ki tudja használni a HTTP/2 kapcsolat multiplexelési és adatprioritási lehetőségeit, amely már létrejött a fő domainnel.
Ha nem tárolja a harmadik fél erőforrásait, mivel ezeket egy másik domainről töltik be, nem lehet őket priorizálni. Ez ahhoz vezet, hogy versenyezni fognak az ügyfél sávszélességéért. Ez megakadályozhatja, hogy a lap megjelenítéséhez kritikus fontosságú anyagok betöltési ideje sokkal hosszabb legyen, mint ami a legjobb körülmények között elérhető. beszéd az HTTP/2 priorizálásáról, amelyben mindez nagyon jól van magyarázva.
Feltételezhetjük, hogy a külső erőforrások linkjeiben található attribútumok preconnect segíthetnek a probléma megoldásában. Azonban, ha sok ilyen link van különböző domainekre, az valójában túlterhelheti a kapcsolatot a legkritikusabb pillanatban.
Ha a külső erőforrásokat önállóan hosztolják, ellenőrizni lehet, hogy ezek az erőforrások hogyan kerülnek kiszolgálásra a kliens számára. Nevezetesen az alábbiakról van szó:
- Biztosítható, hogy a legjobban megfelelő adatkompressziós algoritmus legyen alkalmazva, amely a legjobban illik minden böngészőhöz (Brotli/gzip).
- Növelhető a források gyorsítótárazási ideje, amely általában még a legismertebb szolgáltatóknál sem különösebben hosszú (például a GA címke számára a megfelelő érték 30 percre van beállítva).
Még a TTL értékét is kibővítheti az erőforrás számára, például egy évre, a megfelelő anyagok beillesztésével a gyorsítótár-kezelési stratégiájába (URL-hashok, verziókezelés stb.). Erről alább beszélünk.
▍Védelem a külső szolgáltatások leállása vagy lekapcsolása ellen
A külső erőforrások önálló hosztolásának egy másik érdekes aspektusa, hogy ez csökkentheti a külső szolgáltatások leállása miatti kockázatokat. Tegyük fel, hogy a használt harmadik féltől származó A/B tesztelési megoldás egy blokkoló script formájában van megvalósítva, amely az oldal fejlécében töltődik be. Ez a script lassan töltődik be. Ha a megfelelő script betöltése nem sikerül – üres oldal jelenik meg. Ha a betöltéshez nagyon sok idő szükséges – az oldal nagy késéssel jelenik meg. Vagy tegyük fel, hogy a projekt egy bibliotékát használ, amelyet egy külső CDN-erőforrás tölt be. Tegyük fel, hogy ez az erőforrás leállást tapasztalt, vagy egy adott országban blokkolták. Ilyen helyzet a weboldal működésének logikáját zavarja meg.
Ahhoz, hogy megtudja, hogyan működik a weboldala, ha egy külső szolgáltatás nem érhető el, használhatja a SPOF szakaszt a .
SPOF szakasz a webpagetest.org-on
▍Mi a helyzet a böngészők anyagainak gyorsítótárazási problémáival? (tipp: ez mítosz)
Azt hihetnénk, hogy a nyilvános CDN-ek használata automatikusan jobb teljesítményt eredményez, mivel ezek a szolgáltatások elég jó hálózatokkal rendelkeznek és világszerte elérhetők. De a helyzet valójában egy kicsit bonyolultabb.
Tegyük fel, hogy több különböző weboldalunk van: website1.com, website2.com, website3.com. Mindezen weboldalak jQuery könyvtárat használnak. CDN-en, például a googleapis.com-on keresztül csatlakoztatjuk őt. Elvárhatjuk, hogy a böngésző egyszer letöltse és gyorsítótárba helyezze a könyvtárat, majd azután ezt használja mindhárom weboldal esetében. Ez csökkenthetné a hálózati terhelést, és talán spórolhatnánk is, javítva ezzel a források teljesítményét. Gyakorlati szempontból azonban a helyzet más. Például a Safari implementálta a következő lehetőséget: : a gyorsítótárban dupla kulcsokat használnak, amelyek a dokumentum forrásán és a külső forrás forrásán alapulnak. jó cikk erről a témáról.
Régi kutatások és , valamint egy frissebb Paola Calvano kutatásaik azt mutatják, hogy a források nem maradnak olyan hosszú ideig a böngésző gyorsítótárában, mint ahogy azt elvárnánk: „Jelentős eltérés figyelhető meg a saját és a külső forrású projektforrások gyorsítótárazási ideje között. Az CSS-ről és a webfontokkal kapcsolatosan van szó. Nevezetesen, a saját fontok 95%-ának gyorsítótárazási ideje meghaladja a hét napot, míg a külső fontok 50%-ának gyorsítótárazási ideje egy hétnél kevesebb! Ez jó okot ad a webfejlesztőknek a fontfájlok saját hosztolására!”
Ennek eredményeként, ha külső anyagokat hosztolsz, nem fogsz problémákat tapasztalni a böngésző gyorsítótárazásából eredő teljesítménnyel kapcsolatban.
Most, hogy átvettük a külső források saját hosztolásának erősségeit, beszéljünk arról, hogyan lehet megkülönböztetni a jó megvalósítást a rossztól.
Rossz: a részletekben rejlik a hiba
A külső források saját domainre való áthelyezése nem történhet meg automatikusan, anélkül, hogy megfelelő gyorsítótárazást biztosítanánk ezeknek a forrásoknak.
Az egyik fő probléma itt a gyorsítótárazási idő. Például a verzióinformációk a külső szkriptek neveibe körülbelül így kerülnek be: jquery-3.4.1.js. Az ilyen fájl a jövőben nem változik, ezért ez nem okoz problémát a gyorsítótárazásával.
De ha egy fájl verziókezelési sémája nem alkalmazható, akkor a gyorsítótárazott szkriptek, amelyek neve változatlan marad, de a tartalmuk változik, elavulttá válhatnak. Ez komoly problémát okozhat, mivel például nem teszi lehetővé az automatikus frissítések alkalmazását a biztonsági javításokhoz, amelyeket az ügyfeleknek a lehető leghamarabb meg kell kapniuk. A fejlesztőnek erőfeszítéseket kell tennie a hasonló szkriptek gyorsítótárazásának frissítésére. Ezen kívül ez alkalmazás hibákat is okozhat, mivel a gyorsítótárból származó kód eltérhet a szerveroldali projekt friss verziójától.
Igaz, ha a gyakran frissülő anyagokról (címke menedzserek, A/B tesztelési megoldások) beszélünk, a CDN gyorsítótárazása bár megoldható feladat, de sokkal bonyolultabb. Az olyan szolgáltatások, mint a Commanders Act, címke kezelő megoldások, új verziók közzétételekor webhooks-t használnak. Ez lehetővé teszi a gyorsítótár törlésének megszervezését a CDN-en, vagy ami még jobb, lehetőséget biztosít a hash vagy URL verzió frissítésének hívására.
▍Adatvezérelt tartalomkínálat az ügyfelek számára
Továbbá, amikor a gyorsítótárazásról beszélünk, figyelembe kell venni azt a tényt is, hogy a CDN-en alkalmazott gyorsítótárazási beállítások nem feltétlenül felelnek meg bizonyos külső forrásoknak. Például ezek a források felhasználói ügynökök szagolásán (user agent sniffing, adaptív szolgáltatás) alapuló technológiákat használhatnak, hogy a különböző böngészők számára optimalizált verziókat kínáljanak. Ez a technológia, hogy meghatározza a böngésző lehetőségeit, reguláris kifejezésekre vagy olyan adatbázisra támaszkodik, amely információkat tartalmaz az HTTP fejléc adatainak összegyűjtéséről. User-Agent. Miután megértették, hogy melyik böngészővel van dolguk, azt az anyagot adják át neki, amely a számára készült.
Két szolgáltatásra érdemes emlékezni. Az első a googlefonts.com. A második a polyfill.io. A Google Fonts szolgáltatás a bizonyos forráshoz különböző CSS kódokat biztosít, amelyek a böngésző képességeitől függenek (linkeket adva woff2 forrásokra, használva unicode-range).
Íme egy pár lekérdezés eredménye a Google Fonts-ról, amelyek különböző böngészőkből lettek végrehajtva.
A Google Fonts lekérdezés eredménye, amelyet Chrome-ból hajtottak végre
A Google Fonts lekérdezés eredménye, amelyet IE10-ből hajtottak végre
A Polyfill.io csak azokat a polifillokat adja a böngészőnek, amelyekre szüksége van. Ezt teljesítmény szempontjából teszi.
Például nézzük meg, hogy mi történik, ha a következő lekérdezést különböző böngészőkből hajtjuk végre:
Egy ilyen lekérdezés eredményeként, amelyet IE10-ből hajtottak végre, 34 Kb adat érkezik. A Chrome-ból végrehajtott válasz viszont üres lesz.
A Privacy: néhány megfontolás a magánéletről
Ez a pont az utolsó, de nem a legfontosabb. Arról van szó, hogy a harmadik fél erőforrásainak önálló hosztolása a projekt fő domaine vagy almappái alatt veszélyeztetheti a felhasználók magánéletét, és negatív hatással lehet a fő webprojektre.
Ha a CDN rendszered helytelenül van beállítva, akkor azzal véget érhet, hogy a domained sütijeit egy harmadik fél szolgáltatásának küldöd. Ha a CDN szinten nem történik meg a helyes szűrés, akkor a munkamenet sütijeid, amelyeket normális esetben nem lehet JavaScript-ben használni (a httponly), elküldhetők egy idegen hosztra.
Ez történhet olyan nyomkövetőkkel, mint az Eulerian vagy a Criteo. A harmadik féltől érkező nyomkövetők egyedi azonosítót állíthattak be a sütikben. Ha ezek oldalanyagaikban szerepeltek, akkor a felhasználó különböző webforrásokkal való interakciója során saját belátásuk szerint olvashatták az azonosítót.
Manapság a legtöbb böngésző tartalmaz védelmet az ilyen nyomkövetők viselkedése ellen. Ennek eredményeként a nyomkövetők most már a , különböző projektek saját szkriptjeiként álcázva magukat. Nevezetesen, a nyomkövetők azt javasolják a weboldal tulajdonosoknak, hogy adják hozzá a CNAME-t egy bizonyos domainhez, amelynek címe általában véletlenszerű karakterhalmaznak tűnik.
Bár nem ajánlott, hogy a weboldal sütijei minden aldomain számára elérhetők legyenek (például — *.website.com), sok weboldalon ezt megteszik. Ilyen esetben az ilyen sütik automatikusan elküldésre kerülnek egy álcázott harmadik fél nyomkövetőhöz. Ennek eredményeként a magánszféra már nem létezik.
Ezen kívül ugyanaz történik a HTTP-fejlécekkel is, , amelyek csak a fő domainhez kerülnek elküldésre, mivel felhasználhatók a létrehozásához. felhasználó. Ügyeljen arra, hogy a használt CDN-szolgáltatás helyesen szűrje ezeket a fejléceket.
Összegzés
Ha hamarosan harmadik féltől származó erőforrások saját hosztolásába fogott, hadd adjak néhány tanácsot:
- Hozza létre a legfontosabb JS könyvtárait, betűtípusait és CSS fájljait a saját szerverein. Ez csökkenti a webhely leállásának vagy teljesítménycsökkenésének kockázatát, amely a webhely működéséhez elengedhetetlen erőforrás hiányából adódik.
- Mielőtt harmadik féltől származó erőforrásokat cache-elne a CDN-en, győződjön meg arról, hogy a fájlneveik elnevezésénél használnak valamilyen verziókezelési rendszert, vagy hogy képes arra, hogy a fájl életciklusát kezelje, manuálisan vagy automatikusan törölve a CDN cache-t, amikor új verziójú szkriptet publikál.
- Fokozottan figyeljen a CDN, proxy szerver és cache beállításaira. Ez lehetővé teszi, hogy elkerülje a projekthez tartozó cookie-k vagy fejlécek
Client-Hintskülső szolgáltatásokhoz történő elküldését.
Használjátok a CI/CD technológiákat a projektjeitekben? Hostol-e külső anyagokat a szerverein, amelyek rendkívül fontosak a projektjei működése szempontjából?
Forrás: habr.com
