Î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
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.
Resursele terțelor părți sunt descărcate din surse externe (preluate de la
Resursele terțelor părți sunt stocate în același loc ca și restul materialelor site-ului (preluate de la
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.
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
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ă
studii vechi
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.
Rezultatul interogării Google Fonts din Chrome
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:
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
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
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.?
Sursa: www.habr.com