Iseseisev kolmandate osapoolte ressursside majutamine: hea, halb, kole

Viimastel aastatel pakuvad üha rohkem platvorme esiplaaniprojektide optimeerimiseks võimalusi iseseisvaks hostimiseks või kolmandate osapoolte ressursside proksimiseks. Akamai võimaldab määrata spetsiifilisi parameetreid iseseisvalt loodud URL-idele. Cloudflare'il on tehnoloogia Edge Workers. Fasterzine suudab ümber kirjutada lehtede URL-e nii, et need viiksid kolmandate osapoolte ressurssidele, mis asuvad peamise veebisaidi domeenis.

Kui on teada, et teie projektis kasutatavad kolmandate osapoolte teenused ei muutu liiga sageli ning et nende klientidele edastamise protsessi saab parandada, siis mõtlete kindlasti selliste teenuste proksimise peale. Sellise lähenemisega saate need ressursid tõenäoliselt „lähedasemaks“ tuua kasutajatele ning saavutada suuremat kontrolli nende vahemällu salvestamise üle kliendi poolel. See võimaldab ka kaitsta kasutajaid kolmandate osapoolte teenuste ‘langemise’ või nende jõudluse halvenemisega seotud ebamugavuste eest.

Hea: jõudluse tõus

Iseseisev hostimine kolmandate osapoolte ressursidest parandab jõudlust üsnagi nähtaval viisil. Hoolimata sellest, et brauser ei pea uuesti pöörduma DNS-i poole, ei pea ta looma TCP-ühendust ja teostama TLS-käepigistust kolmanda osapoole domeenil. Seda, kuidas iseseisev hostimine kolmandate osapoolte ressursidest mõjutab jõudlust, saab näha, võrreldes kahte järgmist pilti.

Kolmandate osapoolte ressursid laaditakse välisest allikast (võetud siit)

Kolmandate osapoolte ressursid salvestatakse seal, kus ka ülejäänud veebisaidi materjalid (võetud siit)

Olukorda parandab veel see, et brauser kasutab HTTP/2-ühenduse multiplexerimise ja andmete prioriseerimise võimalusi, mis on juba loodud peamise domeeniga.

Kui te ei majuta oma serveris kolmandate osapoolte ressursse, ei saa neid prioriseerida, kuna need laaditakse erinevast domeenist. See viib olukorrani, kus nad konkureerivad omavahel kliendi ribalaiuse pärast. See võib tähendada, et lehekoostamisel kriitilise tähtsusega materjalide laadimisaeg osutub oluliselt pikemaks, kui see oleks ideaalsetes tingimustes. Siin esitlus HTTP/2 prioriseerimisest, kus kogu see teema on väga hästi selgitatud.

Võib eeldada, et väliste ressursside linkide atribuutide kasutamine preconnect aitab probleemi lahendada. Siiski, kui selliseid linke erinevatele domeenidele on liiga palju, võib see tegelikult üle koormata sideüksuse kõige kriitilisemal hetkel.

Kui hostida kolmandate osapoolte ressursse iseseisvalt, on võimalik kontrollida, kuidas need ressursid kliendini edastatakse. Täpsemalt öeldes on jutt järgmise üle:

• On võimalik tagada andmete tihendamise algoritmi kasutamine, mis sobib kõige paremini igale brauserile (Brotli/gzip).
• Saab suurendada ressursside vahemälu aega, mis isegi kõige tuntumate pakkujate juures ei ole eriti suur (näiteks on GA sildi jaoks vastav väärtus seatud 30 minutiks).

Saab isegi suurendada ressursi TTL näitajat, näiteks aastani, kaasates vastavad materjalid oma vahemäluhalduse strateegiasse (URL-i hashes, versioonimine jne). Nendest räägime allpool.

▍Kaitse kolmandate osapoolte teenuste katkestuste või nende sulgemise eest

Veel üks huvitav aspekt kolmandate osapoolte ressurside iseseisvast hostimisest on see, et see võimaldab vähendada riske, mis on seotud kolmandate osapoolte teenuste katkestustega. Oletame, et teie kasutatav kolmanda osapoole A/B testimise lahendus on realiseeritud blokeeriva skriptina, mis laaditakse lehe päisesse. See skript laadib aeglaselt. Kui vastavat skripti ei õnnestu laadida, jääb leht tühjaks. Kui selle laadimiseks kulub väga kaua aega, ilmub leht suure viivitusega. Või oletame, et projektis kasutatakse raamatukogu, mis laaditakse kolmanda osapoole CDN-ressursilt. Kujutame ette, et see ressurss on kokku kukkunud või blokeeritud mõnes riigis. Selline olukord viib saidi töö loogika rikkumiseni.

