Keskiviikkona, 9.12.2020

Verkkosivujen latausnopeus РOnko Google PageSpeed Insights hyvä mittari vai sulaa hulluutta?

Sivuston latausnopeuteen vaikuttaa monta eri tekijää. Googlen silmissä sivusto on hyvä muunmuassa silloin kun koodia on oikein hyödynnetty. Mutta mikä oikeastaan on "oikein". Kannattaako Googlea miellyttää? Se selviää pian.

Tämä kirjoitus saattaa sisältää vanhentunutta tietoa, sillä se on julkaistu yli 2 vuotta sitten.

Google on vakiinnuttanut jalansijan palveluntarjoana, johon monet luottavat. Google PageSpeed Insights on omien sanojensa mukaan palvelu, joka analysoi verkkosivun sis√§ll√∂n ja ehdottaa sitten keinoja, joilla sivusta voi tehd√§ nopeamman. Lis√§tietoja ja laskentakriteerej√§ l√∂ytyy kattavasti. Mutta onko pisteisiin luottaminen ja onko 100/100 realistista tai edes tarpeellista saavuttaa? T√§m√§ on jatkokirjoitus vuoden 2017 edelleen relevantille, hieman provosoivalle kirjoituksellemme ”Google PageSpeed nopeustestin tuloksilla ei ole mit√§√§n merkityst√§”.

Täyttä 100/100 tulosta on nykyään lähes mahdoton saavuttaa

Google PageSpeed -työkalu on muuttunut netin kehityksen mukaan. Se ei ole enää saman näköinen, eikä toimi samalla tavalla kuin vuosia sitten. Moottorina toimii Lighthouse, joka on Googlen erikseen optimointiin kehittämä työkalu. Nykyään on nopeammat nettiyhteydet, mutta myös nettisivujen vaatimukset ovat kasvaneet. Enää ei jurnuteta modeemiajalla, eikä mikään ole rasittavampaa kuin hitaasti latautuvat sivut. Nykyaikana hitaana koetaankin pidempään kuin sekuntin latautuvat nettisivut kun taas ennen sekunti oli lyhyt aika.

Aiemmin Google PageSpeed tarkkaili enemmänkin miten resurssit on pakattu, miten käytettävä sivusto on mobiilissa ja millaisia palvelinkomponentteja on käytössä. Nykyään Google keskittyy vielä tarkemmin siihen miten tiedostoja käytetään ja onko esimerkiksi Googlen avoimen standardin komponentteja (ngx-pagespeed, AMP, jne.) käytössä.

Google PageSpeed ei näytä enää tältä. Moottori on uudistunut moneen kertaan.

Mobiilissa 100/100 tulos on siis k√§yt√§nn√∂ss√§ nyky√§√§n mahdotonta saavuttaa. Mobiilitesti emuloi hidasta 2G-yhteytt√§ ja vanhaa puhelinta, jotta saataisiin ”worst case scenario” -tilanne aikaan. First Meaningful Paintit ja muut ty√∂p√∂yt√§koneella vihre√§ll√§ olevat mittarit ovat herk√§sti mobiilissa punaisella. Google rokottaa mobiilissa monista asioista, joista ei viel√§ pari vuotta sitten tarvinnut kiinnostua.

Huomionarvoista on, että edes Googlen omat sivut eivät saa täysiä pisteitä.

Mobiilissa monen modernin sivuston on siis vaikeaa saada edes yli 50 pistettä. Yleensä hyvän pistemäärän voi saavuttaa kunhan:

  • Ei k√§yt√§ analytiikkascriptej√§ (esim. Google Analytics, Snoobi, Hotjar)
  • Ei k√§yt√§ pikseleit√§ ja muita tageja (Google Tag Manager, Facebook Pixel)
  • Unohtaa somesein√§t (Juicer)
  • Chatti, Crisp tai Intercom pois vaan
  • Ei ker√§t√§ liidej√§ Leadfeeder, Albacross, ym. turha toivo
  • Poistoon HubSpot, CRM-integraatiot
  • V√§hemm√§n tai ei ollenkaan isoja kuvia tai hoitaa niiden pakkaamisen kunnolla
  • Oma br√§ndifontti ja siit√§ useampi leikkaus sivuilla? Mieluusti pois tai r√§ps√§ht√§v√§ render√∂inti tilalle
  • Videot tai upotukset: Huspois
  • Ei puhettakaan vaativammista k√§ytt√∂liittym√§elementeist√§ kuten monimutkaisista lomakkeista tai hauista

