Cum ne-am îmbunătățit principalele elemente vitale web (studiu de caz)

Anul trecut, Google a început să sublinieze importanța Core Web Vitals și modul în care acestea reflectă experiența reală a unei persoane când vizitează site-uri de pe web. Performanța este o caracteristică de bază a companiei noastre, Instant Domain Search — este în nume. Imaginați-vă surpriza noastră când am constatat că scorurile noastre vitale nu erau grozave pentru mulți oameni. Calculatoarele noastre rapide și internetul prin fibră au mascat experiența pe care o au oamenii adevărați pe site-ul nostru. Nu a trecut mult timp până când o mare de notificări roșii „sărace” și galbene „trebuie îmbunătățite” din Google Search Console a avut nevoie de atenția noastră. Entropia câștigase și a trebuit să ne dăm seama cum să curățăm și cum să ne facem site-ul mai rapid.

Am înființat Instant Domain Search în 2005 și l-am păstrat ca o treabă secundară în timp ce lucram la o companie Y Combinator (Snipshot, W06), înainte de a lucra ca inginer software la Facebook. Recent, am devenit un grup mic, cu sediul în principal în Victoria, Canada și lucrăm la un număr lung de funcții noi și îmbunătățiri de performanță. Scorurile noastre slabe ale datelor vitale web și actualizarea Google care se profilează, ne-au determinat să găsim și să remediem aceste probleme.

Când a fost lansată prima versiune a site-ului, am creat-o cu PHP, MySQL și XMLHttpRequest. Internet Explorer 6 era pe deplin acceptat, Firefox câștiga cotă, iar Chrome mai era la câțiva ani de la lansare. De-a lungul timpului, am evoluat printr-o varietate de generatoare de site statice, cadre JavaScript și tehnologii de server. Stack-ul nostru front-end actual este React servit cu Next.js și un serviciu de backend încorporat Rust pentru a răspunde căutărilor noastre de nume de domeniu. Încercăm să respectăm cele mai bune practici, oferind cât mai mult posibil pe un CDN, evitând cât mai multe scripturi de la terțe părți și utilizând grafică SVG simplă în loc de PNG-uri bitmap. Nu a fost de ajuns.

Next.js ne permite să ne construim paginile și componentele în React și TypeScript. Când este asociat cu VS Code, experiența de dezvoltare este uimitoare. Next.js funcționează în general prin transformarea componentelor React în HTML și CSS static. În acest fel, conținutul inițial poate fi servit de la un CDN, iar apoi Next poate „hidrata” pagina pentru a face elementele dinamice. Odată ce pagina este hidratată, site-ul nostru se transformă într-o aplicație cu o singură pagină în care oamenii pot căuta și genera nume de domenii. Nu ne bazăm pe Next.js pentru a face mult lucru pe partea de server, majoritatea conținutului nostru este exportat static ca HTML, CSS și JavaScript pentru a fi difuzat dintr-un CDN.

Când cineva începe să caute un nume de domeniu, înlocuim conținutul paginii cu rezultatele căutării. Pentru a face căutările cât mai rapide posibil, front-end-ul interogează direct backend-ul nostru Rust, care este puternic optimizat pentru căutări de domenii și sugestii. La multe interogări putem răspunde instantaneu, dar pentru unele TLD-uri trebuie să facem interogări DNS mai lente, care pot dura o secundă sau două pentru a se rezolva. Când unele dintre aceste interogări mai lente se rezolvă, vom actualiza interfața de utilizare cu orice informații noi intră. Paginile cu rezultate sunt diferite pentru fiecare și ne poate fi greu să prezicem exact modul în care fiecare persoană experimentează site-ul.

Chrome DevTools sunt excelente și un loc bun de început atunci când urmăriți probleme de performanță. Vizualizarea Performanță arată exact când sunt trimise solicitările HTTP, unde browserul petrece timp evaluând JavaScript și multe altele:

Există trei valori de bază Web Vitals pe care Google le va folosi pentru a ajuta la clasarea site-urilor în viitoarea lor actualizare a algoritmului de căutare. Google împarte experiențele în „Bine”, „Necesită îmbunătățire” și „Slab” pe baza scorurilor LCP, FID și CLS pe ​​care oamenii reali le au pe site:

