Auto-găzduire de resurse terță parte: bine, rău, urât

În ultimii ani, tot mai multe platforme de optimizare a proiectelor front-end oferă oportunități de auto-găzduire sau de proxy a resurselor terțelor părți. Akamai vă permite să setați parametri specifici pentru URL-uri autogenerate. Cloudflare are tehnologia Edge Workers. Fasterzine poate rescrie URL-uri de pe pagini, astfel încât acestea să trimită către resurse terță parte situate pe domeniul principal al site-ului.

Auto-găzduire de resurse terță parte: bine, rău, urât

Dacă știi că serviciile de la terți utilizate în proiectul tău nu se schimbă foarte des și că procesul de livrare a acestora către clienți ar putea fi îmbunătățit, atunci probabil că te gândești la proxy astfel de servicii. Cu această abordare, puteți aduce aceste resurse mai aproape de utilizatorii dvs. și puteți obține un control mai complet asupra stocării lor în cache pe partea clientului. Acest lucru, în plus, vă permite să protejați utilizatorii de problemele cauzate de „defectarea” unui serviciu terță parte sau de degradarea performanței acestuia.

Bine: Performanță îmbunătățită

Auto-găzduirea resurselor altcuiva îmbunătățește performanța într-un mod foarte evident. Browserul nu trebuie să acceseze din nou DNS, nu trebuie să stabilească o conexiune TCP și să efectueze o strângere de mână TLS pe ​​un domeniu terță parte. Puteți vedea cum auto-găzduirea resurselor altcuiva afectează performanța comparând următoarele două cifre.

Auto-găzduire de resurse terță parte: bine, rău, urât
Resursele terțelor părți sunt descărcate din surse externe (preluate de la prin urmare)

Auto-găzduire de resurse terță parte: bine, rău, urât
Resursele terțelor părți sunt stocate în același loc ca și restul materialelor site-ului (preluate de la prin urmare)

Situația este îmbunătățită și de faptul că browserul va folosi capacitatea de a multiplexa și prioritiza datele din conexiunea HTTP/2 care a fost deja stabilită cu domeniul principal.

Dacă nu găzduiești resurse terțe, atunci, deoarece acestea vor fi încărcate dintr-un domeniu diferit de cel principal, nu pot fi prioritizate. Acest lucru îi va determina să concureze între ei pentru lățimea de bandă a clientului. Acest lucru poate duce la timpi de încărcare a conținutului esențial pentru construirea unei pagini, care este mult mai lung decât ceea ce ar fi realizabil în circumstanțe ideale. Aici vorbim despre prioritizarea HTTP/2 care explică foarte bine toate acestea.

Se poate presupune că utilizarea atributelor în legăturile către resurse externe preconnect va ajuta la rezolvarea problemei. Cu toate acestea, dacă există prea multe dintre aceste legături către domenii diferite, poate supraîncărca linia de comunicare în cel mai important moment.

Dacă găzduiți singur resurse terțe, puteți controla cum exact aceste resurse sunt oferite clientului. Și anume, vorbim despre următoarele:

  • Vă puteți asigura că este utilizat algoritmul de comprimare a datelor care se potrivește cel mai bine fiecărui browser (Brotli/gzip).
  • Puteți crește timpul de stocare în cache pentru resurse care de obicei nu sunt deosebit de lungi, chiar și cu cei mai cunoscuți furnizori (de exemplu, valoarea corespunzătoare pentru eticheta GA este setată la 30 de minute).

Puteți chiar extinde TTL pentru o resursă la, să zicem, un an prin încorporarea conținutului relevant în strategia dvs. de gestionare a stocării în cache (hash-uri URL, versiuni etc.). Despre asta vom vorbi mai jos.

▍Protecție împotriva întreruperilor în funcționarea serviciilor terților sau a opririi acestora

Un alt aspect interesant al găzduirii proprii a resurselor terțelor este că vă permite să reduceți riscurile asociate cu întreruperile serviciilor terțe. Să presupunem că soluția de testare A/B terță parte pe care o utilizați este implementată ca un script de blocare care se încarcă în secțiunea de cap a paginii. Acest script se încarcă lent. Dacă scriptul corespunzător nu se încarcă, pagina va fi goală. Dacă încărcarea durează foarte mult, pagina va apărea cu o întârziere mare. Sau să presupunem că proiectul folosește o bibliotecă încărcată dintr-o resursă CDN terță parte. Să ne imaginăm că această resursă a cunoscut un eșec sau a fost blocată într-o anumită țară. O astfel de situație va duce la o încălcare a logicii site-ului.

Pentru a afla cum funcționează site-ul dvs. atunci când un serviciu extern nu este disponibil, puteți utiliza secțiunea SPOF pe webpagetest.org.

