În ultimii ani, tot mai multe platforme pentru optimizarea proiectelor frontend oferă opțiuni de auto-găzduire sau de proxy pentru resurse externe. Akamai permite definirea pentru URL-urile create în mod autonom. Cloudflare dispune de tehnologia Edge Workers. Fasterzine poate URL-urile de pe pagini astfel încât acestea să indice resurse externe aflate pe domeniul principal al site-ului.
Dacă știți că serviciile externe utilizate în proiectul dumneavoastră nu se schimbă foarte des și că procesul de livrare a acestora către clienți poate fi îmbunătățit, atunci cu siguranță vă gândiți la proxy-ul acestor servicii. Prin această abordare, puteți „aproxima” aceste resurse de utilizatori și obține un control mai complet asupra caching-ului lor pe partea clientului. În plus, aceasta ajută la protejarea utilizatorilor de probleme cauzate de „căderea” serviciului extern sau degradarea performanței acestuia.
Avantaj: creșterea performanței
Auto-găzduirea resurselor externe îmbunătățește performanța într-un mod destul de evident. Browser-ul nu trebuie să facă o nouă solicitare DNS, nu trebuie să stabilească o conexiune TCP și să efectueze un handshake TLS pe un domeniu extern. Modul în care auto-găzduirea resurselor externe influențează performanța poate fi observat comparând cele două ilustrații următoare.
Resurse externe sunt încărcate din surse externe (preluat )
Resurse externe sunt stocate acolo unde sunt și celelalte materiale ale site-ului (preluat )
Situația este îmbunătățită și de faptul că browser-ul va folosi capabilitățile de multiplexare și prioritizare a datelor pe o conexiune HTTP/2 deja stabilită cu domeniul principal.
Dacă nu găzduiți resurse externe, acestea, fiind încărcate de pe un domeniu diferit de cel principal, nu vor putea fi prioritizate. Acest lucru va duce la o competiție între ele pentru lățimea de bandă a clientului. Aceasta poate cauza ca timpul de încărcare al materialelor critice pentru formarea paginii să fie mult mai mare decât timpul ce ar putea fi obținut în condiții ideale. prezentarea despre prioritizarea HTTP/2, în care totul este explicat foarte clar.
Se poate presupune că utilizarea atributelor în linkurile către resurse externe preconnect va ajuta la rezolvarea problemei. Totuși, dacă vor exista prea multe linkuri către domenii diferite, acest lucru ar putea, de fapt, supraîncărca linia de comunicație în cel mai critic moment.
Dacă găzduiești resurse externe pe cont propriu — poți controla modul în care aceste resurse sunt livrate clientului. Mai exact, este vorba despre următoarele:
- Poți asigura aplicarea unui algoritm de comprimare a datelor, cel mai potrivit pentru fiecare browser (Brotli/gzip).
- Poți crește timpul de cache pentru resurse, care de obicei, chiar și la cei mai cunoscuți furnizori, nu este foarte mare (de exemplu, valoarea corespunzătoare pentru eticheta GA este setată la 30 de minute).
Poți chiar să extinzi timpul TTL pentru resursă, de exemplu, până la un an, integrând materialele corespunzătoare în strategia ta de gestionare a cache-ului (hash-uri URL, versiuni și așa mai departe). Despre aceasta vom discuta mai jos.
▍Protecție împotriva întreruperilor în funcționarea serviciilor externe sau a deconectării acestora
Un alt aspect interesant al găzduirii autonome a resurselor externe este că aceasta permite atenuarea riscurilor legate de întreruperile serviciilor externe. Să presupunem că soluția externă pe care o folosești pentru testarea A/B-urilor este implementată sub formă de script blocant, care este încărcat în secțiunea de header a paginii. Acest script se încarcă încet. Dacă încărcarea scriptului respectiv eșuează — pagina va fi goală. Dacă încărcarea sa durează foarte mult timp — pagina va apărea cu un întârziere semnificativă. Sau, să presupunem că în proiect se folosește o bibliotecă, care este încărcată dintr-o resursă CDN externă. Să ne imaginăm că această resursă a suferit o defecțiune sau a fost blocată într-o anumită țară. O astfel de situație va duce la perturbarea logicii de funcționare a site-ului.
Pentru a afla cum funcționează site-ul tău în condiții de inaccesibilitate a unei resurse externe, poți folosi secțiunea SPOF de pe .
Secțiunea SPOF de pe webpagetest.org
▍Ce zici de problemele de cache ale materialelor în browsere? (sugestie: este un mit)
S-ar putea să credeți că utilizarea CDN-urilor publice va conduce automat la o performanță mai bună a resurselor, deoarece aceste servicii dispun de rețele de calitate și sunt distribuite în întreaga lume. Dar, de fapt, lucrurile sunt puțin mai complicate.
Să presupunem că avem mai multe site-uri diferite: website1.com, website2.com, website3.com. Toate aceste site-uri utilizează biblioteca jQuery. O conectăm prin CDN, de exemplu — googleapis.com. Ne așteptăm ca browserul să încarce și să cacheze biblioteca o singură dată, apoi să o folosească pentru toate cele trei site-uri. Acest lucru ar putea reduce încărcătura pe rețea. Poate că va economisi undeva și va ajuta la îmbunătățirea performanței resurselor. Dintr-o perspectivă practică, aspectele sunt diferite. De exemplu, Safari a implementat o funcționalitate numită : în cache se folosesc chei duble, bazate pe sursa documentului și pe sursa resursei externe. un articol bun despre acest subiect.
Studiile vechi și , precum și mai recente Pola Calvano, arată că resursele nu sunt stocate în cache-urile browserelor atât de mult timp cum ne-am aștepta: „Există o discrepanță serioasă între timpul de caching al resurselor proprii și al celor externe din proiect. Este vorba despre CSS și fonturi web. În special, perioada de caching pentru 95% dintre fonturile proprii depășește o săptămână, în timp ce perioada de caching pentru 50% dintre fonturile externe este mai mică de o săptămână! Acest lucru oferă dezvoltatorilor web motive întemeiate pentru a găzdui singuri fișierele de fonturi!”
Prin urmare, dacă veți găzdui materiale externe, nu veți observa probleme de performanță cauzate de caching-ul browserului.
Acum, când am examinat avantajele găzduirii proprii a resurselor externe, să discutăm despre cum să facem distincția între o implementare bună a acestei abordări și una slabă.
Slab: diavolul stă în detalii
Mutarea resurselor externe pe propriul domeniu nu poate fi realizată automat, fără a se asigura că aceste resurse sunt corect cache-uite.
Una dintre problemele principale aici este timpul de caching. De exemplu, informațiile despre versiuni sunt incluse în numele scripturilor externe cam așa: jquery-3.4.1.js. Acest fișier nu se va schimba în viitor, astfel că nu va provoca probleme cu caching-ul său.
Dar, dacă nu se aplică un anumit sistem de versionare pentru gestionarea fișierelor, scripturile cached, a căror conținut se schimbă fără a modifica numele fișierului, pot deveni depășite. Acest lucru poate deveni o problemă serioasă, deoarece, de exemplu, nu permite actualizarea automată a scripturilor cu corecții de securitate care ar trebui să ajungă la clienți cât mai repede posibil. Dezvoltatorul va trebui să depună eforturi pentru a actualiza aceste scripturi în cache. În plus, acest lucru poate provoca erori în funcționarea aplicației, datorită faptului că codul utilizat de client din cache diferă de versiunea actualizată a codului, care este așteptată de partea de server a proiectului.
Adevărat, când vorbim despre materiale care se actualizează frecvent (manageri de etichete, soluții pentru testare A/B), caching-ul lor pe CDN devine o sarcină complexă, deși realizabilă. Servicii precum Commanders Act, soluții pentru gestionarea etichetelor, folosesc webhooks la publicarea noilor versiuni. Aceasta permite organizarea ștergerii cache-ului pe CDN sau, și mai bine, posibilitatea de a solicita actualizarea hash-ului sau versiunii URL-ului.
▍Livrarea adaptivă a materialelor către clienți
În plus, atunci când discutăm despre caching, trebuie să luăm în considerare și faptul că setările de caching utilizate pe CDN pot să nu fie potrivite pentru anumite resurse externe. De exemplu, aceste resurse pot folosi tehnologia sniffing a agentului utilizator (user agent sniffing, adaptive serving) pentru a livra versiunile materialelor optimizate specific pentru browserele respective. Aceste tehnologii, pentru a determina capacitățile browserului, se bazează pe expresii regulate sau pe o bază de date care colectează informații despre antetele HTTP. User-Agent. Odată ce află cu ce browser au de-a face, îi livrează materiale adaptate acestuia.
Aici putem menționa două servicii. Primul — googlefonts.com. Al doilea — polyfill.io. Serviciul Google Fonts oferă, pentru o anumită resursă, diferit cod CSS, în funcție de capacitățile browserului (oferind linkuri către resurse woff2, folosind unicode-range).
Iată rezultatele câtorva solicitări către Google Fonts, efectuate din browsere diferite.
Rezultatul cererii către Google Fonts, efectuat din Chrome
Rezultatul cererii către Google Fonts, efectuat din IE10
Polyfill.io furnizează browserului doar acele polyfill-uri de care acesta are nevoie. Acest lucru se face din motive de performanță.
De exemplu, să ne uităm la ce se va întâmpla dacă efectuăm următoarea cerere din diferite browsere:
Ca răspuns la o astfel de cerere, efectuată din IE10, se va primi 34 Kb de date. Răspunsul efectuat din Chrome va fi gol.
Zevil: unele considerații legate de confidențialitate
Acest punct este ultimul ca ordine, dar nu și ca importanță. Este vorba despre faptul că găzduirea independentă a resurselor externe pe domeniul principal al proiectului sau pe subdomeniul său poate compromite confidențialitatea utilizatorilor și poate avea un impact negativ asupra proiectului web principal.
Dacă sistemul dumneavoastră CDN este configurat greșit, totul se poate termina cu trimiterea cookie-urilor dumneavoastră către un serviciu extern. Dacă la nivelul CDN nu există o filtrare corectă, cookie-urile de sesiune, care în mod normal nu pot fi utilizate în JavaScript (cu atributul httponly), pot fi trimise către un host străin.
Exact aceasta se poate întâmpla cu trackerele, precum Eulerian sau Criteo. Trackerele externe ar fi putut seta un identificator unic în cookie-uri. Acestea, dacă erau incluse în materialele site-urilor, puteau citi identificatorul la discreția lor în timpul interacțiunii utilizatorului cu diferite resurse web.
În zilele noastre, majoritatea browserelor includ protecție împotriva unor astfel de comportamente ale trackerelor. Ca urmare, acum trackerele folosesc tehnologia , mascându-se sub propriile scripts ale diferitelor proiecte. Așadar, trackerele sugerează proprietarilor de site-uri să adauge în setările lor CNAME pentru un anumit domeniu, a cărui adresă arată de obicei ca un set aleator de caractere.
Deși nu este recomandat să faceți cookie-urile site-ului disponibile pentru toate subdomeniile (de exemplu — *.website.com), pe multe site-uri acest lucru se face. În acest caz, aceste cookie-uri sunt trimise automat către un tracker extern mascat. Ca rezultat, nu mai putem vorbi despre confidențialitate.
În plus, același lucru se întâmplă și cu antetele HTTP , care sunt trimise doar domeniului principal, deoarece acestea pot fi utilizate pentru a crea a utilizatorului. Asigurați-vă că serviciul CDN pe care îl folosiți filtrează corect aceste antete.
Concluzii
Dacă intenționați să implementați în curând găzduirea independentă a resurselor terțe, permiteți-mi să vă ofer câteva sfaturi:
- Găzduiți cele mai importante biblioteci JS, fonturi și fișiere CSS pe serverele proprii. Acest lucru va reduce riscul de cădere a site-ului sau de scădere a performanței din cauza faptului că o resursă esențială pentru funcționarea site-ului devine indisponibilă din cauza unui serviciu terț.
- Înainte de a cache-ui resursele terțe pe CDN, asigurați-vă că fișierele lor sunt denumite folosind un sistem de versionare sau că aveți control asupra ciclului de viață al acestor resurse, resetând manual sau automat cache-ul CDN la publicarea unei versiuni noi a scriptului.
- Fiți foarte atenți la setările CDN, serverului proxy și cache-ului. Acest lucru vă va ajuta să preveniți trimiterea cookie-urilor proiectului dvs. sau a anteturilor
Client-Hintsserviciilor terțe.
Stimați cititori! Oferiți pe serverele dumneavoastră materiale externe care sunt extrem de importante pentru funcționarea proiectelor dumneavoastră?
Sursa: habr.com