Muistathan myös:

  • Varmistaa ett√§ sivusi on hyvin koodattu moderneja tekniikoita (mieluusti Googlen palikoita) hy√∂dynt√§en
  • K√§ytt√§√§ palvelimen ja sivuston v√§limuistitustekniikoista ngx-pagespeed -moduulia, Redis/Varnish-v√§limuistia, transientteja/object cachea, browser/static cachea jne.
  • Kompressoida ja minifoida kaikki resurssit tuotannossa, my√∂s kuvat ja SVGt. WordPressin puolella kuvan resoluution pienent√§misen hoitaa k√§tev√§sti Imagify tai Kraken suoraan sivuja p√§ivitt√§ess√§ WP-adminin kautta. My√∂s WordPress rajaa turhan isot kuvat max 2048px kokoon 5.3 versioista l√§htien.
  • Paljon muuta, kymmenitt√§in pieni√§ toimenpiteit√§, joita en t√§ss√§ erikseen listaa

Googlen näkemyseroja ei tarvitse miellyttää

Ehk√§ suurin ero (ja √§rsytt√§vyys) Googlen kriteereiss√§ on nyky√§√§n se, ett√§ ns. ”hukkakoodia” ei saisi olla yht√§√§n. T√§m√§ tarkoittaa sit√§ ett√§ kun Google aiemmin arvosti sit√§ ett√§ esimerkiksi sivuston visuaaliset tyylit on pakattu kaikki samaan tiedostoon k√§tev√§sti, nyky√§√§n Google rankaisee siit√§, ett√§ alasivun tyylej√§ ladataan jo etusivulla. T√§m√§ on t√§ysin n√§kemysasia, eik√§ usein edes vaikuta merkitt√§v√§sti nopeuteen.

Kuvitellaan kaksi erillist√§ sivustoa, joissa molemmissa on saman kokoinen, pieni CSS-tiedosto, esimerkiksi 100 kB. Sivusto 1: etusivulla on k√§yt√∂ss√§ v√§h√§n tyylej√§ ja loput tyylitiedostosta hy√∂dynnet√§√§n vasta alasivuja selatessa, jolloin etusivun k√§ytt√∂aste tiedostosta on esimerkiksi 30 prosenttia. Sivusto 2: Otetaan vaikkapa ”onepager”-tyyppinen yhden sivun sivusto, jossa kaikki tyylit ovat samalla sivulla ja k√§ytt√∂aste on t√§ll√∂in luonnollisesti 100%, koska alasivuja ei ole ja kaikki tarvittavat tyylit ladataan samalla sivulla, jota selataan. Google rankaisee ensin mainitun sivun pisteit√§, koska tiedostossa on sen mielest√§ ”turhaa koodia”.

T√§llainen ”turhan koodin v√§ltt√§minen” tarkoittaisi sit√§, ett√§ oikeat sivustot pit√§isi rakentaa niin, ett√§ joka sivulla ladataan aina uusi tiedosto. Sivusto sis√§lt√§isi sivum√§√§r√§n mukaisen m√§√§r√§n tiedostoja jokaiselle sivulle erikseen. T√§m√§ on √§√§rimm√§isen ty√∂l√§s ja tarpeeton tapa kehitt√§√§ verkkosivuja. Tai sitten alettaisiin noudattaa nykytrendi√§ CSS-in-JS, jossa nettisivu koodataan appimaiseen muotoon ja kaikki tyylit sis√§llytett√§isiin toiminnallisen JavaScript-koodin sekaan. Molemmissa tavoissa on omat ep√§k√§yt√§nn√∂llisyytens√§.

WordPress-maailmassa ei ole mitään järkevää tapaa ladata tiedostoja sivukohtaisesti, eikä se ole ajankäytöllisesti edes kannattavaa. Jos siinä jonkun millisekunnin säästää latausnopeudessa, se ei ole sen arvoista kun ladattavaa tulee tiedostotolkulla enemmän alasivuilla. Google ei tässä kohtaa usko, että keskivertokävijä selaisi sivuja paria pääsivua syvemmälle, mutta me uskomme että hyvällä sivustolla niin tapahtuu.

On paljon järkevämpää, että kävijä saa koko sivuston koodin ensimmäisellä latauksella mukaansa, jotta alasivut latautuvat nopeammin kun kaikki on jo kerralla ladattu käyttäjän selaimen välimuistiin. Oletusarvoista on, että koko sivun koodi mahtuu pieneen tilaan (mieluusti max 300-500 kB) ja siihen pyrimme toteuttajana. Omassa työssä on mielenkiintoista elää kuin 80-luvun videopelimaailmassa, jossa jokaisella bitillä on merkitys. Joissakin tilanteissa on tietenkin mahdotonta vaikuttaa koodin kokoon, esimerkiksi silloin kun osa koodista tulee ulkopuolelta.