Auto-găzduire de resurse terță parte: bine, rău, urât
Secțiunea SPOF pe webpagetest.org

▍Ce se întâmplă cu problemele legate de stocarea în cache a materialelor în browsere? (indiciu: este un mit)

S-ar putea să credeți că utilizarea CDN-urilor publice ar duce automat la o performanță mai bună a resurselor, deoarece aceste servicii au rețele de înaltă calitate și sunt distribuite în întreaga lume. Dar totul este de fapt puțin mai complicat.

Să presupunem că avem mai multe site-uri diferite: website1.com, website2.com, website3.com. Toate aceste site-uri folosesc biblioteca jQuery. Îl conectăm la ei folosind un CDN, de exemplu - googleapis.com. Vă puteți aștepta ca browserul să descarce și să memoreze în cache biblioteca o dată, apoi să o folosească pe toate cele trei site-uri. Acest lucru ar putea reduce sarcina în rețea. Poate că acest lucru vă va permite să economisiți bani undeva și să contribuiți la îmbunătățirea performanței resurselor. Din punct de vedere practic, totul arată diferit. De exemplu, Safari are o caracteristică numită Prevenirea inteligentă a urmăririi: Cache-ul folosește chei duale bazate pe sursa documentului și sursa resursei terță parte. Aici bun articol pe acest subiect.

studii vechi Yahoo и Facebook, precum și mai recente studiu Paul Calvano, arată că resursele nu sunt stocate în cache-urile browserului atâta timp cât ne-am putea aștepta: „Există un decalaj serios între timpul de stocare în cache al resurselor proprii ale unui proiect și ale terților. Vorbim despre CSS și fonturi web. Și anume, 95% dintre fonturile native au o durată de viață în cache de mai mult de o săptămână, în timp ce 50% dintre fonturile terțe au o durată de viață în cache de mai puțin de o săptămână! Acest lucru le oferă dezvoltatorilor web un motiv convingător să găzduiască ei înșiși fișierele cu fonturi!”

Drept urmare, dacă găzduiți conținutul altor persoane, nu veți observa probleme de performanță cauzate de memorarea în cache a browserului.

Acum că am acoperit punctele forte ale auto-găzduirii terților, să vorbim despre cum să distingem o implementare bună a acestei abordări de una proastă.

Cel rău: Diavolul este în detalii

Mutarea resurselor terță parte în propriul domeniu nu se poate face automat fără a vă asigura că astfel de resurse sunt stocate în cache în mod corespunzător.

Una dintre principalele probleme aici este timpul de cache. De exemplu, informațiile despre versiune sunt incluse în nume de script terță parte, cum ar fi: jquery-3.4.1.js. Un astfel de fișier nu se va schimba în viitor și, prin urmare, acest lucru nu va cauza probleme cu memorarea în cache.

Dar dacă o schemă de versiuni nu este utilizată atunci când lucrați cu fișiere, scripturile stocate în cache, al căror conținut se modifică în timp ce numele fișierului rămâne neschimbat, pot deveni învechite. Aceasta poate fi o problemă serioasă, deoarece, de exemplu, nu permite adăugarea de corecții automate de securitate la scripturile pe care clienții trebuie să le primească cât mai repede posibil. Dezvoltatorul va trebui să facă un efort pentru a actualiza astfel de scripturi în cache. În plus, acest lucru poate cauza defecțiuni ale aplicației din cauza faptului că codul utilizat pe client din cache diferă de cea mai recentă versiune a codului pentru care este proiectată partea de server a proiectului.

Adevărat, dacă vorbim despre materiale care sunt actualizate frecvent (manager de etichete, soluții pentru testarea A/B), atunci păstrarea lor în cache folosind instrumente CDN este o sarcină care poate fi rezolvată, dar este mult mai complexă. Servicii precum Commanders Act, o soluție de gestionare a etichetelor, folosesc webhook-uri atunci când publică versiuni noi. Acest lucru vă oferă posibilitatea de a forța o ștergere a memoriei cache pe CDN-ul sau, mai bine, abilitatea de a forța o actualizare hash sau URL.

▍Livrarea adaptativă a materialelor către clienți

În plus, atunci când vorbim despre stocarea în cache, trebuie să ținem cont de faptul că setările de cache utilizate pe CDN-ul pot să nu fie potrivite pentru unele resurse terțe. De exemplu, astfel de resurse pot utiliza tehnologia user agent sniffing (servire adaptivă) pentru a servi anumite browsere cu versiuni de conținut optimizate special pentru acele browsere. Aceste tehnologii se bazează pe expresii regulate sau pe o bază de date cu informații despre antetul HTTP, pentru a descoperi capabilitățile browserului. User-Agent. Odată ce știu cu ce browser au de-a face, îi oferă materiale concepute pentru el.

