De afgelopen jaren bieden steeds meer platforms voor het optimaliseren van front-end-projecten mogelijkheden voor het zelf hosten of proxyen van bronnen van derden. Met Akamai kun je instellen voor zelf gegenereerde URL's. Cloudflare beschikt over Edge Workers-technologie. Fasterzine kan URL's op pagina's zodat ze verwijzen naar bronnen van derden die zich op het hoofddomein van de site bevinden.
Als u weet dat de services van derden die in uw project worden gebruikt niet vaak veranderen, en dat het proces van het leveren ervan aan klanten verbeterd kan worden, dan denkt u er waarschijnlijk aan om dergelijke services te proxyen. Met deze aanpak kunt u deze bronnen heel goed dichter bij uw gebruikers brengen en meer volledige controle krijgen over hun caching aan de clientzijde. Hierdoor kunt u gebruikers bovendien beschermen tegen problemen die worden veroorzaakt door de "crash" van een service van derden of verslechtering van de prestaties ervan.
Goed: Verbeterde prestaties
Het zelf hosten van de bronnen van iemand anders verbetert de prestaties op een heel voor de hand liggende manier. De browser hoeft niet opnieuw toegang te krijgen tot DNS, geen TCP-verbinding tot stand te brengen en geen TLS-handshake uit te voeren op een domein van derden. U kunt zien hoe het zelf hosten van de bronnen van iemand anders de prestaties beïnvloedt door de volgende twee cijfers te vergelijken.
Bronnen van derden worden gedownload van externe bronnen (overgenomen van )
Bronnen van derden worden op dezelfde plaats opgeslagen als de rest van het sitemateriaal (afkomstig van )
De situatie wordt ook verbeterd door het feit dat de browser de mogelijkheid zal gebruiken om gegevens te multiplexen en prioriteit te geven aan de HTTP/2-verbinding die al tot stand is gebracht met het hoofddomein.
Als u geen bronnen van derden host, kan er geen prioriteit aan worden gegeven, omdat deze worden geladen vanuit een ander domein dan het hoofddomein. Hierdoor zullen ze met elkaar concurreren om de bandbreedte van de klant. Dit kan resulteren in laadtijden voor inhoud die cruciaal is voor het bouwen van een pagina, die veel langer is dan wat onder ideale omstandigheden haalbaar zou zijn. lezing over HTTP/2-prioritering die dit allemaal heel goed uitlegt.
Aangenomen kan worden dat het gebruik van attributen in links naar externe bronnen preconnect zal helpen bij het oplossen van het probleem. Als er echter te veel van deze links naar verschillende domeinen zijn, kan dit de communicatielijn op het meest cruciale moment zelfs overbelasten.
Als u zelf bronnen van derden host, kunt u bepalen hoe deze bronnen precies aan de klant worden gegeven. We hebben het namelijk over het volgende:
- U kunt ervoor zorgen dat het datacompressie-algoritme wordt gebruikt dat het beste bij elke browser past (Brotli/gzip).
- U kunt de cachetijd voor bronnen die doorgaans niet bijzonder lang zijn, verhogen, zelfs bij de meest bekende providers (de overeenkomstige waarde voor de GA-tag is bijvoorbeeld ingesteld op 30 minuten).
U kunt de TTL voor een bron zelfs verlengen tot bijvoorbeeld een jaar door relevante inhoud op te nemen in uw cachingbeheerstrategie (URL-hashes, versiebeheer, enz.). We zullen hier hieronder over praten.
▍Bescherming tegen onderbrekingen in de werking van diensten van derden of het afsluiten ervan
Een ander interessant aspect van het zelf hosten van bronnen van derden is dat u hiermee de risico's kunt beperken die gepaard gaan met uitval van services van derden. Laten we aannemen dat de A/B-testoplossing van derden die u gebruikt, is geïmplementeerd als een blokkeerscript dat in het hoofdgedeelte van de pagina wordt geladen. Dit script laadt langzaam. Als het bijbehorende script niet kan worden geladen, is de pagina leeg. Als het laden erg lang duurt, verschijnt de pagina met een lange vertraging. Of stel dat het project een bibliotheek gebruikt die is gedownload van een CDN-bron van derden. Laten we ons voorstellen dat deze hulpbron in een bepaald land een storing heeft gehad of is geblokkeerd. Een dergelijke situatie zal leiden tot een schending van de logica van de site.
Als u wilt weten hoe uw site werkt wanneer een externe dienst niet beschikbaar is, kunt u de SPOF-sectie gebruiken op .
SPOF-sectie op webpaginatest.org
▍Hoe zit het met problemen met het cachen van materiaal in browsers? (hint: het is een mythe)
Je zou kunnen denken dat het gebruik van openbare CDN’s automatisch tot betere resourceprestaties zou leiden, aangezien deze diensten over netwerken van redelijk hoge kwaliteit beschikken en over de hele wereld worden gedistribueerd. Maar eigenlijk is alles iets ingewikkelder.
Laten we zeggen dat we verschillende sites hebben: website1.com, website2.com, website3.com. Al deze sites gebruiken de jQuery-bibliotheek. We verbinden het met hen via een CDN, bijvoorbeeld googleapis.com. U kunt van de browser verwachten dat hij de bibliotheek één keer downloadt en in de cache opslaat, en deze vervolgens op alle drie de sites gebruikt. Dit zou de belasting van het netwerk kunnen verminderen. Misschien kunt u hiermee ergens geld besparen en de prestaties van de hulpbronnen helpen verbeteren. Praktisch gezien ziet alles er anders uit. Safari heeft bijvoorbeeld een functie genaamd : de cache gebruikt dubbele sleutels op basis van de bron van het document en de bron van de bron van derden. goed artikel over dit onderwerp.
oude studies и , maar ook recenter Paul Calvano laat zien dat bronnen niet zo lang in browsercaches worden opgeslagen als we zouden verwachten: “Er gaapt een serieuze kloof tussen de cachetijd van de eigen bronnen van een project en die van derden. We hebben het over CSS en weblettertypen. 95% van de native lettertypen heeft namelijk een cachelevensduur van meer dan een week, terwijl 50% van de lettertypen van derden een cachelevensduur van minder dan een week heeft! Dit geeft webontwikkelaars een dwingende reden om zelf lettertypebestanden te hosten!”
Als gevolg hiervan zult u, als u de inhoud van anderen host, geen prestatieproblemen merken die worden veroorzaakt door browsercaching.
Nu we de sterke punten van self-hosting door derden hebben besproken, gaan we het hebben over hoe je een goede implementatie van deze aanpak kunt onderscheiden van een slechte.
Het slechte: de duivel zit in de details
Het verplaatsen van bronnen van derden naar uw eigen domein kan niet automatisch worden gedaan zonder ervoor te zorgen dat dergelijke bronnen op de juiste manier in de cache worden opgeslagen.
Een van de grootste problemen hier is de cachetijd. Versie-informatie is bijvoorbeeld opgenomen in scriptnamen van derden, zoals deze: jquery-3.4.1.js. Zo'n bestand zal in de toekomst niet veranderen en als gevolg daarvan zal dit geen problemen veroorzaken met de caching ervan.
Maar als er geen versiebeheerschema wordt gebruikt bij het werken met bestanden, kunnen in de cache opgeslagen scripts, waarvan de inhoud verandert terwijl de bestandsnaam onveranderd blijft, verouderd raken. Dit kan een serieus probleem zijn, omdat het bijvoorbeeld niet mogelijk is geautomatiseerde beveiligingspatches toe te voegen aan scripts die clients zo snel mogelijk moeten ontvangen. De ontwikkelaar zal moeite moeten doen om dergelijke scripts in de cache bij te werken. Bovendien kan dit applicatiefouten veroorzaken omdat de code die op de client uit de cache wordt gebruikt, verschilt van de nieuwste versie van de code waarvoor het servergedeelte van het project is ontworpen.
Het is waar dat als we het hebben over materialen die regelmatig worden bijgewerkt (tagmanagers, oplossingen voor A/B-testen), het cachen ervan met behulp van CDN-tools een taak is die kan worden opgelost, maar die veel complexer is. Services zoals Commanders Act, een oplossing voor tagbeheer, gebruiken webhooks bij het publiceren van nieuwe versies. Dit geeft je de mogelijkheid om een cache flush op het CDN te forceren, of, beter nog, de mogelijkheid om een hash- of URL-update te forceren.
▍Adaptieve levering van materialen aan klanten
Als we het over caching hebben, moeten we bovendien rekening houden met het feit dat de caching-instellingen die op het CDN worden gebruikt mogelijk niet geschikt zijn voor sommige bronnen van derden. Dergelijke bronnen kunnen bijvoorbeeld gebruik maken van user-agent sniffing-technologie (adaptieve bediening) om specifieke browsers te bedienen met versies van inhoud die specifiek voor die browsers zijn geoptimaliseerd. Deze technologieën zijn afhankelijk van reguliere expressies, of een database met HTTP-headerinformatie, om de browsermogelijkheden te achterhalen. User-Agent. Zodra ze weten met welke browser ze te maken hebben, geven ze hem materialen die daarvoor zijn ontworpen.
Hier kunt u twee diensten onthouden. De eerste is googlefonts.com. De tweede is polyfill.io. De Google Fonts-service biedt voor een bepaalde bron verschillende CSS-codes, afhankelijk van de mogelijkheden van de browser (links geven naar woff2-bronnen met behulp van unicode-range).
Hier zijn de resultaten van een aantal Google Fonts-zoekopdrachten gemaakt vanuit verschillende browsers.
Google Fonts-queryresultaat van Chrome
Resultaat van Google Fonts-query uitgevoerd vanuit IE10
Polyfill.io geeft de browser alleen de polyfills die hij nodig heeft. Dit wordt gedaan om prestatieredenen.
Laten we bijvoorbeeld eens kijken wat er gebeurt als u het volgende verzoek vanuit verschillende browsers uitvoert:
Als reactie op een dergelijk verzoek, uitgevoerd vanuit IE10, wordt 34 KB aan gegevens ontvangen. En het antwoord daarop, uitgevoerd vanuit Chrome, zal leeg zijn.
Boos: enkele privacyoverwegingen
Dit punt is het laatste, maar daarom niet minder belangrijk. Het punt is dat het zelf hosten van bronnen van derden op het hoofddomein van het project of op het subdomein ervan de privacy van gebruikers in gevaar kan brengen en een negatieve invloed kan hebben op het hoofdwebproject.
Als uw CDN-systeem niet correct is geconfigureerd, is het mogelijk dat u de cookies van uw domein naar een service van derden verzendt. Als er op CDN-niveau geen goede filtering is georganiseerd, dan kunnen uw sessiecookies, die onder normale omstandigheden niet in JavaScript kunnen worden gebruikt (met de httponly), kan naar een buitenlandse host worden gestuurd.
Dit is precies wat er kan gebeuren met trackers als Eulerian of Criteo. Trackers van derden hebben mogelijk een unieke identificatie in de cookie ingesteld. Als ze deel uitmaakten van sitemateriaal, konden ze de ID naar eigen goeddunken lezen terwijl de gebruiker met verschillende webbronnen werkte.
Tegenwoordig bieden de meeste browsers bescherming tegen dit soort trackergedrag. Als gevolg hiervan gebruiken trackers nu technologie , vermomd als hun eigen scripts voor verschillende projecten. Trackers bieden site-eigenaren namelijk de mogelijkheid om een CNAME toe te voegen aan hun instellingen voor een bepaald domein, waarvan het adres er meestal uitziet als een willekeurige reeks tekens.
Hoewel het niet wordt aanbevolen om websitecookies beschikbaar te maken voor alle subdomeinen (bijvoorbeeld - *.website.com), doen veel sites dit wel. In dit geval worden dergelijke cookies automatisch naar een verkapte tracker van derden gestuurd. Hierdoor kunnen we niet meer over enige privacy praten.
Hetzelfde gebeurt ook met HTTP-headers , die alleen naar het hoofddomein worden verzonden, omdat ze kunnen worden gebruikt om gebruiker. Zorg ervoor dat de CDN-service die u gebruikt deze headers correct filtert.
Resultaten van
Als u van plan bent binnenkort zelfhosting van bronnen van derden te implementeren, wil ik u enkele tips geven:
- Host uw belangrijkste JS-bibliotheken, lettertypen en CSS-bestanden. Dit verkleint het risico dat de site uitvalt of prestatieverlies veroorzaakt doordat een bron die essentieel is voor de site niet beschikbaar is vanwege de fout van een service van een derde partij.
- Voordat u bronnen van derden op een CDN cachet, moet u ervoor zorgen dat er een soort versiebeheersysteem wordt gebruikt bij het benoemen van hun bestanden, of dat u de levenscyclus van deze bronnen kunt beheren door de CDN-cache handmatig of automatisch opnieuw in te stellen wanneer u een nieuwe versie van publiceert. het script.
- Wees zeer voorzichtig met uw CDN-, proxyserver- en cache-instellingen. Hiermee kunt u voorkomen dat uw project of headers cookies ontvangen
Client-Hintsdiensten van derden.
Beste lezers! Hostt u op uw servers materiaal van anderen dat uiterst belangrijk is voor de werking van uw projecten?
Bron: www.habr.com