Kuidas teada saada, kuidas teie sait töötab olukordades, kus mõni väline teenus ei ole saadaval, võite kasutada SPOF jaotist webpagetest.org.

SPOF jaotis webpagetest.org-is

▍Kuidas on lood brauserites ressursside vahemäluprobleemidega? (näpunäide: see on müüt)

Võib arvata, et avalike CDN-ide kasutamine toob automaatselt paremat jõudlust, kuna need teenused omavad piisavalt kvaliteetseid võrke ja on jaotatud üle kogu maailma. Kuid tegelikult on kõik natuke keerulisem.

Oletame, et meil on mitu erinevat veebisaiti: website1.com, website2.com, website3.com. Kõik need saidid kasutavad jQuery teeki. Me ühendame selle CDN-iga, näiteks — googleapis.com. Võime eeldada, et brauser laadib teegi kord ja salvestab selle vahemälusse, seejärel kasutab seda kõigis kolmes saidis. See võiks vähendada võrgu koormust. Võib-olla võib see säästa kuskil ja aidata parandada ressursside jõudlust. Praktiliselt aga näeb kõik teistsugune välja. Näiteks on Safaris rakendatud funktsioon, mida nimetatakse Intelligent Tracking Prevention: vahemälus kasutatakse kahtlustatud võtmeid, mis põhinevad dokumendi allikal ja kolmanda osapoole ressursi allikal. Siin hea artikkel selle teema kohta.

Vanad uuringud Yahoo ja Facebook, samuti uuemad uuring Pola Calvano, näitavad, et ressursid ei püsi brauseri vahemälu nii kaua, kui võiksime oodata: "Omanda ressursside ja kolmandate osapoolte ressursside vahemälu kestuse vahel on tõsine lõhe. Räägime CSS-ist ja veebifontidest. Täpsemalt, 95% enda fontide vahemälu kestus ületab nädalat, samas kui 50% kolmandate osapoolte fontide vahemälu kestus on alla nädala! See annab veebiarendajatele kaalukaid põhjuseid fontide failide ise hostimiseks!"

Seetõttu, kui hostite oma juures teiste materjale, ei pruugi te märkata veepidevuse probleeme, mida põhjustab brauseri vahemälu.

Nüüd, kui oleme uurinud iseseisva hostimise tugevusi, rääkigem sellest, kuidas head rakendust halvast eristada.

halb: devils on detailides

Kolmanda osapoole ressursside edastamine oma domeenile ei saa automaatselt toimuda ilma nende ressursside õige vahemällu salvestamiseta.

Üks peamisi probleeme siin on vahemälu aeg. Näiteks versiooni teave lisatakse kolmandate osapoolte skriptide nimedes umbes nii: jquery-3.4.1.js. Selline fail ei muutu tulevikus, seega ei tekita see mingit probleemi selle vahemällu salvestamisega.

Kuid kui mingit versioonimise skeemi failide töötlemisel ei rakendata, võivad vahemällu salvestatud skriptid, mille sisu muutub sama faili nõnna, aeguda. See võib kujuneda tõsiseks probleemiks, näiteks ei lase see automaatselt rakendada turvaparandusi skriptidesse, mis peaksid võimalikult kiiresti jõudma klientideni. Arendajal tuleb pingutada, et sarnased skriptid vahemälus uuendada. Lisaks võib see põhjustada rakenduse talitlushäireid, kuna kliendi poolt vahemälust kasutatav kood erineb värskest koodi versioonist, millele serveri osa on loodud.

Tõsi, kui räägime sageli uuendatavatest materjalidest (siltide haldurid, A/B-testimise lahendused), siis nende vahemällu salvestamine CDN-idega on ülesanne, kuigi teostatav, on kordades keerulisem. Teenused nagu Commanders Act, silti haldavad lahendused, kasutavad uute versioonide avaldamisel veebikoonuseid. See võimaldab korraldada vahemälu tühjendamist CDN-is või, mis veelgi parem, võimaldab välja kutsuda uuenduse hash'i või versiooni URL-ile.

▍Kohandatud materjalide edastamine klientidele

Lisaks, kui räägime vahemällu salvestamisest, tuleb arvesse võtta ka seda, et CDN-ides kasutatavad vahemällu salvestamise seadistused ei pruugi sobida teatud kolmandate osapoolte ressurssidega. Näiteks võivad sellised ressursid kasutada kasutajaagendi nuhkimistehnoloogiat (user agent sniffing, adaptive serving), et edastada kindlatele brauseritele versioone materjalidest, mis on spetsiaalselt nende brauserite jaoks optimeeritud. Need tehnoloogiad tuginevad brauseri võimekuse määramiseks regulaaravaldustele või andmebaasile, kus on kogutud teave HTTP-pealkirjade kohta. User-Agent. Pärast seda, kui nad on teada saanud, millega nad tegelevad, edastavad nad sellele materjalid, mis on sellele sobivad.

