Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud

Viimastel aastatel pakuvad üha enam esiotsa projektide optimeerimise platvorme võimalusi isehostimiseks või kolmandate osapoolte ressursside puhverserveriks. Akamai võimaldab teil määrata konkreetsed parameetrid ise loodud URL-ide jaoks. Cloudflare'il on Edge Workersi tehnoloogia. Fasterzine saab uuesti kirjutama URL-id lehtedel, et need osutaksid kolmanda osapoole ressurssidele, mis asuvad saidi põhidomeenis.

Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud

Kui teate, et teie projektis kasutatavad kolmandate osapoolte teenused ei muutu kuigi sageli ja et nende klientidele tarnimise protsessi saaks parandada, siis tõenäoliselt mõtlete selliste teenuste puhverserverile. Selle lähenemisviisiga saate need ressursid väga hästi oma kasutajatele lähemale tuua ja saada täielikuma kontrolli nende vahemällu kliendi poolel. Lisaks võimaldab see kaitsta kasutajaid probleemide eest, mis on põhjustatud kolmanda osapoole teenuse "krahhist" või selle jõudluse halvenemisest.

Hea: parem jõudlus

Kellegi teise ressursside isehostimine parandab jõudlust väga ilmselgelt. Brauser ei pea uuesti DNS-i juurde pääsema, ta ei pea looma TCP-ühendust ega sooritama kolmanda osapoole domeenis TLS-käepigistust. Näete, kuidas kellegi teise ressursside isehostimine toimivust mõjutab, kui võrrelda kahte järgmist joonist.

Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud
Kolmanda osapoole ressursid laaditakse alla välistest allikatest (võetud aadressilt siit)

Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud
Kolmandate osapoolte ressursse hoitakse samas kohas, kus saidi ülejäänud materjalid (võetud saidilt siit)

Olukorda parandab ka see, et brauser hakkab kasutama juba põhidomeeniga loodud HTTP/2 ühenduse andmete multipleksimise ja prioritiseerimise võimalust.

Kui te ei hosti kolmanda osapoole ressursse, siis kuna need laaditakse põhidomeenist erinevalt domeenilt, ei saa neid prioriteediks seada. See paneb nad omavahel konkureerima kliendi ribalaiuse pärast. Selle tulemuseks võib olla lehe ehitamiseks kriitilise tähtsusega sisu laadimisaeg, mis on palju pikem kui ideaaltingimustes saavutatav. siin on räägime HTTP/2 prioritiseerimisest, mis seletab seda kõike väga hästi.

Võib eeldada, et atribuutide kasutamine linkides välistele ressurssidele preconnect aitab probleemi lahendada. Kui aga neid linke erinevatele domeenidele on liiga palju, võib see tegelikult kõige olulisemal hetkel sideliini üle koormata.

Kui majutate ise kolmanda osapoole ressursse, saate juhtida, kuidas täpselt neid ressursse kliendile antakse. Nimelt räägime järgmisest:

  • Saate tagada, et kasutatakse igale brauserile kõige paremini sobivat andmete tihendamise algoritmi (Brotli/gzip).
  • Saate suurendada vahemällu salvestamise aega ressursside puhul, mis tavaliselt ei ole eriti pikad, isegi kõige tuntumate pakkujate puhul (näiteks GA märgendi vastavaks väärtuseks on määratud 30 minutit).

Saate isegi pikendada ressursi TTL-i näiteks ühe aastani, lisades oma vahemällu haldamise strateegiasse asjakohase sisu (URL-i räsid, versioonid jne). Sellest räägime allpool.

▍Kaitse kolmandate osapoolte teenuste töö katkestuste või nende väljalülitamise eest

Kolmanda osapoole ressursside isehostimise teine ​​huvitav aspekt on see, et see võimaldab teil maandada riske, mis on seotud kolmanda osapoole teenuste katkestustega. Oletame, et teie kasutatav kolmanda osapoole A/B-testimise lahendus on rakendatud blokeeriva skriptina, mis laaditakse lehe peaosas. See skript laaditakse aeglaselt. Kui vastava skripti laadimine ebaõnnestub, on leht tühi. Kui laadimine võtab väga kaua aega, ilmub leht suure viivitusega. Või oletame, et projekt kasutab kolmanda osapoole CDN-i ressursist alla laaditud teeki. Kujutagem ette, et selles ressursis tekkis rike või see blokeeriti teatud riigis. Selline olukord viib saidi loogika rikkumiseni.

Kui soovite teada saada, kuidas teie sait töötab, kui mõni väline teenus pole saadaval, saate kasutada jaotist SPOF webpagetest.org.

Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud
SPOF-i jaotis saidil webpagetest.org

