Viimastel aastatel on üha enam platvorme, mis pakuvad veebiprojektide optimeerimiseks iseseisvat hostimist või kolmandate osapoolte ressursside proxytamist. Akamai võimaldab määrata iseseisvalt loodud URL-ide jaoks. Cloudflare'il on tehnoloogia Edge Workers. Fasterzine suudab lehtedel nii, et need viitavad kolmandate osapoolte ressurssidele, mis asuvad veebisaidi põhidu men.
Kui on teada, et teie projektis kasutatavad kolmandate osapoolte teenused ei muutu liiga tihti ja teenuste kättetoimetamise protsessi saab parandada, siis mõtlete kindlasti nende teenuste proxytamisele. Sellise lähenemisega saate tõepoolest „lähedasemaks“ need ressursid kasutajatele ja saavutada suurema kontrolli nende vahemälu üle kliendi poolel. Samuti kaitseb see kasutajaid olukordade eest, kus kolmanda osapoole teenus katkeb või kaotab oma jõudluse.
Hea: jõudluse suurenemine
Sõltumatu kolmandate osapoolte ressursside hostimine parandab jõudlust ilmselgelt. Brauserid ei pea enam DNS-iga ühendust võtma, nad ei pea looma TCP-ühendust ning täitma TLS-käepigistust kolmandal domeenil. Seda, kuidas kolmandate osapoolte ressursside sõltumatu hostimine jõudlust mõjutab, saab näha, võrreldes kahte järgmiste pilte.
Kolmandate osapoolte ressursid laaditakse välisest allikast (võetud )
Kolmandate osapoolte ressursid asuvad seal, kus ka ülejäänud saidi materjalid (võetud )
Situatsiooni parandab ka asjaolu, et brauserid kasutavad multiplikatsiooni ja HTTP/2 ühenduse andmete prioriseerimise võimalusi, mis on juba loodud põhidomeeniga.
Kui te ei majuta kolmandate osapoolte ressursse enda juures, ei saa neid, kuna need laaditakse erinevast domeenist, prioriseerida. See toob kaasa, et need konkureerivad omavahel kliendi ribalaiuse pärast. See võib põhjustada asjaolu, et lehe kujundamiseks kriitiliselt oluliste materjalide laadimise aeg on palju pikem, kui ideaalsetel tingimustel saavutada võiks. esitlus HTTP/2 prioriseerimise kohta, kus seda kõik väga hästi selgitatakse.
Võib arvata, et välistesse ressurssidesse viitavatesse linkidesse atribuutide lisamine preconnect aitab probleemiga toime tulla. Siiski, kui selliseid linke erinevatesse domeenidesse on liiga palju, võib see tegelikult sidet üle koormata kõige kriitilisemal hetkel.
Kui hostite kolmandate osapoolte ressursse iseseisvalt, saate kontrollida, kuidas need ressursid kliendile edastatakse. Nimelt, on juttu järgmistest aspektidest:
- Saate tagada andmete tihendamise algoritmi rakendamise, mis sobib iga brauseriga kõige paremini (Brotli/gzip).
- Saate suurendada ressursside vahemälu aega, mis tavaliselt isegi tuntud pakkujate juures ei ole eriti suur (nt GA sildil on vastav väärtus seatud 30 minutiks).
Saate isegi pikendada ressursi TTL-i, näiteks aastani, lisades vastavad materjalid oma vahemälu haldamise strateegiasse (URL-hashed, versioonimine jne). Sellest räägime allpool.
▍ Kaitsmed kolmandate osapoolte teenuste katkestuste või väljalülitamise eest
Veel üks huvitav aspekt kolmandate osapoolte ressursside iseseisvaks hostimiseks on see, et see aitab leevendada riske, mis on seotud kolmandate osapoolte teenuste katkestustega. Oletame, et teie kasutatav kolmanda osapoole A/B testimise lahendus on rakendatud kui blokeeriv skript, mis laaditakse lehe päisesse. See skript laaditatakse aeglaselt. Kui vastava skripti laadimine ebaõnnestub, jääb leht tühjaks. Kui selle laadimine võtab väga kaua aega, ilmub leht suure viivitusega. Või oletame, et projektis kasutatakse raamatukogu, mis laaditakse kolmandalt CDN-ilt. Oletame, et see ressurss on kokku kukkunud või seda on mingis riigis blokeeritud. Selline olukord toob kaasa saidi töö loogika kahjustamise.
Et teada saada, kuidas teie sait töötab juhul, kui mõni väline teenus pole saadaval, võite kasutada SPOF sektsiooni .
SPOF sektsioon webpagetest.org
▍ Kuidas on lood sirvijate vahemäluprobleemidega? (näpunäide: see on müüt)
Võib mõelda, et avalike CDN-ide kasutamine toob automaatselt kaasa parema ressursi jõudluse, kuna need teenused omavad piisavalt kvaliteetseid võrgustruktuure ja on laialdaselt levitatud. Kuid tegelikkus on natuke keerulisem.
Oletame, et meil on mitu erinevat veebisaiti: website1.com, website2.com, website3.com. Kõigil nendel saitidel kasutatakse jQuery teeki. Me ühendame selle CDN-iga, näiteks — googleapis.com. Võib oodata, et brauser laadib teegi üks kord alla ja salvestab selle vahemällu ning seejärel kasutab seda kõigil kolmel saidil. See võiks vähendada võrgu koormust. Võib-olla aitab see kuskil säästa ja parandada ressursi jõudlust. Praktikas on siiski olukord teine. Näiteks on Safari-s rakendatud funktsioon, mida nimetatakse : vahemälus kasutatakse kahe võtme süsteemi, mis põhineb dokumendi allika ja kolmanda osapoole allika kombinatsioonil. hea artikkel selle teema kohta.
Vanad uuringud ja , samuti uuemad Paula Calvano uuringud näitavad, et ressursid ei jää brauseri vahemäludesse nii kauaks, kui me võiksime oodata: „Oleme tõsise lõhe ajavahemiku vahel oma ja kolmandate osapoolte projektide ressursi vahemälu vahel. Räägime CSS-st ja veebifontidest. Nimelt on 95% oma fontide vahemälu kestus üle nädala, samas kui 50% kolmandate osapoolte fontide vahemälu kestus on alla nädala! See annab veebiarendajatele häid põhjuseid fontide failide isehostimise kasuks!“
Seega, kui hostite enda juures kellegi teise materjale, ei pruugi te märgata jõudlusprobleeme, mis on põhjustatud brauseri vahemälust.
Nüüd, kui oleme käsitlenud kolmandate osapoolte ressursside isehostimise eeliseid, räägime, kuidas eristada selle lähenemise head rakendust halvast.
Halb: detailides peitub kurat
Kolmandate osapoolte ressursside liigutamine oma domeenile ei ole automaatne, kui ei pöörata tähelepanu nende ressursside õigele vahemälule.
Üks peamisi probleeme on vahemälu kestus. Näiteks, versiooniteave lisatakse kolmandate osapoolte skriptide nimedes umbes nii: jquery-3.4.1.js. Selline fail ei muutu tulevikus, mis ei põhjusta vahemäluga seotud probleeme.
Kuid kui mingit versioonimise skeemi failide töötlemisel ei kasutata, võivad vahemälus olevad skriptid, mille sisu muutub muutumatuks failinime all, vananeda. See võib kujuneda tõsiseks probleemiks, kuna see näiteks ei võimalda automateeritult turvapaike, mis peaksid klientideni jõudma nii kiiresti kui võimalik. Arendaja peab tegema jõupingutusi, et värskendada selliseid skripte vahemälus. Samuti võivad tekkida rakenduse tõrked, kuna vahemälust kasutatav kood erineb projekti serveripoolse osa eeldatavast värskest koodiversioonist.
Kui aga rääkida materjalidest, mis uuenevad sageli (siltide haldurid, A/B-testimise lahendused), siis nende vahemälustamine CDN-ides on küll teostatav ülesanne, kuid juba märksa keerulisem. Teenused nagu Commanders Act, siltide haldamise lahendused, kasutavad uute versioonide avaldamisel veebi hooke. See annab võimaluse korraldada vahemälu tühjendamist CDN-ides või, mis veel parem, võimaluse kutsuda üles värskendama hash'i või URL-i versiooni.
▍Kohandatud materjalide esitamine klientidele
Lisaks, kui räägime vahemälust, tuleb arvesse võtta ka seda, et CDN-ides kasutatavad vahemällu seadistused ei pruugi sobida mõnede kolmandate osapoolte ressursside jaoks. Näiteks võivad need ressursid kasutada kasutaja agendi nuusutamise tehnoloogiat (user agent sniffing, adaptive serving) selleks, et edastada konkreetsetele brauseritele versioone materjalidest, mis on nende brauserite jaoks eriti optimeeritud. Need tehnoloogiad toetuvad regulaarsetele väljenditele või andmebaasile, mis sisaldab teavet HTTP-päise kohta User-Agent. Saades teada, millega nad tegelevad, edastavad nad sellele brauserile tema jaoks kohandatud materjalid.
Siin võib meenutada kahte teenust. Esimene — googlefonts.com. Teine — polyfill.io. Google Fonts teenus pakub, teatud ressursi jaoks, erinevat CSS-koodi, mis sõltub brauseri võimalustest (anda linke woff2-ressurssidele, kasutades unicode-range).
Siin on tulemused paarist Google Fonts päringust, mis on tehtud erinevatest brauseritest.
Google Fontsist saadud päringu tulemus Chrome'ist
Google Fontsist saadud päringu tulemus IE10-st
Polyfill.io annab brauserile ainult need polifillid, mis talle vajalikud on. See tehakse jõudluse kaalutlustel.
Vaadakem näiteks, mis juhtub, kui esitada järgmine päring erinevates brauserites:
IE10-st tehtud päringu vastuseks saadakse 34 KB andmeid. Vastus, mis saadakse Chrome'ist, on aga tühi.
Kurja: mõned privaatsuse kaalutlused
See punkt on viimane, kuid mitte vähem oluline. Siin on jutt sellest, et kolmandate osapoolte ressursside majutamine projekti põhiteemal või selle alamdomeenidel võib ohustada kasutajate privaatsust ja avaldada negatiivset mõju peamise veebiprojekti toimimisele.
Kui teie CDN-süsteem ei ole õigesti seadistatud, võib juhtuda, et saadate oma domeeni küpsiseid kolmandale teenusele. Kui CDN tasemel ei ole korraldatud õiget filtreerimist, võivad teie sessiooniküpsised, mis tavaliselt pole JavaScriptis kergesti kasutatavad (atribuut httponly), saadetakse kolmanda osapoole hostile.
Just seda võib juhtuda jälgijatega nagu Eulerian või Criteo. Kolmandad jälgijad võivad kehtestada küpsiseid unikaalse identifikaatoriga. Need, kui need olid osa veebisaitide materjalidest, võivad lugeda identifikaatorit oma äranägemise järgi, kui kasutaja töötab erinevate veebiresurssidega.
Käesoleval ajal sisaldavad enamik brausereid kaitset sellise jälgimise käitumise eest. Seetõttu kasutavad jälgijad nüüd tehnoloogiat , maskeerides end erinevate projektide enda skriptide järgi. Nimelt pakuvad jälgijad veebisaidi omanikele, et nad lisavad oma seadistustesse CNAME määratlemise mõne domeeni jaoks, mille aadress näeb tavaliselt välja nagu juhuslik sümbolite kogum.
Kuigi ei ole soovitatav, et veebisaidi küpsised oleksid saadaval kõigile alamdomeenidele (näiteks — *.website.com), teevad paljud saidid seda. Sellisel juhul saadetakse need küpsised automaatselt maskeeritud kolmanda osapoole jälgijale. Tulemuseks on, et privaatsetest asjadest ei saa enam rääkida.
Lisaks toimub sama ka HTTP-pealkirjadega , mis saadetakse ainult peamisele domeenile, kuna neid saab kasutada loomiseks. Veenduge, et teie kasutatav CDN-teenus filtreeriks selliseid pealkirju õigesti.
Kokkuvõte
Kui plaanite varsti juurutada kolmandate osapoolte ressursside iseseisvat majutamist — lubage mul anda teile mõned soovitused:
- Majutage enda kõige olulisemaid JS-kogusid, fonte ja CSS-failide. See vähendab riski, et veebisait lakkab töötamast või selle jõudlus väheneb seoses vahendi kättesaamatusega kolmanda teenuse tõttu, mis on veebisaidi toimimise jaoks hädavajalik.
- Enne kui hakkate kolmandate osapoolte ressursse CDN-is vahemällu salvestama, veenduge, et nende failide nimede määramiseks kasutatakse versioonihaldust või et saate nende ressursside elutsüklit hallata, kas käsitsi või automaatselt tühistades CDN-i vahemälu, kui avaldate uue skripti versiooni.
- Olge äärmiselt ettevaatlik CDN-i, puhverserveri ja vahemälu seadistustega. See võimaldab teil vältida oma projekti küpsiste või pealkirjade saatmist
Client-Hintskolmandatele teenustele.
Lugupidamisega lugejad! Kas majutate oma serverites teiste materjale, mis on teie projektide jaoks äärmiselt olulised?
Allikas: habr.com