Siin võib tuua meelde kaks teenust. Esimene - googlefonts.com. Teine - polyfill.io. Google Fonts teenus pakub, mõne ressursi jaoks, erinevat CSS-koodi, mis sõltub brauseri võimekusest (andmata linke woff2-ressursside, kasutades unicode-range).

Siin on tulemused paarist päringust Google Fonts-le, mis tehti erinevatest brauseritest.

Google Fonts'i päringute tulemus, mis on tehtud Chrome'ist

Google Fonts'i päringute tulemus, mis on tehtud IE10-st

Polyfill.io annab brauserile ainult need polüfillid, mis talle vajalikud on. See toimub jõudluse kaalutlustest.

Vaadakem näiteks, mis juhtub, kui teeme järgmise päringu erinevates brauserites: https://polyfill.io/v3/polyfill.js?features=default

IE10-st tehtud päringu vastuseks tuleb 34 KB andmeid. Chrome'ist tehtud päringule on vastus tühi.

Halb: mõningad kaalutlused privaatsuse kohta

See punkt on viimane järjestuses, kuid mitte vähem oluline. Jutt on sellest, et kolmandate osapoolte ressursside iseseisev hostimine projekti peamisel domeenil või selle alamdomeenil võib panna ohtu kasutajate privaatsuse ja avaldada negatiivset mõju põhiprojekti veebilehele.

Kui teie CDN-süsteem on valesti seadistatud, võib see lõppeda sellega, et saadate teie domeeni küpsised kolmandale teenusele. Kui CDN-i tasemel ei korraldata õiget filtreerimist, võivad teie sessiooni küpsised, mida tavaliselt ei saa kasutada JavaScriptis (millel on atribuut httponly), saadetakse kolmandale hostile.

Just see võib juhtuda näiteks Euleriani või Criteo jälgijatega. Kolmandad jälgijad võivad paigaldada ainulaadse identifikaatori küpsisesse. Need, kui nad olid saidi sisu osaks, said lugeda identifikaatorit oma äranägemise järgi, kui kasutaja töötas erinevate veebiresurssidega.

Tänapäeval sisaldavad enamik brausereid kaitset sellise jälgijate käitumise vastu. Tulemuseks on, et nüüd kasutavad jälgijad tehnoloogiat CNAME Cloaking, maskeerides end erinevate projektide skriptide järgi. Nimelt pakuvad jälgijad veebilehe omanikele CNAME-i lisamist oma seadistustesse mingiks domeeniks, mille aadress näeb välja nagu juhuslik sümbolite kombinatsioon.

Kuigi ei ole soovitatav teha nii, et veebilehe küpsised oleksid kõigile alamdomeenidele kergesti ligipääsetavad (näiteks — *.website.com), tehakse seda paljudele veebilehtedele. Sel juhul saadetakse sellised küpsised automaatselt maskeeritud kolmandale jälgijale. Tulemuseks on, et mingist privaatsusest ei saa enam rääkida.

Lisaks toimub sama ka HTTP-pealkirjadega Client-Hints, mis saadetakse ainult põhikodule, kuna neid saab kasutada loomiseks digitaalne jälg kasutaja. Pange tähele, et teie kasutatav CDN-teenus filtreerib selliseid pealkirju õigesti.

Summary

Kui plaanite varsti juurutada kolmandate osapoolte allikate iseseisvat hostimist, lubage mul anda teile mõned nõuanded:

• Hoidke oma tähtsaimad JS-raamatukogud, fondid ja CSS-failid oma serveris. See vähendab riski, et teie veebisaidi töö katkeb või selle jõudlus halveneb, kui vajalik ressurss, mis on veebisaidi toimimiseks hädavajalik, ei ole saadaval kolmanda osapoole teenuse tõttu.
• Enne kolmandate osapoolte ressursside vahemällu salvestamist CDN-is veenduge, et nende failide nimetamist kasutatakse mingisugust versiooni haldust või et saate nende ressursside elutsükli hallata, käsitsi või automaatselt tühjendades CDN-i vahemälu, kui avaldate uue versiooni skriptist.
• Olge väga ettevaatlik CDN-i, puhverserveri ja vahemälu seadistuste osas. See takistab teil saatmast oma projekti küpsiseid või pealkirju Client-Hints kolmandate osapoolte teenustele.

Lugupeetud lugejad! Kas majutate oma serverites võõraid materjale, mis on teie projektide toimimiseks äärmiselt olulised?

Allikas: habr.com