100 pistettä PageSpeedissä: mitä muutimme sen eteen

Lähtöarvo oli 58 sadasta puhelimella. Se ei ole huono arvo verkkosivustolle, jonka yläosassa on 3D-tehoste, mutta se on arvo, jota Google rankaisee mobiilihaussa tuntuvasti. Lopussa oli 100 pistettä tietokoneella ja 98 puhelimella, samoin 100 saavutettavuudesta.

Seuraava ei ole yleinen tarkistuslista vaan todellinen kulku – mukaan lukien kohdat, joissa erehdyimme.

Lähtötilanne

Viisi toimenpidettä, joilla todella oli merkitystä

1. Korvaa kirjasto, älä optimoi sitä

Yläosassa näkyy hiukkaspilvi 3D:nä. Sitä varten pyöri tunnettu grafiikkakirjasto – 458 kilotavua pienentämisen jälkeen. Mittaus osoitti, ettei 51 kilotavua siitä suoritettu koskaan.

Ratkaiseva näkökulma oli kysymys siitä, kuinka paljon oikeasti tarvitsemme. Osia oli yksitoista: renderoija, näkymä, kamera, geometria, materiaali ja muutama apuluokka. Kaikki nämä voi ohjelmoida suoraan selaimen grafiikkarajapintaa vasten.

Tulos: 458 kilotavusta tuli 6 kilotavua. Ulkoasu on identtinen – otimme käyttöön samat varjostimet.

2. Pakkaus oli vain puoliksi päällä

Palvelinasetuksissa pakkaus oli «päällä» – mutta rivi, joka määrää pakattavat tiedostotyypit, oli kommentoitu pois. Se on monen jakelun oletus. Tulos: pakattiin yksinomaan HTML.

Grafiikkakirjasto siis kulki linjaa pitkin pakkaamattomana. Kytkemisen jälkeen: 1243 kilotavusta tuli 251 kilotavua. Lisäksi pidämme pakatut versiot nyt valmiiksi laskettuina vieressä, jottei palvelimen tarvitse laskea uudelleen joka noudolla.

Vaiva: kaksi riviä asetuksia. Vaikutus: vajaa megatavu ensimmäistä avausta kohden.

3. Poista animaatiokirjasto kokonaan

Vierityksen aikaisiin sisääntuloihin pyöri toinen kirjasto, 114 kilotavua. Mittaus osoitti sen lisäksi aiheuttavan pakotettuja taiton uudelleenlaskentoja – se kysyi vierityksen aikana geometriaa ja pakotti selaimen laskemaan taiton uudelleen keskellä liikettä.

Korvattu IntersectionObserver-tarkkailijalla, joka vain asettaa luokan. Varsinaisen liikkeen tekee CSS. 114 kilotavua vähemmän, ei enää uudelleenlaskentoja, noin 40 riviä omaa koodia.

4. Favicon oli 205 kilotavun kokoinen

Pikkuseikka hämmästyttävällä vaikutuksella, koska se ladataan hyvin varhain. Korvattu 6 kilotavun SVG-tiedostolla, joka luotiin olemassa olevasta logosta.

5. Kysy geometriaa animaatiokehyksessä

Eräs skripti luki jokaisen vieritystapahtuman yhteydessä dokumentin kokonaiskorkeuden. Tätä ominaisuutta selain ei voi vastata muistista – sen on laskettava koko sivun taitto uudelleen, keskellä vieritystä.

Siitä seuraava sääntö, joka pätee kaikkialla: lue tapahtumassa, kirjoita seuraavassa kuvassa. Ei koskaan toisin päin. Siitä lähtien sivun korkeus mitataan kerran ja muistetaan sen sijaan että sitä kysyttäisiin uudelleen kuusikymmentä kertaa sekunnissa.

Virhe, joka maksoi 24 pistettä

Mikä toi vähän

Täydellisyyden vuoksi ne toimenpiteet, jotka ovat jokaisessa ohjeessa ja jotka meillä olivat tuskin mitattavissa:

Kuvaformaatit. Etusivullamme on tuskin lainkaan kuvia – logo on SVG-tiedosto. Siellä missä kuvia on, muunnos tietysti kannattaa; päävipuvarreksi siitä on vain kuvapainotteisilla sivuilla.

Kirjasinten pienentäminen edelleen. Isännöimme kahta kirjasinperhettä itse ja lataamme näkyvällä alueella tarvittavat ennakkoon. Lisäoptimointi olisi mahdollista mutta ei liikuta arvoa.

Palvelimen sijainti. Usein suositeltu, meidän tapauksessamme merkityksetön: aika ensimmäiseen tavuun oli jo 20 millisekuntia. Se, joka on siinä jo hyvässä asemassa, ei voita jakeluverkolla mitään.

Menettely perässä tehtäväksi

1. Mittaa ennen kuin mitään muutetaan. Mobiili ja työpöytä erikseen, arvot muistiin.
2. Etsi suurin siirretty tiedosto. Lähes aina se on JavaScriptiä. Kysymys ei ole siitä, miten se pienennetään, vaan siitä, tarvitaanko sitä.
3. Tarkista pakkaus. Ei sitä, onko se päällä, vaan sitä, mille tiedostotyypeille.
4. Laske estävät pyynnöt. Jokainen tyylitiedosto yläosassa viivyttää ensimmäistä piirtoa.
5. Tarkista taittohypyt ilman jarrua. Se yksi testi, joka meiltä puuttui.
6. Mittaa uudelleen jokaisen muutoksen jälkeen. Muuten ei lopussa tiedä, mikä vaikutti.

Auta minua kääntämään sivuni PageSpeed-raportti järjestykseksi.
Ole ankara; älä kehu mitään.

Mittausarvoni:
- Mobiili: [pistemäärä], työpöytä: [pistemäärä]
- LCP, TBT, CLS laitteittain: [arvot]
- Suurimmat siirretyt tiedostot kokoineen: [lista]
- Renderöintiä estävät pyynnöt: [lista]
- Raportin ilmoitukset: [liitä teksti]

Sivusta:
- Miten se on rakennettu: [CMS / staattinen / sivunrakennin]
- Tarvitaanko JavaScriptiä näkyvään sisältöön? [kyllä/ei]
- Miten CSS toimitetaan? [ulkoisena / ennakkoon / osittain ennakkoon]

Tehtävät:
1. Liitä jokainen ilmoitus syyhyn ja kerro, mihin tunnuslukuun
   se vaikuttaa – LCP, TBT vai CLS.
2. Järjestä toimenpiteet vaikutuksen ja vaivan suhteen mukaan.
   Kerro kustakin, montako pistettä se realistisesti liikuttaa ja miksi.
3. Nimeä raportin toimenpiteet, joista minun rakennustavallani
   ei ole käytännössä hyötyä – ja perustele sen sijaan että
   jättäisit ne pois.
4. Kysy jokaisesta suuresta JavaScript-tiedostosta ensin, tarvitaanko
   sitä, ennen kuin ehdotat pienentämistä.
5. Huomauta, jos CSS toimitetaan vain osittain ennakkoon, ja selitä,
   miksi se voi olla CLS:n kannalta huonompi kuin ei lainkaan.
6. Kerro, mitä minun pitäisi mitata uudelleen jokaisen muutoksen jälkeen.

Älä keksi mittausarvoja.

Johtopäätös

Pistemäärä itsessään ei ole tavoite – se on mittausarvo, ei liiketoiminnan tulos. Merkitystä on sen takana olevalla kokemuksella: sivun, joka on luettavissa 1,4 sekunnin jälkeen, lukee useampi ihminen kuin sellaisen, joka tarvitsee kuusi sekuntia. Mobiiliverkon kautta tulevien kävijöiden kohdalla ero on suurempi kuin mikään tekstin optimointi.

Tie sinne kulki meidän tapauksessamme yhden toistuvan kysymyksen kautta: tarvitsemmeko tätä? Viisi kuudesta toimenpiteestä oli jonkin poistamista, ei lisäämistä.

Usein kysytyt kysymykset