En els darrers anys, cada cop hi ha més plataformes per optimitzar projectes front-end ofereixen oportunitats per a l'autoallotjament o el proxy de recursos de tercers. Akamai us permet configurar per als URL autogenerats. Cloudflare té tecnologia Edge Workers. Fasterzine pot URL a les pàgines perquè apuntin a recursos de tercers situats al domini principal del lloc.
Si sabeu que els serveis de tercers utilitzats en el vostre projecte no canvien gaire sovint i que el procés de lliurament d'ells als clients es podria millorar, probablement esteu pensant a utilitzar aquests serveis. Amb aquest enfocament, podeu acostar aquests recursos als vostres usuaris i obtenir un control més complet sobre la seva memòria cau al costat del client. Això, a més, permet protegir els usuaris dels problemes causats pel "crash" d'un servei de tercers o la degradació del seu rendiment.
Bo: rendiment millorat
L'autoallotjament dels recursos d'una altra persona millora el rendiment d'una manera molt òbvia. El navegador no necessita tornar a accedir al DNS, no necessita establir una connexió TCP i realitzar una encaixada de mans TLS en un domini de tercers. Podeu veure com l'autoallotjament dels recursos d'una altra persona afecta el rendiment comparant les dues xifres següents.
Els recursos de tercers es baixen de fonts externes (pres de )
Els recursos de tercers s'emmagatzemen al mateix lloc que la resta de materials del lloc (pres de )
La situació també es veu millorada pel fet que el navegador utilitzarà la capacitat de multiplexar i prioritzar dades de la connexió HTTP/2 que ja s'ha establert amb el domini principal.
Si no allotgeu recursos de tercers, com que es carregaran des d'un domini diferent del principal, no es poden prioritzar. Això farà que competiran entre ells per l'ample de banda del client. Això pot provocar temps de càrrega per al contingut crític per crear una pàgina que sigui molt més llarg del que es podria aconseguir en circumstàncies ideals. parlar sobre la priorització HTTP/2 que explica molt bé tot això.
Es pot suposar que l'ús d'atributs en enllaços a recursos externs preconnect ajudarà a resoldre el problema. Tanmateix, si hi ha massa d'aquests enllaços a diferents dominis, en realitat pot sobrecarregar la línia de comunicació en el moment més crucial.
Si allotgeu recursos de tercers vosaltres mateixos, podeu controlar exactament com es donen aquests recursos al client. És a dir, estem parlant del següent:
- Podeu assegurar-vos que s'utilitza l'algoritme de compressió de dades que millor s'adapti a cada navegador (Brotli/gzip).
- Podeu augmentar el temps d'emmagatzematge a la memòria cau per als recursos que normalment no són especialment llargs, fins i tot amb els proveïdors més coneguts (per exemple, el valor corresponent per a l'etiqueta GA s'estableix en 30 minuts).
Fins i tot podeu ampliar el TTL d'un recurs a, per exemple, un any incorporant contingut rellevant a la vostra estratègia de gestió de la memòria cau (hash d'URL, versions, etc.). En parlarem a continuació.
▍Protecció contra interrupcions en el funcionament de serveis de tercers o la seva aturada
Un altre aspecte interessant de l'autoallotjament de recursos de tercers és que us permet mitigar els riscos associats a les interrupcions dels serveis de tercers. Suposem que la solució de prova A/B de tercers que utilitzeu s'implementa com a script de bloqueig que es carrega a la secció de capçalera de la pàgina. Aquest script es carrega lentament. Si l'script corresponent no es carrega, la pàgina estarà buida. Si es triga molt a carregar-se, la pàgina apareixerà amb un gran retard. O bé, suposem que el projecte utilitza una biblioteca baixada d'un recurs CDN de tercers. Imaginem que aquest recurs ha patit un fracàs o ha estat bloquejat en un determinat país. Aquesta situació comportarà una violació de la lògica del lloc.
Per saber com funciona el vostre lloc quan algun servei extern no està disponible, podeu utilitzar la secció SPOF a .
Secció SPOF a webpagetest.org
▍Què passa amb els problemes amb la memòria cau dels materials als navegadors? (Pista: és un mite)
Podríeu pensar que l'ús de CDN públics conduiria automàticament a un millor rendiment dels recursos, ja que aquests serveis tenen xarxes d'alta qualitat i es distribueixen arreu del món. Però en realitat tot és una mica més complicat.
Suposem que tenim diversos llocs web: website1.com, website2.com, website3.com. Tots aquests llocs utilitzen la biblioteca jQuery. El connectem a ells mitjançant un CDN, per exemple: googleapis.com. Podeu esperar que el navegador baixi i emmagatzemi la biblioteca una vegada, i després l'utilitzi als tres llocs. Això podria reduir la càrrega a la xarxa. Potser això us permetrà estalviar diners en algun lloc i ajudarà a millorar el rendiment dels recursos. Des d'un punt de vista pràctic, tot sembla diferent. Per exemple, Safari té una funció anomenada : La memòria cau utilitza claus duals basades en la font del document i la font del recurs de tercers. bon article sobre aquest tema.
estudis antics и , així com més recents Paul Calvano, demostren que els recursos no s'emmagatzemen a la memòria cau del navegador durant tant de temps com podríem esperar: “Hi ha una bretxa greu entre el temps d'emmagatzematge en memòria cau dels recursos propis d'un projecte i de tercers. Estem parlant de CSS i tipus de lletra web. És a dir, el 95% dels tipus de lletra nadius tenen una vida de la memòria cau de més d'una setmana, mentre que el 50% dels tipus de lletra de tercers tenen una vida de la memòria cau de menys d'una setmana. Això dóna als desenvolupadors web una raó convincent per allotjar fitxers de tipus de lletra ells mateixos!
Com a resultat, si allotgeu contingut d'altres persones, no notareu cap problema de rendiment causat per la memòria cau del navegador.
Ara que hem cobert els punts forts de l'autoallotjament de tercers, parlem de com distingir una bona implementació d'aquest enfocament d'una dolenta.
El dolent: el diable està en els detalls
Moure recursos de tercers al vostre propi domini no es pot fer automàticament sense assegurar-vos que aquests recursos s'emmagatzemen correctament a la memòria cau.
Un dels principals problemes aquí és el temps de memòria cau. Per exemple, la informació de la versió s'inclou en noms d'script de tercers com aquest: jquery-3.4.1.js. Aquest fitxer no canviarà en el futur i, com a resultat, no causarà cap problema amb la seva memòria cau.
Però si no s'utilitza algun esquema de versions quan es treballa amb fitxers, els scripts en memòria cau, el contingut dels quals canvia mentre el nom del fitxer no es modifica, poden quedar obsolets. Això pot ser un problema greu, ja que, per exemple, no permet afegir pedaços de seguretat automatitzats als scripts que els clients necessiten rebre el més aviat possible. El desenvolupador haurà de fer un esforç per actualitzar aquests scripts a la memòria cau. A més, això pot provocar errors en l'aplicació a causa del fet que el codi utilitzat al client de la memòria cau difereix de l'última versió del codi per a la qual està dissenyada la part del servidor del projecte.
És cert que si parlem de materials que s'actualitzen amb freqüència (gestors d'etiquetes, solucions per a proves A/B), aleshores guardar-los en memòria cau amb eines CDN és una tasca que es pot resoldre, però és molt més complexa. Serveis com Commanders Act, una solució de gestió d'etiquetes, utilitzen webhooks quan es publiquen noves versions. Això us ofereix la possibilitat de forçar un buidat de memòria cau al CDN o, millor encara, la possibilitat de forçar una actualització hash o URL.
▍Enviament adaptatiu de materials als clients
A més, quan parlem de la memòria cau, hem de tenir en compte el fet que la configuració de la memòria cau que s'utilitza a la CDN pot no ser adequada per a alguns recursos de tercers. Per exemple, aquests recursos poden utilitzar la tecnologia de rastreig d'agents d'usuari (publicació adaptativa) per servir navegadors específics amb versions de contingut optimitzades específicament per a aquests navegadors. Aquestes tecnologies es basen en expressions regulars, o en una base de dades d'informació de capçalera HTTP, per esbrinar les capacitats del navegador. User-Agent. Un cop saben amb quin navegador estan tractant, li donen materials dissenyats per a això.
Aquí podeu recordar dos serveis. El primer és googlefonts.com. El segon és polyfill.io. El servei Google Fonts proporciona, per a un recurs determinat, diversos codis CSS, en funció de les capacitats del navegador (donant enllaços a recursos woff2 mitjançant unicode-range).
Aquests són els resultats d'un parell de consultes de Google Fonts fetes des de diferents navegadors.
Resultat de la consulta de Google Fonts de Chrome
Resultat de la consulta de Google Fonts executada des d'IE10
Polyfill.io ofereix al navegador només els polyfills que necessita. Això es fa per raons de rendiment.
Per exemple, fem una ullada a què passa si executeu la sol·licitud següent des de diferents navegadors:
En resposta a aquesta sol·licitud executada des d'IE10, es rebran 34 KB de dades. I la resposta, executada des de Chrome, estarà buida.
Enfadat: algunes consideracions de privadesa
Aquest punt és l'últim en ordre, però no menys important. La qüestió és que l'autoallotjament de recursos de tercers al domini principal del projecte o al seu subdomini pot posar en perill la privadesa dels usuaris i afectar negativament el projecte web principal.
Si el vostre sistema CDN no està configurat correctament, és possible que acabeu enviant les galetes del vostre domini a un servei de tercers. Si no s'organitza el filtratge adequat a nivell de CDN, les galetes de sessió, que normalment no es poden utilitzar en JavaScript (amb el httponly), es pot enviar a un host estranger.
Això és exactament el que pot passar amb rastrejadors com Eulerian o Criteo. És possible que els rastrejadors de tercers hagin establert un identificador únic a la galeta. Si formaven part dels materials del lloc, podrien llegir l'identificador a la seva discreció mentre l'usuari treballava amb diferents recursos web.
Actualment, la majoria dels navegadors inclouen protecció contra aquest tipus de comportament de seguiment. Com a resultat, els rastrejadors ara utilitzen tecnologia , disfressats com els seus propis guions per a diversos projectes. És a dir, els rastrejadors ofereixen als propietaris de llocs afegir un CNAME a la seva configuració per a un determinat domini, l'adreça del qual normalment sembla un conjunt aleatori de caràcters.
Tot i que no es recomana posar galetes de llocs web disponibles per a tots els subdominis (per exemple, *.website.com), molts llocs ho fan. En aquest cas, aquestes galetes s'envien automàticament a un rastrejador de tercers disfressat. Com a resultat, ja no podem parlar de cap privadesa.
A més, passa el mateix amb les capçaleres HTTP , que només s'envien al domini principal, ja que es poden utilitzar per crear usuari. Assegureu-vos que el servei CDN que utilitzeu filtra aquestes capçaleres correctament.
Resultats de
Si teniu previst implementar l'allotjament automàtic de recursos de tercers aviat, deixeu-me donar-vos alguns consells:
- Allotja les teves biblioteques JS, tipus de lletra i fitxers CSS més importants. Això reduirà el risc de fallada del lloc o degradació del rendiment a causa d'un recurs vital per al lloc que no està disponible per culpa d'un servei de tercers.
- Abans d'emmagatzemar a la memòria cau recursos de tercers en un CDN, assegureu-vos que s'utilitza algun tipus de sistema de control de versions quan s'anomenen els fitxers, o que podeu gestionar el cicle de vida d'aquests recursos restablint manualment o automàticament la memòria cau del CDN quan publiqueu una versió nova de el guió.
- Aneu molt amb compte amb la vostra configuració de CDN, servidor intermediari i memòria cau. Això us permetrà evitar que el vostre projecte o capçaleres s'enviïn galetes
Client-Hintsserveis de tercers.
Benvolguts lectors! Allotgeu als vostres servidors materials d'altres persones que són extremadament importants per al funcionament dels vostres projectes?
Font: www.habr.com