An de leschte Jore bidden ëmmer méi Plattforme fir Front-End-Projeten Optimisatiounsméiglechkeeten fir Selbsthosting oder Proxy vun Drëtt-Partei Ressourcen. Akamai erlaabt Iech ze setzen fir selwer generéiert URLen. Cloudflare huet Edge Workers Technologie. Fasterzine kann URLen op Säiten sou datt se op Drëtt-Partei Ressourcen weisen, déi um Haaptdomän vum Site sinn.
Wann Dir wësst datt d'Drëtt-Partei Servicer, déi an Ärem Projet benotzt ginn, net ganz dacks änneren, an datt de Prozess fir se un d'Clienten ze liwweren verbessert ka ginn, dann denkt Dir wahrscheinlech drun sou Servicer ze proxyen. Mat dëser Approche kënnt Dir ganz gutt dës Ressourcen méi no bei Äre Benotzer bréngen a méi komplett Kontroll iwwer hire Cache op der Client Säit kréien. Dëst, zousätzlech, erlaabt Iech d'Benotzer vu Probleemer ze schützen, déi duerch den "Crash" vun engem Drëtt-Partei-Service oder Verschlechterung vu senger Leeschtung verursaacht ginn.
Gutt: verbessert Leeschtung
Selbsthosting vun engem aneren seng Ressourcen verbessert d'Performance op eng ganz offensichtlech Manéier. De Browser brauch net erëm op DNS ze kommen, et brauch keng TCP Verbindung ze etabléieren an en TLS Handshake op engem Drëtt Partei Domain auszeféieren. Dir kënnt gesinn wéi d'Selbsthosting vun engem aneren seng Ressourcen d'Performance beaflosst andeems Dir déi folgend zwou Figuren vergläicht.
Drëtt Partei Ressourcen ginn aus externe Quellen erofgelueden (vun )
Drëtt Partei Ressourcen ginn op der selwechter Plaz gelagert wéi de Rescht vun de Sitematerialien (vun )
D'Situatioun gëtt och verbessert duerch d'Tatsaach datt de Browser d'Fähigkeit benotzt fir ze multiplexéieren an Daten aus der HTTP/2 Verbindung ze prioritären déi scho mat der Haaptdomän etabléiert ass.
Wann Dir keng Drëtt-Partei Ressourcen hutt, da well se vun engem Domain anescht wéi den Haapt gelueden ginn, kënnen se net prioritär gesat ginn. Dëst wäert dozou féieren datt se matenee konkurréiere fir d'Bandbreedung vum Client. Dëst kann zu Luedezäite fir Inhalter kritesch féieren fir eng Säit ze bauen déi vill méi laang ass wéi wat ënner idealen Ëmstänn erreechbar wier. schwätzen iwwer HTTP / 2 Prioritéit déi all dëst ganz gutt erkläert.
Et kann ugeholl ginn, datt d'Benotzung vun Attributer an Linken op extern Ressourcen preconnect wäert hëllefen de Problem ze léisen. Wéi och ëmmer, wann et ze vill vun dëse Linken op verschidden Domainen ass, kann et tatsächlech d'Kommunikatiounslinn am entscheedendste Moment iwwerlaascht.
Wann Dir Drëtt Partei Ressourcen selwer hostt, kënnt Dir kontrolléieren wéi genau dës Ressourcen dem Client ginn. Mir schwätzen nämlech iwwer déi folgend:
- Dir kënnt suergen, datt den Datekompressiounsalgorithmus, deen am Beschten all Browser passt, benotzt gëtt (Brotli / gzip).
- Dir kënnt d'Cachingzäit fir Ressourcen erhéijen déi normalerweis net besonnesch laang sinn, och mat de bekanntste Fournisseuren (zum Beispill ass de entspriechende Wäert fir de GA Tag op 30 Minutten gesat).
Dir kënnt souguer den TTL fir eng Ressource op, soen, e Joer verlängeren andeems Dir relevant Inhalter an Är Caching Management Strategie integréiert (URL Hashes, Versioun, etc.). Mir schwätzen iwwer dëst ënnert.
▍Schutz géint Ënnerbriechungen an der Operatioun vun Drëtt-Partei-Servicer oder hir Ausschaltung
En aneren interessanten Aspekt vu Selbsthosting vun Drëtt Partei Ressourcen ass datt et Iech erlaabt d'Risiken ze reduzéieren verbonne mat Ausbroch vun Drëtt Partei Servicer. Loosst eis unhuelen datt d'Drëtt-Partei A/B Testléisung déi Dir benotzt als Blockéierungsskript implementéiert gëtt dat an de Kappsektioun vun der Säit lued. Dëst Skript lued lues. Wann de entspriechende Skript net lued, ass d'Säit eidel. Wann et eng ganz laang Zäit dauert fir ze lueden, erschéngt d'Säit mat enger laanger Retard. Oder, ugeholl datt de Projet eng Bibliothéik benotzt, déi vun enger Drëtt Partei CDN Ressource erofgeluede gëtt. Loosst eis virstellen datt dës Ressource e Feeler erlieft huet oder an engem bestëmmte Land blockéiert gouf. Sou eng Situatioun wäert zu enger Verletzung vun der Logik vum Site féieren.
Fir erauszefannen wéi Äre Site funktionnéiert wann e puer externe Service net verfügbar ass, kënnt Dir d'SPOF Sektioun op benotzen .
SPOF Sektioun op webpagetest.org
▍Wat iwwer Probleemer mam Cache vu Materialien a Browser? (Tipp: et ass e Mythos)
Dir mengt vläicht datt d'Benotzung vun ëffentlechen CDNs automatesch zu enger besserer Ressourceleistung féiert, well dës Servicer zimlech héichqualitativ Netzwierker hunn a ronderëm d'Welt verdeelt sinn. Awer alles ass tatsächlech e bësse méi komplizéiert.
Loosst eis soen datt mir verschidde Siten hunn: website1.com, website2.com, website3.com. All dës Siten benotzen d'jQuery Bibliothéik. Mir verbannen et mat hinnen mat engem CDN, zum Beispill - googleapis.com. Dir kënnt erwaarden datt de Browser d'Bibliothéik eemol erofluet an cache, an dann op all dräi Siten benotzt. Dëst kéint d'Laascht op de Reseau reduzéieren. Vläicht erlaabt dëst Iech iergendwou Suen ze spueren an hëlleft d'Ressourceleistung ze verbesseren. Aus enger praktescher Siicht gesäit alles anescht aus. Zum Beispill, Safari huet eng Feature genannt : De Cache benotzt duebel Schlësselen baséiert op der Quell vum Dokument an der Quell vun der Drëttpersoun. gudden Artikel zu dësem Thema.
al Studien и , wéi och méi rezent Paul Calvano, weisen datt Ressourcen net sou laang a Browser-Cache gespäichert ginn wéi mir erwaarden: "Et gëtt e seriöse Gruef tëscht der Cachezäit vun engem Projet seng eegen an Drëtt-Partei Ressourcen. Mir schwätzen iwwer CSS a Webfonten. Nämlech, 95% vun gebiertege Schrëften hunn e Cache Liewen vu méi wéi enger Woch, während 50% vun Drëtt Partei Schrëften hunn e Cache Liewen vu manner wéi enger Woch! Dëst gëtt Webentwéckler en zwéngende Grond fir Schrëftdateien selwer ze hosten!"
Als Resultat, wann Dir den Inhalt vun anere Leit host, mierkt Dir keng Performanceprobleemer verursaacht duerch Browser-Caching.
Elo datt mir d'Stäerkte vum Drëtt Partei Selbsthosting ofgedeckt hunn, loosst eis schwätzen iwwer wéi eng gutt Ëmsetzung vun dëser Approche vun enger schlechter erzielt gëtt.
De Schlecht: Den Däiwel ass an den Detailer
D'Ressourcen vun Drëttubidder op Ären eegene Domain bewegen kann net automatesch gemaach ginn ouni sécherzestellen datt sou Ressourcen richteg cache sinn.
Ee vun den Haaptprobleemer hei ass Cachezäit. Zum Beispill gëtt d'Versiounsinformatioun an Drëtt Partei Skriptnimm wéi dëst abegraff: jquery-3.4.1.js. Sou eng Datei wäert an Zukunft net änneren, an als Resultat wäert dëst keng Probleemer mat sengem Cache verursaachen.
Awer wann e puer Versiounsschema net benotzt gëtt wann Dir mat Dateien schafft, kënnen cache Skripte, den Inhalt vun deenen ännert wann de Dateinumm onverännert bleift, verännert ginn. Dëst kann e seriöse Problem sinn, well et zum Beispill net erlaabt automatiséiert Sécherheetspatches op Skripte bäizefügen, déi Clienten esou séier wéi méiglech kréien. Den Entwéckler muss en Effort maachen fir esou Scripten am Cache ze aktualiséieren. Zousätzlech kann dëst Applikatiounsfehler verursaachen wéinst der Tatsaach datt de Code deen um Client vum Cache benotzt gëtt vun der leschter Versioun vum Code ënnerscheet fir deen de Serverdeel vum Projet entworf ass.
Richteg, wa mir iwwer Material schwätzen, déi dacks aktualiséiert ginn (Tag Manager, Léisunge fir A / B Testen), dann Cache se mat CDN Tools ass eng Aufgab déi geléist ka ginn, awer vill méi komplex ass. Servicer wéi Commanders Act, eng Tag Management Léisung, benotzen Webhooks wann Dir nei Versioune publizéiert. Dëst gëtt Iech d'Fäegkeet fir e Cache Spull op der CDN ze zwéngen, oder, besser nach, d'Fäegkeet en Hash oder URL Update ze forcéieren.
▍ Adaptiv Liwwerung vu Materialien u Clienten
Zousätzlech, wa mir iwwer Caching schwätzen, musse mir d'Tatsaach berücksichtegen datt d'Caching-Astellungen, déi op der CDN benotzt ginn, vläicht net fir e puer Drëtt-Partei Ressourcen passend sinn. Zum Beispill kënnen esou Ressourcen User Agent Sniffing (adaptive Serving) Technologie benotzen fir spezifesch Browser ze déngen mat Versioune vum Inhalt, déi speziell fir dës Browser optiméiert sinn. Dës Technologien vertrauen op reegelméisseg Ausdréck, oder eng Datebank vun HTTP Header Informatioun, fir d'Browserfäegkeeten erauszefannen. User-Agent. Wann se wësse mat wéi engem Browser se ze dinn hunn, ginn se et Materialien, déi dofir entworf sinn.
Hei kënnt Dir zwee Servicer erënneren. Déi éischt ass googlefonts.com. Déi zweet ass polyfill.io. De Google Fonts Service bitt, fir eng bestëmmte Ressource, verschidde CSS Coden, ofhängeg vun de Fäegkeeten vum Browser (gëtt Linken op woff2 Ressourcen mat unicode-range).
Hei sinn d'Resultater vun e puer Google Fonts Ufroen aus verschiddene Browser gemaach.
Google Fonts Ufroresultat vu Chrome
Resultat vun der Google Fonts Ufro aus IE10 ausgefouert
Polyfill.io gëtt dem Browser nëmmen déi Polyfills déi et brauch. Dëst gëtt aus Leeschtungsgrënn gemaach.
Loosst eis zum Beispill kucken wat geschitt wann Dir déi folgend Ufro vu verschiddene Browser leeft:
Als Äntwert op esou eng Ufro aus IE10 ausgefouert, ginn 34 KB vun Daten kritt. An d'Äntwert op et, aus Chrome ausgefouert, wäert eidel sinn.
Angry: E puer Privatsphär Considératiounen
Dëse Punkt ass lescht an der Rei, awer net zulescht wichteg. De Punkt ass datt d'Selbsthosting vun Drëtt-Partei Ressourcen op der Haaptdomän vum Projet oder op sengem Subdomain d'Privatsphär vun de Benotzer a Gefor bréngen an den Haaptwebprojet negativ beaflossen.
Wann Ären CDN System net richteg konfiguréiert ass, kënnt Dir Är Domain Cookien op en Drëtt Partei Service schécken. Wann de richtege Filter net um CDN Niveau organiséiert ass, da sinn Är Sessiouns-Cookien, déi normalerweis net a JavaScript benotzt kënne ginn (mat der httponly), kann un en auslännesche Host geschéckt ginn.
Dëst ass genau wat mat Tracker wéi Eulerian oder Criteo ka geschéien. Drëtt Partei Tracker kënnen en eenzegaartegen Identifizéierer am Cookie gesat hunn. Wa se Deel vum Sitematerial waren, kënne se den Identifizéierer no hirem Diskretioun liesen, während de Benotzer mat verschiddene Webressourcen schafft.
Dës Deeg enthalen déi meescht Browser Schutz géint dës Zort Tracker Verhalen. Als Resultat benotze Tracker elo Technologie , Masquerading als hir eege Scripte fir verschidde Projeten. Nämlech, Tracker bidden Site Besëtzer fir e CNAME op hir Astellunge fir e bestëmmten Domain ze addéieren, d'Adress vun deem normalerweis ausgesäit wéi eng zoufälleg Zeeche vu Charaktere.
Och wann et net recommandéiert ass Websäit Cookien fir all Ënnerdomainen verfügbar ze maachen (zum Beispill - *.website.com), vill Site maachen dat. An dësem Fall ginn esou Cookien automatesch un e verkleeden Drëtt Partei Tracker geschéckt. Als Resultat kënne mir net méi iwwer Privatsphär schwätzen.
Och geschitt datselwecht mat HTTP Header , déi nëmmen un den Haaptdomän geschéckt ginn, well se kënne benotzt ginn fir ze kreéieren Benotzer. Vergewëssert Iech datt den CDN Service deen Dir benotzt dës Header korrekt filtert.
Resultater
Wann Dir plangt Selbsthosting vun Drëtt Partei Ressourcen geschwënn ëmzesetzen, loosst mech Iech e puer Tipps ginn:
- Host Är wichtegst JS Bibliothéiken, Schrëften an CSS Dateien. Dëst wäert de Risiko vum Site Echec oder Performance Degradatioun reduzéieren wéinst enger Ressource déi vital fir de Site net verfügbar ass wéinst dem Feeler vun engem Drëtt Partei Service.
- Ier Dir Drëtt Partei Ressourcen op engem CDN cache, gitt sécher datt eng Aart vu Versiounssystem benotzt gëtt wann Dir hir Dateien nennt, oder datt Dir de Liewenszyklus vun dëse Ressourcen verwalten kënnt andeems Dir den CDN Cache manuell oder automatesch zrécksetzt wann Dir eng nei Versioun publizéiert. d'Schrëft.
- Sidd ganz virsiichteg iwwer Är CDN, Proxy Server, a Cache Astellungen. Dëst erlaabt Iech ze verhënneren datt Äre Projet oder Header Cookien geschéckt ginn
Client-HintsDrëtt Partei Servicer.
Léif Lieser! Gitt Dir Material vun anere Leit op Äre Serveren, déi extrem wichteg sinn fir den Fonctionnement vun Äre Projeten?
Source: will.com