100 de puncte la PageSpeed: ce am schimbat pentru asta

Valoarea de pornire a fost 58 din 100 pe telefon. Nu este o valoare proastă pentru un site cu efect 3D în antet, dar este o valoare pe care Google o penalizează simțitor în căutarea mobilă. La final au ieșit 100 de puncte pe desktop și 98 pe telefon, cu 100 și la accesibilitate.

Ce urmează nu este o listă generală de verificare, ci parcursul real – inclusiv locurile în care ne-am înșelat.

Situația de pornire

Cele cinci intervenții care au contat cu adevărat

1. Înlocuirea bibliotecii, nu optimizarea ei

Antetul arată un nor de particule în 3D. Pentru asta rula o bibliotecă grafică cunoscută – 458 KB după micșorare. Măsurarea arăta că 51 KB din ea nu erau executați niciodată.

Privirea decisivă a fost întrebarea de cât avem nevoie în realitate. Erau unsprezece componente: renderer, scenă, cameră, geometrie, material și câteva clase ajutătoare. Toate se pot programa direct pe interfața grafică a browserului.

Rezultat: 458 KB au devenit 6 KB. Reprezentarea este identică – am preluat aceleași shadere.

2. Compresia era pornită doar pe jumătate

În configurația serverului, compresia era pe «pornit» – dar linia care spune ce tipuri de fișiere să fie comprimate era comentată. Aceasta este setarea implicită a multor distribuții. Rezultat: se comprima exclusiv HTML.

Biblioteca grafică trecea deci necomprimată prin cablu. După activare: 1243 KB au devenit 251 KB. În plus, punem acum variantele comprimate precalculate alături, ca serverul să nu recalculeze la fiecare accesare.

Efort: două linii de configurare. Efect: aproape un megaoctet la fiecare primă accesare.

3. Eliminarea completă a bibliotecii de animație

Pentru aparițiile la derulare rula încă o bibliotecă, 114 KB. Măsurarea o indica în plus drept cauză a recalculărilor forțate de aspect – interoga geometria în timpul derulării și obliga browserul să recalculeze aspectul în mijlocul mișcării.

Înlocuită cu un IntersectionObserver care doar setează o clasă. Mișcarea propriu-zisă o face CSS. 114 KB mai puțin, fără recalculări, aproximativ 40 de linii de cod propriu.

4. Favicon-ul avea 205 KB

Un fleac cu efect surprinzător, pentru că se încarcă foarte devreme. Înlocuit cu un fișier SVG de 6 KB, generat din logoul existent.

5. Interogarea geometriei în cadrul de animație

Un script citea la fiecare eveniment de derulare înălțimea totală a documentului. Această proprietate nu poate fi dată de browser din memorie – pentru ea trebuie să recalculeze aspectul întregii pagini, în mijlocul derulării.

Regula care rezultă de aici și care este valabilă peste tot: citește în eveniment, scrie în cadrul următor. Niciodată invers. De atunci înălțimea paginii este măsurată o dată și reținută, în loc să fie cerută din nou de șaizeci de ori pe secundă.

Greșeala care a costat 24 de puncte

Ce a adus puțin

De dragul completitudinii, măsurile care apar în orice ghid și care la noi au fost abia măsurabile:

Formatele de imagine. Pagina noastră de start are foarte puține imagini – logoul este un fișier SVG. Acolo unde apar imagini, conversia merită bineînțeles; ca pârghie principală este bună doar pentru paginile încărcate cu imagini.

Micșorarea suplimentară a fonturilor. Găzduim două familii de fonturi la noi și le preîncărcăm pe cele necesare în zona vizibilă. O optimizare suplimentară ar fi posibilă, dar nu mișcă valoarea.

Locația serverului. Recomandată frecvent, în cazul nostru irelevantă: timpul până la primul octet era deja de 20 de milisecunde. Cine stă deja bine acolo nu câștigă nimic dintr-o rețea de distribuție.

Procedeul de urmat întocmai

1. Măsurați înainte să schimbați ceva. Mobil și desktop separat, notați valorile.
2. Căutați cel mai mare fișier transferat. Aproape întotdeauna este JavaScript. Întrebarea nu este cum îl micșorezi, ci dacă ai nevoie de el.
3. Verificați compresia. Nu dacă este pornită, ci pentru ce tipuri de fișiere.
4. Numărați cererile blocante. Fiecare fișier de stil din antet reține prima afișare.
5. Verificați salturile de aspect fără frână. Testul care ne-a lipsit nouă.
6. Măsurați din nou după fiecare modificare. Altfel nu se știe la final ce a avut efect.

Ajută-mă să traduc raportul PageSpeed al paginii mele într-o
ordine de priorități. Fii sever; nu lăuda nimic.

Valorile mele măsurate:
- Mobil: [punctaj], Desktop: [punctaj]
- LCP, TBT, CLS pe fiecare dispozitiv: [valori]
- Cele mai mari fișiere transferate, cu dimensiune: [listă]
- Cereri care blochează afișarea: [listă]
- Mesajele din raport: [inserează textul]

Despre pagină:
- Cum este construită: [CMS / static / constructor]
- Este JavaScript necesar pentru conținutul vizibil? [da/nu]
- Cum este livrat CSS-ul? [extern / în avans / parțial în avans]

Sarcini:
1. Atribuie fiecărui mesaj o cauză și spune ce indicator
   influențează – LCP, TBT sau CLS.
2. Sortează măsurile după efect raportat la efort. Spune la
   fiecare câte puncte mișcă realist și de ce.
3. Numește măsurile din raport care la modul meu de construcție
   nu aduc practic nimic – și motivează, în loc să le lași
   pur și simplu deoparte.
4. La fiecare fișier JavaScript mare întreabă întâi dacă este
   necesar, înainte să propui micșorarea.
5. Atrage atenția dacă CSS-ul este livrat doar parțial în avans
   și explică de ce asta poate fi mai rău pentru CLS
   decât deloc.
6. Spune ce ar trebui să măsor din nou după fiecare modificare.

Nu inventa valori măsurate.

Concluzie

Punctajul în sine nu este scopul – este o valoare măsurată, nu un rezultat de afaceri. Ce contează este experiența din spate: o pagină care se poate citi după 1,4 secunde este citită de mai mulți oameni decât una care are nevoie de șase secunde. La vizitatorii mobili pe rețea celulară, diferența este mai mare decât orice optimizare de text.

Drumul într-acolo a trecut în cazul nostru printr-o singură întrebare recurentă: avem nevoie de asta? Cinci din șase intervenții au constat în a elimina ceva, nu în a adăuga ceva.

Întrebări frecvente