• LCP , sau cea mai mare vopsea de conținut, definește timpul necesar pentru ca cel mai mare element de conținut să devină vizibil.
• FID , sau Întârziere pentru prima introducere, se referă la capacitatea de răspuns a site-ului la interacțiune - timpul dintre o atingere, un clic sau o apăsare de tastă în interfață și răspunsul din pagină.
• CLS sau Schimbarea aspectului cumulativ urmărește modul în care elementele se mișcă sau se deplasează pe pagină în absența unor acțiuni precum tastatura sau evenimentul de clic.

Chrome este configurat să urmărească aceste valori pentru toți utilizatorii Chrome conectați și trimite înapoi la Google statistici anonime care rezumă experiența unui client pe un site înapoi la Google pentru evaluare. Aceste scoruri sunt accesibile prin Raportul privind experiența utilizatorului Chrome și sunt afișate atunci când inspectați o adresă URL cu instrumentul PageSpeed ​​Insights. Scorurile reprezintă experiența percentilei 75 pentru persoanele care vizitează acea adresă URL în ultimele 28 de zile. Acesta este numărul pe care îl vor folosi pentru a ajuta la clasarea site-urilor în actualizare.

O valoare a percentilei 75 (p75) atinge un echilibru rezonabil pentru obiectivele de performanță. A lua o medie, de exemplu, ar ascunde o mulțime de experiențe proaste pe care le au oamenii. Mediana, sau a 50-a percentila (p50), ar însemna că jumătate dintre persoanele care folosesc produsul nostru au avut o experiență mai proastă. Pe de altă parte, percentila 95 (p95) este greu de construit, deoarece captează prea multe valori aberante pe dispozitivele vechi cu conexiuni neregulate. Considerăm că notarea bazată pe percentila 75 este un standard corect de îndeplinit.

Pentru a ne controla scorurile, am apelat mai întâi la Lighthouse pentru niște instrumente excelente încorporate în Chrome și găzduite la web.dev/measure/ și la PageSpeed ​​Insights. Aceste instrumente ne-au ajutat să găsim unele probleme tehnice generale cu site-ul nostru. Am văzut că modul în care Next.js a grupat CSS-ul nostru și a încetinit timpul inițial de randare, ceea ce ne-a afectat FID. Primul câștig ușor a venit dintr-o funcție experimentală Next.js, optimizeCss, care a ajutat la îmbunătățirea semnificativă a scorului nostru general de performanță.

Lighthouse a surprins, de asemenea, o configurație greșită a memoriei cache care a împiedicat unele dintre activele noastre statice să fie servite de la CDN-ul nostru. Suntem găzduiți pe Google Cloud Platform, iar Google Cloud CDN necesită ca antetul Cache-Control să conțină „public”. Next.js nu vă permite să configurați toate anteturile pe care le emite, așa că a trebuit să le înlocuim plasând serverul Next.js în spatele lui Caddy, un server proxy HTTP ușor implementat în Go. De asemenea, am profitat de ocazie pentru a ne asigura că oferim ceea ce am putut cu suportul relativ nou învechit în timp ce se revalidează în browserele moderne, care permite CDN-ului să preia conținut de la origine (serverul nostru Next.js) asincron în fundal.

Este ușor – poate prea ușor – să adăugați aproape orice aveți nevoie la produsul dvs. de la npm. Nu durează mult pentru ca dimensiunile pachetelor să crească. Pachetele mari durează mai mult să se descarce pe rețelele lente, iar telefonul mobil percentila 75 va petrece mult timp blocând firul principal de UI în timp ce încearcă să dea sens întregului cod pe care tocmai l-a descărcat. Ne-a plăcut BundlePhobia, care este un instrument gratuit care arată câte dependențe și octeți va adăuga un pachet npm la pachetul dvs. Acest lucru ne-a determinat să eliminăm sau să înlocuim o serie de animații cu arc de reacție cu tranziții CSS mai simple:

Prin utilizarea BundlePhobia și Lighthouse, am constatat că software-ul terț de înregistrare și analiză a erorilor au contribuit semnificativ la dimensiunea pachetului și timpul de încărcare. Am eliminat și înlocuit aceste instrumente cu propria noastră înregistrare pe partea clientului, care profită de API-urile moderne ale browserului, cum ar fi sendBeacon și ping. Trimitem înregistrări și analize către propria infrastructură Google BigQuery, unde putem răspunde la întrebările la care ne pasă mai detaliat decât ne-ar putea oferi oricare dintre instrumentele disponibile. Acest lucru elimină, de asemenea, o serie de cookie-uri terță parte și ne oferă mult mai mult control asupra modului și când trimitem date de înregistrare de la clienți.