▍ Kuidas on lood materjalide vahemällu salvestamisega brauserites? (vihje: see on müüt)

Võib arvata, et avalike CDN-ide kasutamine tooks automaatselt kaasa parema ressursside jõudluse, kuna neil teenustel on üsna kvaliteetsed võrgud ja neid levitatakse üle maailma. Kuid tegelikult on kõik veidi keerulisem.

Oletame, et meil on mitu erinevat saiti: website1.com, website2.com, website3.com. Kõik need saidid kasutavad jQuery teeki. Ühendame selle nendega näiteks CDN-i abil - googleapis.com. Võite eeldada, et brauser laadib teegi üks kord alla ja salvestab selle vahemällu ning seejärel kasutab seda kõigil kolmel saidil. See võib vähendada võrgu koormust. Võib-olla võimaldab see teil kuskil raha säästa ja parandada ressursside jõudlust. Praktilisest vaatenurgast paistab kõik teistmoodi välja. Näiteks Safaril on funktsioon nimega Intelligentne jälgimise ennetamine: vahemälu kasutab kahte võtit, mis põhinevad dokumendi allikal ja kolmanda osapoole ressursi allikal. siin on hea artikkel sellel teemal.

vanad õpingud Yahoo и Facebook, aga ka uuemad õppida Paul Calvano, näidake, et ressursse ei salvestata brauseri vahemällu nii kaua, kui võiksime eeldada: „Projekti enda ja kolmanda osapoole ressursside vahemällu salvestamise aja vahel on tõsine lõhe. Räägime CSS-ist ja veebifondidest. Nimelt on 95% native fontide vahemälu eluiga üle nädala, samas kui 50% kolmanda osapoole fontidest on vahemälu eluiga alla nädala! See annab veebiarendajatele mõjuva põhjuse ise fondifaile majutada!

Seetõttu ei märka te teiste inimeste sisu hostimisel brauseri vahemällu salvestamisest põhjustatud toimivusprobleeme.

Nüüd, kui oleme käsitlenud kolmanda osapoole isehostimise tugevaid külgi, räägime sellest, kuidas eristada selle lähenemisviisi head rakendamist halvast.

Halb: kurat peitub detailides

Kolmanda osapoole ressursside teisaldamine enda domeeni ei saa toimuda automaatselt, ilma et oleks tagatud, et sellised ressursid on korralikult vahemällu salvestatud.

Üks peamisi probleeme siin on vahemällu salvestamise aeg. Näiteks lisatakse versiooniteave kolmanda osapoole skriptide nimedesse, näiteks järgmiselt: jquery-3.4.1.js. Selline fail ei muutu tulevikus ja selle tulemusel ei põhjusta see vahemällu salvestamisega probleeme.

Kui aga failidega töötamisel mõnda versiooniskeemi ei kasutata, võivad vahemällu salvestatud skriptid, mille sisu muutub, kui failinimi jääb muutumatuks, vananeda. See võib olla tõsine probleem, kuna see ei võimalda näiteks automaatsete turvapaikade lisamist skriptidele, mille kliendid peavad saama võimalikult kiiresti. Arendaja peab pingutama, et selliseid skripte vahemälus värskendada. Lisaks võib see põhjustada rakenduse tõrkeid, kuna kliendil vahemälust kasutatav kood erineb selle koodi viimasest versioonist, mille jaoks projekti serveriosa on loodud.

Tõsi, kui rääkida materjalidest, mida sageli uuendatakse (sildihaldurid, lahendused A/B testimiseks), siis nende vahemällu salvestamine CDN-i vahenditega on lahendatav, kuid palju keerulisem ülesanne. Sellised teenused nagu Commanders Act, sildihalduslahendus, kasutavad uute versioonide avaldamisel veebihaake. See annab teile võimaluse sundida CDN-i vahemälu loputama või, mis veelgi parem, võimaluse sundida räsi või URL-i värskendamist.

▍Adaptiivne materjalide tarnimine klientidele

Lisaks, kui me räägime vahemällu salvestamisest, peame arvestama asjaoluga, et CDN-is kasutatavad vahemäluseaded ei pruugi mõne kolmanda osapoole ressursside jaoks sobida. Näiteks võivad sellised ressursid kasutada kasutajaagendi nuusutamise (adaptiivse teenindamise) tehnoloogiat, et teenindada konkreetseid brausereid sisuversioonidega, mis on spetsiaalselt nende brauserite jaoks optimeeritud. Need tehnoloogiad tuginevad brauseri võimaluste väljaselgitamiseks regulaaravaldistele või HTTP päise teabe andmebaasile. User-Agent. Kui nad teavad, millise brauseriga nad tegelevad, annavad nad sellele selle jaoks mõeldud materjalid.