Tylsät ja nopeat sivut vai kivat JA nopeat sivut?

Helposti alkaa tuntumaan siltä, että sivustolla ei saisi olla mitään kivaa, jos mentäisiin nopeuden ehdoilla. On totta, että kuvattomat, kilkkeettömät tekstipainotteiset sivut latautuvat kaikista nopeiten. Mutta nopeaa saa aikaan myös visuaalisella tyylikkyydellä, kunhan asiat tehdään oikein.

Tässä kohtaa on helppo puhua omista sivuista. Dude.fi vuosimallia 2020 ei ole kaikista kevyin esimerkiksi tyylitiedoston kooltaan (pakkaamaton tiedosto 584 kilotavua, eli noin puoli megaa). Silti rankalla optimoinnilla tyylitkin saa supistettua pariin sataan kilotavuun ja kaiken muun optimoinnin myötä Google PageSpeed / Web Vitals / Google Lighthouse antaa tietokoneen tulokseksi 94/100 pistettä, mobiili vaihtelee 30-90 välillä riippuen siitä mitä milloinkin etusivulla näytetään ja millaisella yhteydellä. Tässäkin huomataan, että kontrasti tulosten välillä on toisinaan erittäin suuri.

Dude.fi pärjää hyvin Googlen silmissä työpöytäkoneella. Mobiilissa tilanne on toinen (33-40/100).

Duden sivuilla eniten pisteit√§ rokottaa JavaScript ja nimenomaan yll√§ kuvattu ”k√§ytt√§m√§t√∂n” koodi, eli javascript, jota ladataan samasta tiedostosta koko sivustolle. JavaScript-koodissa on el√§m√§√§ ”helpottavia” kirjastoja kuten WordPressin tarjoama oletus-jQuery ja joitakin SVG-kirjastoja k√§ytt√§millemme glitch-napin hover efekteille.

Lis√§ksi k√§yt√§mme ”appimaisuutta” luovaa frameworkia, jolla koko sivusto saadaan kerralla ladattua siten, ettei edes sivun vaihtamisia tarvitse ladata uudestaan. Kyll√§, t√§llainen saadaan aikaan my√∂s WordPressill√§. Huomaat kun vaihdat sivua esimerkiksi valikkoa klikkamalla, sivu ei erikseen p√§ivity vaan feidautuu pehme√§sti paikalleen. T√§m√§ on niin mukava ja v√§h√§n k√§ytetty tekniikka, ett√§ sen haluaisi mielell√§√§n s√§ilytt√§√§ omilla sivuillaan.

Seurantakoodeista ja muista kaupantekoa ja liiketoiminnallista elämää helpottavista työkaluista sivustolla on käytössä ainakin Google Analytics, Hotjar, Crisp, Twitter-upotukset, Instagram-upotukset ja Leadfeeder.

Näiden kanssa latausnopeudet hyvillä välimuistitustekniikoilla ovat 150 millisekunnin tuntumissa. Ilman näitä kaikkia latausnopeudet hyvillä yhteyksillä liikkuisivat 50-100 millisekunnin paikkeilla. Mitäpä luulet, haluammeko tylsemmät sivut sillä verukkeella, että mikään ei näytä yhtä kivalta, mutta paperilla näyttää hyvältä? Kukaan tuskin tällaista eroa huomaa selaamisessaan millään tavalla.

Miten oikeasti kannattaa mitata sivuston latausnopeutta?

Palvelintyökaluista stressitestiä voi ajaa Kali Linuxin stressitestaustyökaluilla tai esimerkiksi httpd-tools -pakettiin kuuluvalla Apache ab:lla. Stressitestejä tärkeämpää mielestäni on kuitenkin katsoa ensin sivuston ja palvelimen asiat kuntoon ja mitata ulkoista latausnopeutta jollain työkalulla pidemmällä aikajänteellä. Jos oletetaan, että sivusto on koodattu hyvin, käytössä on selainpään välimuistitukset, WordPress transientit, object cache, WP Cloudflare Super Page Cache, Autoptimize ja Cache Enabler ja palvelimella käytössä on Redis, staattinen cache ja ngx-pagespeed, voidaan nopeutta lähteä mittaamaan helposti.

Vuosina 2006-2019 kehittämämme AdminLabs on erityisen hyvä monitorointiin ja sivuston downtimen ilmoituksiin, mutta sillä voi se