Scorul nostru CLS a avut încă cel mai mult loc de îmbunătățire. Modul în care Google calculează CLS este complicat – vi se oferă o „fereastră de sesiune” maximă cu un interval de 1 secundă, limitată la 5 secunde de la încărcarea inițială a paginii, sau dintr-o interacțiune cu tastatură sau clic, pentru a termina de mutat lucrurile pe site. . Dacă sunteți interesat să citiți mai profund acest subiect, iată un ghid grozav pe acest subiect. Acest lucru penalizează multe tipuri de suprapuneri și ferestre pop-up care apar imediat după ce ați aterizat pe un site. De exemplu, anunțurile care modifică conținutul sau vânzările care ar putea apărea atunci când începeți să defilați în trecut pentru a ajunge la conținut. Acest articol oferă o explicație excelentă a modului în care este calculat scorul CLS și a raționamentului din spatele acestuia.

Ne opunem în mod fundamental acestui tip de dezordine digitală, așa că am fost surprinși să vedem cât de mult loc de îmbunătățire a insistat Google să facem. Chrome are încorporat o suprapunere Web Vitals pe care o puteți accesa utilizând meniul de comandă pentru „Afișați suprapunerea Core Web Vitals”. Pentru a vedea exact ce elemente ia în considerare Chrome în calculul său CLS, am găsit mai utilă opțiunea „Console Logging” a extensiei Chrome Web Vitals din setări. Odată activat, acest plugin vă arată scorurile LCP, FID și CLS pentru pagina curentă. Din consolă, puteți vedea exact ce elemente de pe pagină sunt conectate la aceste scoruri. Scorurile noastre CLS au avut cel mai mult loc de îmbunătățire.

Dintre cele trei valori, CLS este singura care se acumulează pe măsură ce interacționați cu o pagină. Extensia Web Vitals are o opțiune de înregistrare care va arăta exact ce elemente cauzează CLS în timp ce interacționați cu un produs. Urmărește cum se adaugă valorile CLS când derulăm pe pagina de pornire a revistei Smashing:

Google va continua să ajusteze modul în care calculează CLS în timp, așa că este important să rămâneți informat urmărind blogul de dezvoltare web al Google. Când utilizați instrumente precum extensia Chrome Web Vitals, este important să activați limitarea procesorului și a rețelei pentru a obține o experiență mai realistă. Puteți face asta cu instrumentele pentru dezvoltatori simulând un procesor mobil.

Cea mai bună modalitate de a urmări progresul de la o implementare la alta este să măsurați experiențele paginilor în același mod în care o face Google. Dacă ați configurat Google Analytics, o modalitate ușoară de a face acest lucru este să instalați modulul web-vitals al Google și să-l conectați la Google Analytics. Aceasta oferă o măsură aproximativă a progresului dvs. și îl face vizibil într-un tablou de bord Google Analytics.

Aici ne-am lovit de un zid. Am putut vedea scorul nostru CLS și, deși l-am îmbunătățit semnificativ, mai aveam de lucru. Scorul nostru CLS a fost de aproximativ 0,23 și trebuia să îl obținem sub 0,1 – și, de preferință, până la 0. În acest moment, totuși, nu am putut găsi ceva care să ne spună exact ce componente pe care pagini încă afectează scorul. Am putut vedea că Chrome a expus o mulțime de detalii în instrumentele lor Core Web Vitals, dar că agregatorii de jurnalizare au aruncat cea mai importantă parte: exact ce element de pagină a cauzat problema.

Pentru a capta toate detaliile de care avem nevoie, am creat o funcție fără server pentru a capta datele vitale web din browsere. Deoarece nu trebuie să rulăm interogări în timp real asupra datelor, le transmitem în flux în API-ul de streaming Google BigQuery pentru stocare. Această arhitectură înseamnă că putem captura fără costuri cât mai multe puncte de date putem genera.

După ce am învățat câteva lecții în timp ce lucram cu Web Vitals și BigQuery, am decis să grupăm această funcționalitate și să lansăm aceste instrumente ca sursă deschisă la vitals.dev.

Utilizarea Instant Vitals este o modalitate rapidă de a începe să vă urmăriți scorurile Web Vitals în BigQuery. Iată un exemplu de schemă de tabel BigQuery pe care o creăm:

Integrarea cu Instant Vitals este ușoară. Puteți începe prin integrarea cu biblioteca client pentru a trimite date către funcția dvs. de backend sau fără server:

 import { init } from "@instantdomain/vitals-client"; init({ endpoint: "/api/web-vitals" });

Apoi, pe serverul dvs., vă puteți integra cu biblioteca de server pentru a finaliza circuitul:

 import fs from "fs"; import { init, streamVitals } from "@instantdomain/vitals-server"; // Google libraries require service key as path to file const GOOGLE_SERVICE_KEY = process.env.GOOGLE_SERVICE_KEY; process.env.GOOGLE_APPLICATION_CREDENTIALS = "/tmp/goog_creds"; fs.writeFileSync( process.env.GOOGLE_APPLICATION_CREDENTIALS, GOOGLE_SERVICE_KEY ); const DATASET_; init({ datasetId: DATASET_ID }).then().catch(console.error); // Request handler export default async (req, res) => { const body = JSON.parse(req.body); await streamVitals(body, body.name); res.status(200).end(); };

Pur și simplu apelați streamVitals cu corpul solicitării și numele valorii pentru a trimite valoarea către BigQuery. Biblioteca se va ocupa de crearea setului de date și a tabelelor pentru dvs.

După ce am colectat date pentru o zi, am rulat această interogare ca aceasta:

 SELECT `<project_name>.web_vitals.CLS`.Value, Node FROM `<project_name>.web_vitals.CLS` JOIN UNNEST(Entries) AS Entry JOIN UNNEST(Entry.Sources) WHERE Node != "" ORDER BY value LIMIT 10

Această interogare produce rezultate ca acestea:

Aceasta ne arată ce elemente pe care pagini au cel mai mare impact asupra CLS. S-a creat o listă punch pe care echipa noastră să o investigheze și să o repare. Pe Instant Domain Search, se dovedește că conexiunile mobile lente sau proaste vor dura mai mult de 500 ms pentru a încărca unele dintre rezultatele căutării noastre. Unul dintre cei mai mari contribuitori la CLS pentru acești utilizatori a fost de fapt subsolul nostru.

Scorul de schimbare a aspectului este calculat în funcție de dimensiunea elementului care se mișcă și de cât de departe merge. În vizualizarea rezultatelor căutării, dacă un dispozitiv durează mai mult de o anumită perioadă de timp pentru a primi și a reda rezultatele căutării, vizualizarea rezultatelor se va prăbuși la o zero-height , aducând subsolul la vedere. Când apar rezultatele, ele împing subsolul înapoi în partea de jos a paginii. Un element DOM mare care sa mutat atât de departe a adăugat mult scorului nostru CLS. Pentru a rezolva acest lucru corect, trebuie să restructurăm modul în care rezultatele căutării sunt colectate și redate. Am decis să eliminăm subsolul din vizualizarea rezultatelor căutării, ca un hack rapid care l-ar împiedica să se întoarcă în conexiuni lente.

Acum revizuim acest raport în mod regulat pentru a urmări modul în care ne îmbunătățim – și îl folosim pentru a combate rezultatele în scădere pe măsură ce avansăm. Am asistat la valoarea atenției suplimentare aduse funcțiilor și produselor nou lansate pe site-ul nostru și am operaționalizat verificări consecvente pentru a ne asigura că elementele vitale de bază acționează în favoarea clasamentului nostru. Sperăm că, distribuind Instant Vitals, putem ajuta și alți dezvoltatori să-și abordeze scorurile Core Web Vitals.

Google oferă instrumente de performanță excelente încorporate în Chrome și le-am folosit pentru a găsi și remedia o serie de probleme de performanță. Am aflat că datele de teren furnizate de Google au oferit un rezumat bun al progresului nostru p75, dar nu au avut detalii care să poată fi acționate. Trebuia să aflăm exact care elemente DOM au cauzat schimbări de aspect și întârzieri de intrare. Odată ce am început să colectăm propriile noastre date de teren, cu interogări XPath, am putut identifica oportunități specifice pentru a îmbunătăți experiența tuturor pe site-ul nostru. Cu ceva efort, am redus scorurile din câmpul Core Web Vitals din lumea reală într-un interval acceptabil, în pregătirea pentru Actualizarea experienței paginii din iunie. Ne bucurăm să vedem că aceste numere scad în jos și în dreapta!