Siin saate meeles pidada kahte teenust. Esimene neist on googlefonts.com. Teine on polyfill.io. Teenus Google Fonts pakub teatud ressursi jaoks erinevat CSS-koodi, olenevalt brauseri võimalustest (andes linke woff2 ressurssidele, kasutades unicode-range).

Siin on paari Google Fontsi päringu tulemused, mis on tehtud erinevatest brauseritest.

Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud
Google Fontsi päringutulemus Chrome'ist

Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud
IE10-st käivitatud Google Fontsi päringu tulemus

Polyfill.io annab brauserile ainult need polütäited, mida ta vajab. Seda tehakse jõudluse huvides.

Näiteks vaatame, mis juhtub, kui käivitate järgmise päringu erinevatest brauseritest: https://polyfill.io/v3/polyfill.js?features=default

Vastuseks sellisele IE10-st tehtud päringule võetakse vastu 34 KB andmeid. Ja vastus sellele, mis täidetakse Chrome'ist, on tühi.

Vihane: mõned privaatsuskaalutlused

See punkt on järjekorras viimane, kuid mitte vähem oluline. Asi on selles, et kolmanda osapoole ressursside isehostimine projekti põhidomeenis või selle alamdomeenis võib kahjustada kasutajate privaatsust ja mõjutada negatiivselt peamist veebiprojekti.

Kui teie CDN-süsteem pole õigesti konfigureeritud, võite lõpuks saata oma domeeni küpsised kolmanda osapoole teenusele. Kui CDN-i tasemel pole korralikku filtreerimist korraldatud, siis teie seansiküpsised, mida tavaliselt JavaScriptis kasutada ei saa (koos httponly), võidakse saata välismajutajale.

Täpselt nii võib juhtuda jälgimisseadmetega nagu Eulerian või Criteo. Kolmanda osapoole jälgijad võivad olla küpsisesse seadnud kordumatu identifikaatori. Kui need olid osa saidi materjalidest, said nad identifikaatorit oma äranägemise järgi lugeda, kui kasutaja töötas erinevate veebiressurssidega.

Tänapäeval sisaldab enamik brausereid kaitset seda tüüpi jälgija käitumise eest. Selle tulemusena kasutavad jälgijad nüüd tehnoloogiat CNAME varjamine, maskeerides oma stsenaariumideks erinevate projektide jaoks. Nimelt pakuvad jälgijad saidiomanikele lisada teatud domeeni seadetesse CNAME, mille aadress näeb tavaliselt välja nagu suvaline tähemärkide komplekt.

Kuigi veebisaidi küpsiseid ei soovitata teha kõigile alamdomeenidele (näiteks - *.website.com) kättesaadavaks, teevad paljud saidid seda. Sel juhul saadetakse sellised küpsised automaatselt varjatud kolmanda osapoole jälgijale. Sellest tulenevalt ei saa me enam rääkida mingist privaatsusest.

Sama juhtub ka HTTP-päistega Klient-vihjed, mis saadetakse ainult põhidomeenile, kuna neid saab kasutada loomiseks digitaalne sõrmejälg kasutaja. Veenduge, et teie kasutatav CDN-teenus filtreeriks need päised õigesti.

Tulemused

Kui plaanite peagi kasutusele võtta kolmanda osapoole ressursside isehostimise, annan teile mõned näpunäited.

  • Hoiustage oma kõige olulisemad JS-i teegid, fondid ja CSS-failid. See vähendab saidi tõrke või jõudluse halvenemise ohtu, kuna saidi jaoks oluline ressurss ei ole kolmanda osapoole teenuse süül saadaval.
  • Enne kolmanda osapoole ressursside CDN-is vahemällu salvestamist veenduge, et nende failidele nime andmisel kasutatakse mingit versioonimissüsteemi või et saate hallata nende ressursside elutsüklit, lähtestades CDN-i vahemälu käsitsi või automaatselt uue versiooni avaldamisel. stsenaarium.
  • Olge CDN-i, puhverserveri ja vahemälu sätete suhtes väga ettevaatlik. See võimaldab teil vältida küpsiste saatmist oma projektile või päistele Client-Hints kolmanda osapoole teenused.

Kallid lugejad! Kas majutate oma serverites teiste inimeste materjale, mis on teie projektide toimimiseks äärmiselt olulised?

Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud
Isehostitavad kolmanda osapoole ressursid: head, halvad, inetud

Allikas: www.habr.com

Lisa kommentaar