Un scor perfect de performanță și un site care pare lent sunt perfect compatibile. Iată distanța dintre ele.

Scorurile de performanță măsoară o încărcare sintetică pe un dispozitiv simulat. Clientul măsoară așteptarea dintre momentul în care a decis să citească ceva și momentul în care chiar poate.

Cifra care contează

Timpul până la conținut citibil, pe dispozitivul median pe care îl raportează analytics-ul tău — nu pe telefonul de top din camera în care se ia decizia. Un site testat pe telefonul de ultimă generație al unui dezvoltator, pe wifi de birou, poate avea un scor bun și tot să fie genuin lent pentru clientul de pe un telefon de trei ani, pe date mobile instabile — iar acel client nu este un caz marginal ipotetic; pentru multe firme, este vizitatorul median, nu excepția.

De ce diverg scorurile și experiența reală

Un instrument de testare a performanței rulează un script fix, în condiții fixe, și produce o cifră genuin utilă ca să prinzi regresii — un scor care scade zece puncte după un deploy îți spune că s-a schimbat cu adevărat ceva. Ce nu îți spune este cum se simte pagina pentru un vizitator anume, pe o rețea anume, pentru că vizitatorii reali nu experimentează o medie a tuturor condițiilor testate de instrument. Ei experimentează o singură încărcare specifică, pe un dispozitiv specific, o singură dată — iar un site ajustat să arate bine în rezumatul instrumentului, fără să fie testat în condiții realiste de dispozitiv și rețea, poate mulțumi cu ușurință metrica în timp ce eșuează exact vizitatorul pentru care pretindea că a fost optimizat.

Unde se duce de obicei timpul

• Fonturi care blochează textul sute de milisecunde — un vizitator care se uită la un ecran gol în timp ce se descarcă un fișier de font, când browserul avea la dispoziție tot timpul ăsta un font de sistem perfect lizibil.
• Imagini de hero dimensionate pentru un ecran retina de desktop, servite unui telefon, la de patru sau cinci ori rezoluția pe care o poate afișa măcar ecranul unui telefon.
• Taguri de la terți, încărcate sincron, pe care nu își amintește nimeni că le-a adăugat — un snippet de analytics aici, un widget de chat dincolo, fiecare contribuind cu o cerere blocantă care izolat pare neglijabilă și împreună se adună la o întârziere semnificativă înainte ca pagina să devină utilizabilă.
• Randare în browser a unui conținut care nu se schimbă niciodată, ceea ce înseamnă că un vizitator descarcă o pagină goală, apoi descarcă codul care construiește pagina, apoi așteaptă ca acel cod să ruleze, pentru un conținut care ar fi putut fi trimis ca HTML gata făcut încă din primul răspuns.

Distanța dintre „încărcat” și „utilizabil”

O pagină se poate termina de încărcat, în sensul pe care îl măsoară un instrument de performanță, și tot să nu fie utilizabilă — butoane prezente, dar încă nefuncționale pentru că JavaScript-ul care le conectează nu a terminat de rulat, un layout care se așază vizual la locul lui la o secundă întreagă după ce a apărut textul și a mutat exact ce era pe cale să atingă vizitatorul. Aceste momente nu apar mereu clar într-un singur scor rezumat, pentru că scorul măsoară o definiție specifică a lui „gata” care nu se potrivește mereu cu simțul propriu al unui vizitator despre momentul în care o pagină a devenit utilizabilă. Citirea raportului complet, nu doar cifra principală, este unde apar de fapt aceste goluri.

Ce facem în privința asta

Randăm pe server tot ce este static, livrăm cel mai mic subset de font care acoperă textul și punem un buget pentru scripturile de la terți, pe care cineva trebuie să argumenteze ca să îl depășească. Fiecare script nou este cântărit în funcție de ce costă în timp de încărcare, nu aprobat implicit pentru că cererea a venit de la o echipă rezonabilă cu un motiv rezonabil — cererile rezonabile sunt exact felul în care un site rapid se acumulează, adăugire cu adăugire, spre unul lent.

Testarea față de realitate, nu față de confort

Testăm fluxurile principale pe o conexiune limitată artificial și pe un profil de dispozitiv de gamă medie, nu pentru că e plăcut de lucrat așa, ci pentru că e mai aproape de ce experimentează efectiv o parte semnificativă din vizitatorii reali. O pagină care se simte instantanee pe o conexiune rapidă și durează câteva secunde să devină utilizabilă pe una limitată este o pagină testată doar în condiția care o flatează. Testul incomod este cel util, iar săritul peste el este felul în care un site ajunge rapid pentru cei care îl construiesc și lent pentru cei pentru care a fost construit.

Viteza este o cifră de business înainte să fie una tehnică

O pagină mai lentă nu este doar o experiență mai proastă în abstract — este, măsurabil, mai puțini oameni care rămân destul cât să fie convinși. Relația dintre timpul de încărcare și abandon nu este liniară și nu este subtilă: peste un prag relativ scurt, fiecare secundă în plus de așteptare costă o proporție reală, vizibilă, de vizitatori care pur și simplu pleacă înainte să apară conținutul pentru care au venit. De aceea merită tratată munca de performanță ca prioritate comercială, nu ca un moft tehnic discutat doar când se strică ceva — un site care durează cu două secunde în plus să devină utilizabil taxează discret fiecare leu cheltuit pe marketing care trimite trafic către el, indiferent dacă urmărește cineva taxa aia sau nu.

Ce e ușor de reparat, și ce nu

Fonturile și imaginile sunt de obicei câștigurile cele mai rapide, pentru că țin complet de tine și rareori cer restructurare — subsetarea unui font, comprimarea și dimensionarea corectă a imaginilor și servirea formatelor moderne pot îmbunătăți semnificativ timpul de încărcare într-o după-amiază. Scripturile de la terți sunt mai grele, pentru că eliminarea unuia înseamnă de obicei o discuție cu echipa care l-a cerut, iar randarea în browser a conținutului esențial este și mai grea, pentru că poate însemna restructurarea felului în care e construită pagina, nu doar ajustarea unui asset. Să știi din ce categorie face parte o reparație ajută la prioritizare realistă — începe cu reparațiile de-o după-amiază și programează-le deliberat pe cele structurale, în loc să tratezi un audit de performanță ca pe o listă nediferențiată.

Pe scurt

Un scor de performanță este un proxy, nu scopul. Scopul este așteptarea pe care un vizitator real, pe un dispozitiv real, pe o conexiune reală, o experimentează între a-și dori ceva și a-l obține — măsoar-o direct, în condițiile pe care le raportează traficul tău real, și tratează scorul sintetic ca pe o alarmă de regresie, nu ca pe linia de sosire.