Viime vuosina yhä useammat alustat käyttöliittymäprojektien optimointiin tarjoavat mahdollisuuksia itseisännöimiseen tai kolmannen osapuolen resurssien välityspalvelimeen. Akamai antaa sinun asettaa itse luoduille URL-osoitteille. Cloudflaressa on Edge Workers -tekniikka. Fasterzine voi URL-osoitteet sivuilla siten, että ne osoittavat sivuston pääverkkotunnuksessa oleviin kolmannen osapuolen resursseihin.
Jos tiedät, että projektissasi käytetyt kolmannen osapuolen palvelut eivät muutu kovin usein ja että niiden toimitusprosessia asiakkaille voitaisiin parantaa, harkitset todennäköisesti tällaisten palvelujen välityspalvelinta. Tällä lähestymistavalla voit tuoda nämä resurssit lähemmäs käyttäjiäsi ja saada täydellisemmän hallinnan heidän välimuistiin asiakaspuolella. Tämän lisäksi voit suojata käyttäjiä ongelmilta, jotka johtuvat kolmannen osapuolen palvelun kaatumisesta tai sen suorituskyvyn heikkenemisestä.
Hyvä: Parempi suorituskyky
Jonkun toisen resurssien itseisännöiminen parantaa suorituskykyä hyvin ilmeisellä tavalla. Selaimen ei tarvitse käyttää DNS:ää uudelleen, sen ei tarvitse muodostaa TCP-yhteyttä ja suorittaa TLS-kättelyä kolmannen osapuolen toimialueella. Voit nähdä, kuinka jonkun muun resurssien itseisännöinti vaikuttaa suorituskykyyn vertaamalla seuraavia kahta kuvaa.
Kolmannen osapuolen resurssit ladataan ulkoisista lähteistä (otettu osoitteesta )
Kolmannen osapuolen resurssit tallennetaan samaan paikkaan kuin muut sivuston materiaalit (otettu osoitteesta )
Tilannetta parantaa myös se, että selain käyttää mahdollisuutta multipleksoida ja priorisoida tietoja jo päätoimialueen kanssa muodostetusta HTTP/2-yhteydestä.
Jos et isännöi kolmannen osapuolen resursseja, niitä ei voida priorisoida, koska ne ladataan verkkotunnuksesta, joka on eri kuin pääverkkotunnus. Tämä saa ne kilpailemaan keskenään asiakkaan kaistanleveydestä. Tämä voi johtaa sivun rakentamisen kannalta kriittisen sisällön latausaikaan, joka on paljon pidempi kuin mikä olisi saavutettavissa ihanteellisissa olosuhteissa. puhua HTTP/2-priorisoinnista, joka selittää kaiken tämän erittäin hyvin.
Voidaan olettaa, että attribuuttien käyttö linkkejä ulkoisiin resursseihin preconnect auttaa ongelman ratkaisemisessa. Jos näitä linkkejä eri toimialueille on kuitenkin liikaa, se voi itse asiassa ylikuormittaa viestintälinjaa tärkeimmällä hetkellä.
Jos isännöit itse kolmannen osapuolen resursseja, voit hallita, kuinka nämä resurssit tarkalleen annetaan asiakkaalle. Puhumme nimittäin seuraavista:
- Voit varmistaa, että käytetään kullekin selaimelle parhaiten sopivaa tiedonpakkausalgoritmia (Brotli/gzip).
- Voit pidentää välimuistiin kuluvaa aikaa resursseille, jotka eivät yleensä ole erityisen pitkiä, jopa tunnetuimpien palveluntarjoajien kanssa (esimerkiksi GA-tunnisteen vastaavaksi arvoksi on asetettu 30 minuuttia).
Voit jopa pidentää resurssin TTL:ää esimerkiksi vuodeksi sisällyttämällä asiaankuuluvaa sisältöä välimuistin hallintastrategiaasi (URL-hajautus, versiointi jne.). Puhumme tästä alla.
▍Suojaus kolmannen osapuolen palveluiden toiminnan keskeytyksiltä tai niiden sammumiselta
Toinen mielenkiintoinen näkökohta itseisännöimässä kolmannen osapuolen resursseja on, että sen avulla voit lieventää kolmansien osapuolten palveluiden katkoihin liittyviä riskejä. Oletetaan, että käyttämäsi kolmannen osapuolen A/B-testausratkaisu on toteutettu estävänä komentosarjana, joka latautuu sivun yläosassa. Tämä skripti latautuu hitaasti. Jos vastaava komentosarja ei lataudu, sivu on tyhjä. Jos latautuminen kestää hyvin kauan, sivu tulee näkyviin pitkällä viiveellä. Tai oletetaan, että projekti käyttää kolmannen osapuolen CDN-resurssista ladattua kirjastoa. Kuvitellaan, että tämä resurssi epäonnistui tai se estettiin tietyssä maassa. Tällainen tilanne johtaa sivuston logiikan rikkomiseen.
Saat selville, kuinka sivustosi toimii, kun jokin ulkoinen palvelu ei ole käytettävissä, käyttämällä SPOF-osiota .
SPOF-osio osoitteessa webpagetest.org
▍ Entäpä materiaalien välimuistiin liittyvät ongelmat selaimissa? (vinkki: se on myytti)
Saatat ajatella, että julkisten CDN-verkkojen käyttö johtaisi automaattisesti parempaan resurssien suorituskykyyn, koska näillä palveluilla on melko laadukkaat verkot ja niitä levitetään ympäri maailmaa. Mutta kaikki on itse asiassa hieman monimutkaisempaa.
Oletetaan, että meillä on useita eri sivustoja: website1.com, website2.com, website3.com. Kaikki nämä sivustot käyttävät jQuery-kirjastoa. Yhdistämme sen heihin käyttämällä CDN-verkkoa, esimerkiksi - googleapis.com. Voit odottaa, että selain lataa ja tallentaa kirjaston välimuistiin kerran ja käyttää sitä sitten kaikilla kolmella sivustolla. Tämä voi vähentää verkon kuormitusta. Ehkä tämän avulla voit säästää rahaa jossain ja parantaa resurssien suorituskykyä. Käytännön näkökulmasta kaikki näyttää erilaiselta. Esimerkiksi Safarissa on ominaisuus nimeltä : Välimuisti käyttää kahta avainta asiakirjan lähteen ja kolmannen osapuolen resurssin lähteen perusteella. hyvä artikkeli tästä aiheesta.
vanhat opinnot и , sekä uudemmat Paul Calvano, osoita, että resursseja ei tallenneta selaimen välimuistiin niin kauan kuin voisi odottaa: "Projektin omien ja kolmannen osapuolen resurssien välimuistissa on vakava ero. Puhumme CSS:stä ja verkkofonteista. Nimittäin 95 prosentilla alkuperäisistä kirjasimista on välimuistin käyttöikä yli viikon, kun taas 50 prosentilla kolmannen osapuolen kirjasimista on alle viikon välimuisti! Tämä antaa verkkokehittäjille pakottavan syyn isännöidä fonttitiedostoja itse!
Tämän seurauksena, jos isännöit muiden ihmisten sisältöä, et huomaa selaimen välimuistin aiheuttamia suorituskykyongelmia.
Nyt kun olemme käsitelleet kolmannen osapuolen itseisännöinnin vahvuudet, puhutaanpa siitä, kuinka erottaa tämän lähestymistavan hyvä toteutus huonosta.
Huono: Paholainen on yksityiskohdissa
Kolmannen osapuolen resurssien siirtäminen omaan verkkotunnukseesi ei onnistu automaattisesti varmistamatta, että kyseiset resurssit on tallennettu oikein välimuistiin.
Yksi suurimmista ongelmista tässä on välimuistiin kuluva aika. Esimerkiksi versiotiedot sisältyvät kolmannen osapuolen komentosarjanimiin, kuten tämä: jquery-3.4.1.js. Tällainen tiedosto ei muutu tulevaisuudessa, eikä se aiheuta ongelmia sen välimuistissa.
Mutta jos jotakin versiointijärjestelmää ei käytetä tiedostojen kanssa työskennellessä, välimuistissa olevat komentosarjat, joiden sisältö muuttuu tiedostonimen pysyessä muuttumattomana, voivat vanhentua. Tämä voi olla vakava ongelma, koska se ei esimerkiksi salli automaattisten tietoturvakorjausten lisäämistä komentosarjoihin, jotka asiakkaiden on saatava mahdollisimman nopeasti. Kehittäjän on pyrittävä päivittämään tällaiset komentosarjat välimuistissa. Lisäksi tämä voi aiheuttaa sovellusvirheitä johtuen siitä, että asiakkaalla välimuistista käytetty koodi eroaa sen koodin uusimmasta versiosta, jota varten projektin palvelinosa on suunniteltu.
Totta, jos puhumme usein päivitettävistä materiaaleista (tunnisteiden hallintaohjelmat, ratkaisut A/B-testaukseen), niin niiden välimuistiin tallentaminen CDN-työkaluilla on ratkaistavissa oleva, mutta paljon monimutkaisempi tehtävä. Palvelut, kuten Commanders Act, tagien hallintaratkaisu, käyttävät webhookeja uusien versioiden julkaisussa. Tämä antaa sinulle mahdollisuuden pakottaa välimuistin tyhjennys CDN:ään tai, mikä vielä parempaa, mahdollisuuden pakottaa hajautus- tai URL-päivitys.
▍Sopeutuva materiaalitoimitus asiakkaille
Lisäksi kun puhumme välimuistista, meidän on otettava huomioon se tosiasia, että CDN:ssä käytetyt välimuistiasetukset eivät välttämättä sovellu joillekin kolmannen osapuolen resursseille. Tällaiset resurssit voivat esimerkiksi käyttää käyttäjäagentin nuuskimistekniikkaa (adaptiivinen käyttö) palvellakseen tiettyjä selaimia sisältöversioilla, jotka on optimoitu erityisesti kyseisille selaimille. Nämä tekniikat käyttävät säännöllisiä lausekkeita tai HTTP-otsikkotietojen tietokantaa selaimen ominaisuuksien selvittämiseksi. User-Agent. Kun he tietävät, minkä selaimen kanssa he ovat tekemisissä, he antavat sille siihen suunniteltuja materiaaleja.
Tässä voit muistaa kaksi palvelua. Ensimmäinen on googlefonts.com. Toinen on polyfill.io. Google Fonts -palvelu tarjoaa tietylle resurssille erilaisia CSS-koodeja selaimen ominaisuuksien mukaan (antaa linkkejä woff2-resursseihin käyttämällä unicode-range).
Tässä on parin eri selaimilla tehdyn Google Fonts -kyselyn tulokset.
Google Fonts -kyselytulos Chromesta
IE10:stä suoritetun Google Fonts -kyselyn tulos
Polyfill.io antaa selaimelle vain sen tarvitsemat monitäytteet. Tämä tehdään suorituskykysyistä.
Katsotaanpa esimerkiksi, mitä tapahtuu, jos suoritat seuraavan pyynnön eri selaimista:
Vastauksena tällaiseen IE10:stä suoritettuun pyyntöön vastaanotetaan 34 kilotavua tietoa. Ja vastaus siihen, joka suoritetaan Chromesta, on tyhjä.
Vihainen: Joitakin yksityisyyttä koskevia näkökohtia
Tämä kohta on järjestyksessä viimeinen, mutta ei vähiten tärkeä. Asia on siinä, että kolmannen osapuolen resurssien itseisännöinti projektin pääverkkotunnuksella tai sen aliverkkotunnuksella voi vaarantaa käyttäjien yksityisyyden ja vaikuttaa negatiivisesti pääverkkoprojektiin.
Jos CDN-järjestelmääsi ei ole määritetty oikein, saatat päätyä lähettämään verkkotunnuksesi evästeet kolmannen osapuolen palveluun. Jos oikeaa suodatusta ei ole järjestetty CDN-tasolla, istuntoevästeet, joita ei normaalisti voi käyttää JavaScriptissä (ja httponly), voidaan lähettää ulkomaiselle isännälle.
Juuri näin voi tapahtua seuraajille, kuten Eulerian tai Criteo. Kolmannen osapuolen seurantalaitteet ovat saattaneet asettaa evästeeseen yksilöllisen tunnisteen. Jos ne olivat osa sivuston materiaaleja, he saattoivat lukea tunnisteen oman harkintansa mukaan, kun käyttäjä työskenteli eri verkkoresurssien parissa.
Nykyään useimmat selaimet sisältävät suojauksen tämän tyyppistä seurantatoimintoa vastaan. Seurauksena on, että seurantalaitteet käyttävät nyt tekniikkaa naamioituen omiksi käsikirjoituksikseen eri projekteihin. Nimittäin seurantaohjelmat tarjoavat sivuston omistajille CNAME:n lisäämisen asetuksiinsa tietylle verkkotunnukselle, jonka osoite näyttää yleensä satunnaiselta merkkijoukolta.
Vaikka ei ole suositeltavaa asettaa verkkosivuston evästeitä kaikkien aliverkkotunnusten saataville (esimerkiksi - *.website.com), monet sivustot tekevät tämän. Tässä tapauksessa tällaiset evästeet lähetetään automaattisesti naamioituun kolmannen osapuolen seurantaohjelmaan. Tämän seurauksena emme voi enää puhua mistään yksityisyydestä.
Sama tapahtuu myös HTTP-otsikoiden kanssa , jotka lähetetään vain pääverkkotunnukseen, koska niitä voidaan käyttää luomiseen käyttäjä. Varmista, että käyttämäsi CDN-palvelu suodattaa nämä otsikot oikein.
Tulokset
Jos aiot ottaa pian käyttöön kolmannen osapuolen resurssien itseisännöinnin, anna minun antaa sinulle neuvoja:
- Isännöi tärkeimpiä JS-kirjastojasi, fonttejasi ja CSS-tiedostojasi. Tämä vähentää sivuston epäonnistumisen tai suorituskyvyn heikkenemisen riskiä, koska sivustolle tärkeä resurssi ei ole käytettävissä kolmannen osapuolen palvelun vian vuoksi.
- Ennen kuin tallennat kolmannen osapuolen resursseja CDN:ään välimuistiin, varmista, että tiedostojen nimeämisessä käytetään jotakin versiointijärjestelmää tai että voit hallita näiden resurssien elinkaarta manuaalisesti tai automaattisesti nollaamalla CDN-välimuistin, kun julkaiset uuden version käsikirjoitus.
- Ole erittäin varovainen CDN:n, välityspalvelimen ja välimuistin asetuksissa. Näin voit estää evästeiden lähettämisen projektillesi tai otsikoille
Client-Hintskolmannen osapuolen palvelut.
Hyvä lukijat! Isännöitkö palvelimillasi muiden materiaalia, joka on erittäin tärkeää projektisi toiminnan kannalta?
Lähde: will.com