Aici vă puteți aminti două servicii. Primul este googlefonts.com. Al doilea este polyfill.io. Serviciul Google Fonts furnizează, pentru o anumită resursă, diverse coduri CSS, în funcție de capacitățile browserului (oferind link-uri către resurse woff2 folosind unicode-range).

Iată rezultatele câtorva interogări Google Fonts realizate din browsere diferite.

Auto-găzduire de resurse terță parte: bine, rău, urât
Rezultatul interogării Google Fonts din Chrome

Auto-găzduire de resurse terță parte: bine, rău, urât
Rezultatul interogării Google Fonts executată din IE10

Polyfill.io oferă browserului doar polifillurile de care are nevoie. Acest lucru se face din motive de performanță.

De exemplu, să aruncăm o privire la ce se întâmplă dacă executați următoarea solicitare din browsere diferite: https://polyfill.io/v3/polyfill.js?features=default

Ca răspuns la o astfel de solicitare executată de la IE10, vor fi primite 34 KB de date. Și răspunsul la acesta, executat din Chrome, va fi gol.

Furios: Câteva considerente de confidențialitate

Acest punct este ultimul în ordine, dar nu în ultimul rând important. Ideea este că auto-găzduirea resurselor terțe pe domeniul principal al proiectului sau pe subdomeniul acestuia poate pune în pericol confidențialitatea utilizatorilor și poate afecta negativ proiectul web principal.

Dacă sistemul dvs. CDN nu este configurat corect, este posibil să trimiteți cookie-urile domeniului dvs. către un serviciu terță parte. Dacă filtrarea adecvată nu este organizată la nivel CDN, atunci cookie-urile dvs. de sesiune, care în mod normal nu pot fi utilizate în JavaScript (cu httponly), pot fi trimise unei gazde străine.

Este exact ceea ce se poate întâmpla cu trackere precum Eulerian sau Criteo. Este posibil ca instrumentele de urmărire terță parte să fi setat un identificator unic în cookie. Dacă făceau parte din materialele site-ului, puteau citi identificatorul la discreția lor în timp ce utilizatorul lucra cu diferite resurse web.

În zilele noastre, majoritatea browserelor includ protecție împotriva acestui tip de comportament de urmărire. Drept urmare, trackerele folosesc acum tehnologia Mascarea CNAME, mascandu-se drept propriile scenarii pentru diverse proiecte. Și anume, trackerele oferă proprietarilor de site-uri să adauge un CNAME la setările lor pentru un anumit domeniu, a cărui adresă arată de obicei ca un set aleatoriu de caractere.

Deși nu este recomandat să puneți cookie-urile site-ului la dispoziție pentru toate subdomeniile (de exemplu - *.website.com), multe site-uri fac acest lucru. În acest caz, astfel de cookie-uri sunt trimise automat către un instrument de urmărire terță parte deghizat. Drept urmare, nu mai putem vorbi despre nicio confidențialitate.

De asemenea, același lucru se întâmplă și cu anteturile HTTP Client-Sfaturi, care sunt trimise numai către domeniul principal, deoarece pot fi folosite pentru a crea amprenta digitala utilizator. Asigurați-vă că serviciul CDN pe care îl utilizați filtrează corect aceste anteturi.

Rezultatele

Dacă intenționați să implementați în curând găzduirea proprie a resurselor terțelor părți, permiteți-mi să vă dau câteva sfaturi:

  • Găzduiește cele mai importante biblioteci JS, fonturi și fișiere CSS. Acest lucru va reduce riscul de defecțiune a site-ului sau de degradare a performanței din cauza unei resurse vitale pentru site-ul fiind indisponibilă din vina unui serviciu terță parte.
  • Înainte de a stoca în cache resurse terță parte pe un CDN, asigurați-vă că este utilizat un fel de sistem de versiuni la denumirea fișierelor lor sau că puteți gestiona ciclul de viață al acestor resurse prin resetarea manuală sau automată a memoriei cache CDN atunci când publicați o nouă versiune de scenariul.
  • Fiți foarte atenți la CDN-ul, serverul proxy și setările de cache. Acest lucru vă va permite să împiedicați trimiterea cookie-urilor pentru proiectul sau anteturile dvs Client-Hints servicii terților.

Dragi cititori! Găzduiți pe serverele dvs. materiale ale altor persoane care sunt extrem de importante pentru funcționarea proiectelor dvs.?

Auto-găzduire de resurse terță parte: bine, rău, urât
Auto-găzduire de resurse terță parte: bine, rău, urât

Sursa: www.habr.com

Adauga un comentariu