Laaja opas WordPress optimointiin – Tee verkkosivustosi nopeus edellä 2021

Avoimeen lähdekoodiin perustuva blogialusta WordPress on heittämällä yksi suosituimmista sivustojen rakentamiseen käytetyistä työkaluista. Muokattavuuden ansiosta alusta kykenee moneen oli käyttötarkoitus sitten yrityksen sivu, verkkokauppa tai blogi. Lisäosien ja lukuisien sivustoeditori -vaihtoehtojen ansiosta sivuston tekeminen onnistuu myös miltein ilman minkäänlaista teknistä osaamista. Kuulostaa hyvältä eikö? Se olisi sitä ellei todellisuus toisi mukanaan myös varjopuolia. Jos rakennat sivustoja miettimättä ollenkaan teknistä toteutusta tai sitä mitä sinun valikoimat lisäosat todella tekevät, on hyvin helppo rakentaa sivusto joka

1. Toimii hitaasti
2. Rikkoutuu päivitysten yhteydessä
3. Monimutkainen ylläpitää tai muutosten tekeminen on raskasta

Tilanteen korjaamiseksi ei ole muita keinoja kuin todella opiskella verkossa käytettäviä kieliä kuten HTML, CSS, Javascript ja PHP. Näistä neljästä yleensä koostuu WordPress kehittäjän työkalupakki, jolla sivujen tekeminen hoituu monipuolisesti. Olisi myös hyvä olla tietoinen siitä, että jos joudut asentamaan sivustolle lisäosan, niin mitä tämä todella tekee ja pystyisikö toiminnallisuuden toteuttamaan paremmin ilman lisäosia.

Kannattaa muistaa se, että vaikka kuinka tekisit optimoivia toimenpiteitä sivuille, joka on huonosti ja raskaasti rakennettu, tätä on hyvin vaikea saada toimimaan kunnolla. Tästä syystä sivuston nopeus lähtee aina ensisijaisesti siitä miten se on rakennettu ja tämän jälkeen varsinaista nopeusoptimointia harvemmin edes tarvitaan.

Koska puhumme hyvin laajoista kokonaisuuksista, joista voisi helposti kirjoittaa kokonaisen kirjan, on tämä artikkeli vain pintaraapaisu ja yleiskatsaus millä tempuilla teet suorituskykyisiä verkkosivustoja. Toivon kovasti, että viihdyt tämän artikkelin parissa ja saat siitä jonkinasteisen kuvan miten optimoit sivustosi huippukuntoon. Jos huomaat jossain tarkennusta vaativaa tietoa, älä pelkää ilmoittamasta siitä meille! Tekniikat elävät ja päivittyvä, kuten tämä artikkelikin.

Tehokkaan jäsentelyn vuoksi keräsin alle oleellisimmat termit, joita tässä artikkelissa tai sivustoa rakentaessa on hyvä tietää. Voit palata kertaamaan sanan merkitystä missä vaiheessa vain.

WordPress teema ja rakennin

WordPressin käytössä on monesti kaksi kerrosta. Ensimmäinen ulompi kerros on sivustolla käytössä oleva teema. Tämä mahdollistaa sivuston muokkauksen teeman tyylin mukaisesti sekä sisällön lisäämisen sivustolle.

Toinen kerros on sivuston rakennin, joka mahdollistaa sivujen syvemmän muokkaamisen ilman, että teemaa tarvitsee erikseen muokata. Rakennin on monesti erikseen asennettava lisäosa, joka laajentaa teeman toiminnallisuuksia. Yleensä tapana on, että sivustolle asennetaan niin köykäinen teema kuin mahdollista ja sivusto rakennetaan tämän jälkeen rakentimella, sillä nämä tarjoavat rikkaamman rakennuskokemuksen. Poikkeuksena toimii WordPressin oma Gutenberg, jota ei tarvitse asentaa erikseen.

Esimerkiksi:

Elementorin tapauksessa voit asentaa Elementorin oman Hello -teeman ja tämän päälle Elementor -rakentimen, jolla teet varsinaisen sivun. Muita kevyitä teemoja ovat esimerkiksi Astra ja GeneratePress.

Jos rakennat sivuston WordPressin omalla Gutenberg -rakentimella, pohjalla voi olla mikä tahansa teema.

Jotkut työkalut kuten Avada toimivat itsessään teemana sekä rakentimena. On myös työkaluja, jotka poistavat teeman kokonaan käytöstä eli näissä tapauksessa teemaa ei tarvitse asentaa ollenkaan. Oxygen Builder toimii esimerkiksi tällä tavalla.

Lisäosa

WordPress lisäosa on pala koodia, joka on koottu helposti ylläpidettävään ja asennettavaan muotoon. Lisäosat lisäävät sivustolle toimintoja ja voivat myös tarjota käyttöliittymän, joka antaa mahdollisuuden muuttaa lisäosan asetuksia ilman muutoksia koodiin. Lisäosaa voi verrata tietokoneelle asennettavaan ohjelmaan eli kun asennat ohjelmiston tietokoneelle, asennuspaketti luo automaattisesti tarvittavat pikakuvakkeet ja kansiot, jolloin sinun ei tarvitse itse tehdä miltein mitään asennuksen eteen. Myös päivittäminen onnistuu automatisoidusti eli ohjelma tekee muutokset tiedostoihin sinun puolesta. WordPress lisäosan ideologia on täysin sama eli se on vain ns. portti ennalta määrättyihin kansioihin ja tiedostoihin.

DOM (Document Object Model)

DOM eli Document Object Model on yleinen tapa kuvata esimerkiksi HTML -dokumentin rakennetta. Lyhyesti selitettynä, mitä yksinkertaisempi DOM, niin sitä nopeammin sinun sivusto toimii. Käytännössä tämä tarkoittaa sitä, että jokainen HTML -elementti (div, span, a, h1, h2, p jne.), jonka lisäät kasvattaa DOMin kokoa ja sitä kautta tekee sivustosta raskaamman.

HTML

HTML eli HyperText Markup Language on kieli, jolla kuvataan sivuston rakenne. Tämä on myös ehkä koodikielistä se tunnetuin ja uskoisin, että olet törmännyt joskus merkintöihin kuten <h1> (ylimmän tason otsikko) tai <a> (linkki). Nykyisin HTML koodia voi ajatella sivuston luurankona, jota täydennetään muiden kielien avustuksella kuten CSS tai JS.

CSS (Cascading Style Sheets)

CSS eli Cascading Style Sheets on tyylikieli, jota käytetään kuvaamaan sitä miten esimerkiksi sivuston elementit näytetään kävijälle. Voit muokata esimerkiksi kokoa, väriä ja nykyisin jopa lisätä sisältöä kuten ikoneita CSS -kielen avulla. Jos HTML on sivuston luuranko, niin CSS -kieltä voi ajatella lihana luurangon ympärillä. Tämän avulla ulkoasusta tehdään kauniin näköistä. CSS on ehdottomasti yksi tehokkaimmista kielistä mitä verkkosivujen tekijä voi osata.

JS (JavaScript)

JavaScript on maailman käytetyin ohjelmointikieli ja kolmas kielistä mitä käytetään pääasiassa verkkosivujen rakentamisessa. JavaScriptin tarkoituksena on lisätä sivulle dynaamisuutta.

PHP

PHP on toinen vahvasti verkkosivujen rakentamisessa käytetty ohjelmointikieli. WordPress itsessään on vahvasti PHP -kieleen pohjautuva editori, joten sen osaaminen mahdollistaa hyvin laajan muokattavuuden verkkosivuille.

Cache

Cache eli välimuistia käytetään sivuston osittaisen sisällön tallentamiseen joko palvelimelle tai kävijän selaimeen. Välimuistin käyttö mahdollistaa sen, että kaikki verkkosivun tiedostoja ei tarvitse ladata jokaisella latauskerralla uudestaan, vaan nämä voidaan hakea joko palvelimen välimuistista tai sivuston kävijän selaimen välimuistista.

CDN

CDN eli Content Delivery Network on jakeluverkko, joka käytännössä jakaa verkkosivustosi sisällön ympäri maailmaa ja lataa sivuston sisällön (tai sen paloja) kävijää lähimpänä olevasta sijainnista. Koska sivusto voi sijaita fyysisesti vain yhdellä palvelimella, pyritään CDN verkkojen avulla jakamaan sivuston kopiota kävijää lähimpänä olevasta sijainnista.

Requests eli pyynnöt

Kun puhutaan pyynnöistä, nämä ovat asioita joita käyttäjän selain lataa sivulatauksen yhteydessä. Pyyntöjä voi olla esimerkiksi kuvat, css-tiedostot, js-tiedostot tai fontit. Jokainen kuva edustaa yhtä pyyntöä ja jokainen fontti-tiedosto edustaa yhtä pyyntöä. Keskimäärin hyvä nyrkkisääntö on, että mitä vähemmän pyyntöjä sivulataus tuottaa, sen kevyemmästä sivustosta on kyse.

Sivuston nopeudella ja käytettävyydellä on useita vaikutuksia. Merkittävimpiä syitä ovat kuitenkin seuraavat.

Sivustosi käyttökokemus paranee

Responsiivinen ja ripeästi toimiva sivusto on selvästi miellyttävämpi käyttää ja pitää kävijän sivustolla kauemman. Jos sivusto ei reagoi halutulla tavalla, on hyvin iso mahdollisuus, että kävijä ei jaksa selata sivustoa ja siirtyy muualle. Sivuston ladatessa yli 5 sekuntia on 90% todennäköisempää, että vierailija lähtee jo ennen sivun latausta.

Lähde: https://www.thinkwithgoogle.com/intl/en-154/marketing-strategies/app-and-mobile/how-stack-up-new-industry-benchmarks-for-mobile-page-speed/

Sivustosi konvertoi kävijöitä paremmin asiakkaiksi

Konversioprosentin parantuminen on suora seurannaisvaikutus siitä, että sivustosi käyttökokemus paranee. Jos esimerkiksi pyörität verkkosivustoilla mainontaa, älä anna mainosrahojen mennä hukkaan säästämällä huonon verkkosivun (tai palvelimen) kanssa!

Sivustosi arvioidaan korkeammalle hakukoneissa (SEO paranee)

Googlen Core Web Vitals uudistuksen myötä nopeudella on tällä hetkellä enemmän merkitystä kuin koskaan ennen. Tämä ei kuitenkaan tarkoita suoraan sitä, että sivuston täytyisi saada täydet pisteet jokaisesta testistä. Riittää, että tämä läpäisee tarvittavat testit. On muistettava, että testien läpäiseminen ei ole ihan läpihuutojuttu ja tämän takia on hyvä noudattaa hyviä käytänteitä jo sivustoa rakentaessa.

Valitse teema ja käytössä oleva rakennin huolella

Yksi merkittävimmistä valinnoista sivuston suorituskyvyn suhteen on oikean teeman valinta. Tämä ei vaikuta pelkästään suorituskykyyn, vaan myös siihen miten tulet rakentamaan tai muokkaamaan sivustoa ja sen ulkoasua. Käytännössä tämä tarkoittaa sitä, että kannattaa todella käyttää hetki siihen kun vertailet eri vaihtoehtoja. Paras skenaario on jopa kokeilla eri rakentimia testisivustoilla, jolloin saat käytännön kokemusta miten nämä käyttäytyvät. Kannattaa myös muistaa se, että monesti rakentimen tai teeman kehittäjä ilmoittaa sivustollansa, jos heidän työkalu on rakennettu nopeus edellä! Markkinoilla on niin paljon järjettömän raskaita rakentimia ja teemoja, että monesti nopeus on myyntivaltti.

Suorituskyvyn kannalta parhaimpien rakentimien joukkoon nousee monesti Oxygen Builder ja joukossa on myös uusia tulokkaita kuten Bricks Builder tai Zion Builder. Myöskään WordPressin omaa Gutenberg editoria ei kannata vähätellä, sillä tämä on äärimmäisen kevyt ja kehittyy ominaisuuksiltaan kokoajan. Käytännössä kaikki vaihtoehdot, jotka on rakennettu suoraan suorituskyky edellä ovat hyviä vaihtoehtoja sivustosi pohjalle. Jos englanti ei taivu, niin taikasana mitä pitää välttää on bloated eli raskaat sivut ovat pöhöttyneitä!

Suosittuja vaihtoehtoja ovat myös Elementorin tai Divin kaltaiset työkalut, mutta suhtaudu näihin varauksella sillä kyseisillä alustoilla on hyvin helppo tehdä tukkoisia ja huonosti suoriutuvia sivuja. Tämän artikkelin kirjoitushetkellä molemmat alustoista keskittyvät kuitenkin vahvasti suorituskyvyn parannuksiin eli tulevaisuus voi olla aivan eri näköinen.

Vältä ylimääräisiä lisäosia

Suorituskyvyn kannalta lisäosat ovat WordPress sivujen isoin synti ja herkin paikka missä kokematon kehittäjä menee metsään. Tarkoitan tällä sitä, että vaikka lisäosilla on monesti hyvin helppo lisätä toiminnallisuuksia verkkosivustolle, näiden mukana voi tulla ylimääräisiä skriptejä, tiedostoja tai tietokantarivejä (tai kaikki näistä). Monesti mitä lisäosa tekee sinun sivustolle on seuraava:

• Sivuston tietokantaan lisätään uusi taulu, jossa säilötään lisäosaan liittyvät tiedot
• Lisäosan latauksen yhteydessä sivusto lataa lisäosaan liittyvän JS -ja CSS tiedoston (pitäähän ulkoasu ja käyttöliittymä muotoilla jollain tai lisätä muita toiminnallisuuksia)
• Sivuston ylläpitäjällä on yksi palanen lisää ylläpidettävänä ja potentiaalisesti jopa pala, joka voi rikkoa sivuston toiminnan.

Teoriassa lisäosa on vain pala koodia ja yksittäin mikään näistä ei ole varsinaisesti ongelma. Kuitenkin jos asennat sivustolle viisi lisäosaa, jotka tekevät kaikki nämä yllä mainitut toimenpiteet, niin vaikutus on jo moninkertainen. Koska vaikutukset kertautuvat, on hyvä välttää kaikkia lisäosia ja asentaa lisäosa vasta siinä vaiheessa kun se on välttämätön sivuston toiminnalle, tai toiminnallisuutta ei pysty toteuttamaan järkevästi ilman tätä. Esimerkkinä, jos toiminnallisuus on hyvin monimutkainen, niin tämän itse koodaaminen ja koodin ylläpitäminen ei yksinkertaisesti ole kannattavaa.

On kuitenkin muistettava se, että kun valitset oikeat työkalut, voit selvitä hyvinkin pienillä määrillä asennettuja lisäosia. Hyvä nyrkkisääntö on myös, että jos asia on toteutettavissa helposti omalla koodilla, niin kannattaa tehdä se itse (se ei ole niin pelottavaa kuin miltä se aluksi kuulostaa).

Hyviä esimerkkejä tilanteista, joissa voit yhdellä lyhyellä skriptillä lisätä toiminnallisuuden ilman lisäosia ovat esimerkiksi Tag Managerin tai muun analytiikan asennus (käytännössä katsoen kaikki skriptit mitä lisäät sivuston header, body tai footer osioihin), Font Awesomen tai muun fontti/ikonikirjaston lataaminen sivustolle ja CPT:n eli custom post typen lisääminen sivuille. Myös SVG -tiedostojen tuki tai tiedostojen lataamisen estäminen ovat asioita, jotka hoituvat helposti ilman ylimääräisiä lisäosia.

Alla on funktio, jolla pystyt lisäämään helposti skriptejä sivuston header osioon. Tämän avulla saat lisättyä esimerkiksi Google Tag Managerin sivustolle ilman lisäosia. Funktio tulee lisätä functions.php tiedoston sisälle, tai jos sivustollasi ei ole tätä käytössä, voit käyttää lisäosaa kuten Code Snippets tai Advanced Scripts. Muista korvata funktion sisälle oma GTM ID ja jos et käytä Font Awesomea (tai jos se latautuu jotain muuta reittiä pitkin) voit poistaa sen kokonaan.

Font Awesomen voi kuitenkin ladata sivustolle paremmillakin keinoilla, joista kerron lisää myöhemmin!

Vastaavasti voit tehdä saman sivuston body osioon seuraavalla funktiolla.

Pidä verkkosivuston pyyntöjen määrä pienenä

Käytännön tasolla kaikki mitä sivustolle lisäät tai lataat vaikuttaa pyyntöjen määriin. Pyyntö voi olla mikä tahansa resurssi jonka selain joutuu lataamaan eli muun muassa kaikki kuvat, kaikki css -tiedostot, kaikki js -tiedostot ovat pyyntöjä. Hyvänä nyrkkisääntönä on, että mitä enemmän pyyntöjä selain joutuu käsittelemään, sitä raskaammasta sivustosta on kyse. Muista, että kaikki pyynnöt eivät ole tasavertaisia eli on eri asia ladata 10Mt video kuin muutaman kilotavun ikoni.

GtMetrix on äärimmäisen näppärä työkalu, jos sinun täytyy nopeasti (ja selkeästi) tarkastaa mitä kaikkea verkkosivusto lataa. Yllä olevassa kuvassa näkyy sivuston www.goodi.fi sen hetkiset pyynnöt. Yksinkertaisemmilla verkkosivustoilla pyyntöjen määrä tulisi olla alle 50 (mielellään lähempänä 25 kuin 50), mutta verkkokaupoilla ja paljon sisältöä lataavilla sivuilla pyyntöjen määrä voi nousta useampaan sataan. Lazy loading -tekniikoilla on mahdollista viivästää ladattavia resursseja, jolloin selain lataa vain ne resurssit, jotka ovat todella tarpeellisia.

Ulkoisten lähteiden vaikutus sivuston nopeuteen

Ulkoiset lähteet ovat tiedostoja, joita ei ladata lokaalisti sivuston palvelimelta. Ulkoisia lähteitä voivat olla esimerkiksi

• Facebook Pixel
• Google Tag Manager
• Google Ads
• Google Analytics
• Hotjar
• Cookie Bot
• Fontit
• Youtube -tai Vimeo -videot
• jne.

Kaikki palvelimen ulkopuolelta tulevat palvelut ja sisältö ovat ulkoisia lähteitä. Nopeuden kannalta hyvä nyrkkisääntö on, että mitä enemmän lataat asioita lokaalisti, sen parempi. On kuitekin tilanteita missä ulkopuolelta ladattu lähde toimii nopeammin kuin lokaalisti ladattu lähde. Näitä ovat esimerkiksi CDN -palveluiden kautta tulevat resurssit. Oman kokemuksen mukaan nämä ovat kuitenkin sivustoriippuvaisia asioita eli kiveen hakattua sääntöä tästä ei pysty tekemään. Harvemmin on myös järkeä lähteä A/B testaamaan jokaista resurssia, joten lataan vain kaiken mahdollisen sivustolle lokaalisti. Tällä tyylillä on saavutettu huononakin päivänä 95/100 (hyvänä päivänä täydet 100 pojoa) pärjääviä sivustoja eli riittää minulle.

Jos lataat tiedostoja lokaalisti, pystyt määrittämään näille myös omia välimuistisääntöjä (cache-policy). Koska hallitset itse sisältöä, pystyt vaikuttamaan myös siihen mitä tiedoston sisällä on. Voit esimerkiksi karsia fonteista ja ikoneista turhia bittejä pois, jos nämä eivät ole käytössä sivustolla.

Ainoana poikkeuksena lähteistä mihin ei kamalan helposti pysty vaikuttamaan ladataanko se lokaalisti vai ulkopuolisesta lähteestä, on sivuston analytiikka. Kyseisten skriptien lokalisointi on tuloillaan, mutta tällä hetkellä se ei käytännössä maksa vaivaa eli parempi vain tyytyä pieneen häviöön ja ladata ne ulkoisista lähteistä.

DOM -elementtien määrän pitäminen pienenä

DOM -elementit ovat yksi merkittävimpiä tekijöitä siinä miksi jotkut teemat ja rakentimet toimivat nopeammin kuin toiset. Kehittäjien foorumeilla ja markkinointiteksteissä puhutaan sanoilla “bloated”, joka viittaa siihen, että sivusto generoi tarpeettoman paljon ylimääräistä koodia. Tämä johtaa tarpeettoman isoon DOM -puuhun ja hidastaa sivuston toimintaa.

DOM pidetään pienenä tekemällä asiat yksinkertaisesti ja mahdollisimman pienellä määrällä koodia. Käytännön tasolla tämä tarkoittaa sitä, että käytä DIV tai kuita HTML -elementtejä vain silloin kun on tarve ja hyödynnä moderneja tekniikoita kuten flexbox ja grid. WordPressin näkökulmasta kannattaa myös valita rakennin, joka tekee siistiä koodia eikä aiheuta sivustolle pöhötystä.

Tarkasta kuvien koko

Kuvat kasvattavat merkittävästi sivulatauksen kokoa ja näiden pienentäminen oikeaan kokoon on loppujen lopuksi hyvin helppoa. Kuvien optimoinnilla voit helposti säästää sivulatauksen koossa megoja tai kymmeniä megatavuja.

Ensimmäisenä on hyvä tarkastaa kuvan koko. Tämä käy käteviten klikkaamalla kuvan kohdalla hiiren oikeaa painiketta ja valitsemalla ”Inspect”

Tämän jälkeen sinulla avautuu Chromen (tai muun selaimen) kehittäjän valikko. Chromessa voit viedä hiiren kuvaelementin ylle, josta näet suoraan mikä on kuvan todellinen koko (intrinsic size) ja minkä kokoisena selain näyttää kuvan (rendered size). Jos kuvan todellinen koko heittää renderöidystä koosta paljon, voi olla järkevää pienentää palvelimella olevan kuvan kokoa. Kuvaa ei kuitenkaan kannata pienentää liikaa, jotta terävyys ei kärsi. Korkeamman resoluution näytöillä hieman isommat kuvat alaspäin skaalattuna näyttävät paremmalta kuin tismalleen oikean kokoiset kuvat.

Pakkaa kuvat

Kun sinulla on kuvan oikea koko selvillä viimeinen vaihe on pakata se mahdollisimman pieneen kokoon. Tähän kätevä työkalu on https://tinypng.com/. Raahaa ensin täysikokoiset kuvat työkaluun ja lataa pakatut kuvat tämän jälkeen omalle koneelle. Voit ladata kuvat sen jälkeen takaisin palvelimelle.

Käytä moderneja kuvaformaatteja kuten .webp

Kuvien pakkaukseen liittyvät tekniikat ovat parantuneet selvästi ja uusia formaatteja tuodaan yleisölle tasaiseen tahtiin. Formaattien kuten .webp käyttö voi johtaa pienempään kuvan kokoon ja parantaen näin sivuston latausnopeutta. Kannattaa kuitenkin tarkastaa selaintuki aina kun otat käyttöön uusia formaatteja tai tekniikoita!

CSS -ja SVG Sprites tekniikoiden käyttö

CSS Sprites tai SVG Sprites ovat tekniikoita, joilla useita irrallisia kuvia tai ikoneita yhdistetään yhdeksi isommaks kuvatiedostoksi. Isompi kuva rikotaan sen jälkeen sivuston koodissa pienemmiksi paloiksi ja kävijälle esitetään käytännössä leikattu pala isosta kuvasta. Optimoinnin näkökulmasta tämä tarkoittaa sitä, että kävijän selain joutuu lataamaan vain yhden kuvan viiden tai jopa kymmenien sijasta, mikä monesti nopeuttaa sivun toimintaa.

Näin vähennät pyyntöjä CSS Spritesin avulla

1. Yhdistä kuvat yhdeksi isoksi kuvaksi esimerkiksi seuraavan työkalun avulla https://responsive-css.spritegen.com/. Kun olet lisännyt tiedostot, klikkaa painiketta ”Create Sprites”

2. Lataa generoitu kuva klikkaamalla hiiren oikealla painikkeella ja valitsemalla ”Save Image As”.

3. Tallenna generoidut HTML ja CSS koodin pätkät esimerkiksi tekstitiedostoon

4. Lataa haluttu kuva WordPressiin tai palvelimelle

5. Korvaa CSS -koodissa oleva url -osoite tiedoston todellisella polulla. Kannattaa jättää verkkotunnus pois, jolloin osoite on muotoa ”/wp-content/uploads/2021/07/css-sprites.png”. Löydät osoitteen näppäriten kun menet WordPressin hallintaan, valitset ”Mediakirjasto” ja klikkaat halutun kuvan auki. Tiedoston URL -osoite näkyy tiedoissa.

6. Lisää HTML -koodissa olevat IMG -tagit sinne missä haluat kunkin kuvan latautuvan. Eli käytännössä alla olevan kaltaisen koodin pätkän sinne, missä haluat kuvan näkyvän. Älä kuitenkaan kopioi alla olevaa, sillä se ei toimi sinun kohdalla. Saat oikean koodin generaattorin luomasta HTML -tiedostosta, jonka kopioit aiemmin talteen.

<img class=”kuva-1″ alt=”” src=”data:image/png;base64…..

Vältä ”background-image” -käyttöä CSS -tiedoston sisällä

Taustakuvien optimointi on monesti haasteellista sillä nämä ovat usein matalan prioriteetin pyyntöjä ja hankalia Lazy Load -sääntöjen suhteen. Kuvan latautuminen on myös riippuvainen siitä onko kuva HTML -koodin seassa vai ladataanko se CSS -tiedostosta. Jos kuva ladataan CSS -tiedostosta, tämä ladataan vasta kun tiedosto on itsessään parsittu eli mitä ikinä teetkään, niin kuva kannattaa ladata HTML -koodin seassa. WP Speed Matters on kirjoittanut aiheesta artikkelin ja esittelee useamman keinon, millä kuvia saa optimoitua ja artikkeli kannattaa tarkastaa täältä.

Yleisin paikka missä saatat taustakuvaa käyttää on sivujen bannerikuvat. Yksi tapa näiden optimointiin on käyttää <picture> -tagia ja ”position: absolute” sääntöjä. Tällä tavalla saat sivustollesi taustakuvan, jossa tekstit ovat kuvan päällä ja voit lisäät myös CTA -painikkeita tai muita elementtejä.

Koska fontit vievät oletuksena hyvin paljon tilaa www-sivuilta, kannattaa aina miettiä mitkä kaikki fontit ovat tarpeellisia ja kuinka paljon pystyt karsimaan näiden määrää. Tämän lisäksi on kuitenkin toimenpiteitä, joilla voit varmistua, että fontit latautuvat mahdollisimman tehokkaasti.

Optimoi fonttien koko

Ensimmäinen askel on ladata haluttu fontti lokaalisti omalle tietokoneelle. Kun olet ladannut fontteihin liittyvät tiedostot lokaalisti, voit optimoida näiden koon. Ilman optimointeja yksittäisen fonttitiedoston koko voi olla useita satoja kilotavuja, mutta optimoinnilla on mahdollista tiputtaa kokoa, jopa 20 kilotavuun per tiedosto. Tässä esimerkissä hyödynnämme Font Squirrelin työkalua.

1. Mene ensin osoitteeseen https://www.fontsquirrel.com/tools/webfont-generator
2. Asetuksista valitse moodiksi “Expert” ja fontin formaatiksi .woff2 ja .woff (voit valita myös muita jos haluat)
3. Valitse lisäasetuksista “Custom Subsetting” ja valitse halutut kielet ja merkit. Kannattaa valita vain ne merkit mitä todella tarvitset, sillä tämä vaikuttaa merkittävästi fonttien kokoon. Kohdasta “Subset Preview” näet käytössä olevat merkit ja voit tästä tarkastaa, että fontti sisältää kaikki merkit mitä tarvitset. Jos joitain merkkejä puuttuu, voit lisätä ne Subsetting valikoiden alta.
4. Advanced Options alta tyhjennä “prefix”, jotta fontin nimet eivät paisu liian isoiksi.
5. Lataa tiedostot omalle tietokoneelle.

Fonttien lataaminen palvelimelle

Jotta fontit saadaan käyttöön, nämä täytyy ladata vielä palvelimelle. Lataa ne kansioon, josta näitä haluat käyttää ja jos mahdollista kannattaa korvata alkuperäiset fontit uusilla optimoiduilla fonteilla.

Se miten fontit otetaan sivustolla käyttöön riippuu siitä, mitä työkalua käytät. Joudut kuitenkin todennäköisesti lataamaan ne @font-face -säännöllä ja määrittämään fontit käyttöön manuaalisesti. Voit tutustua fonttien lataamiseen tarkemmin täältä.

Huom! Fonttien kanssa kannattaa aina muistaa yhteensopivuus taaksepäin. Teoriassa kaikki modernit selaimet (yli 96% kaikista käyttäjistä) tukevat jo woff2 -formaattia, mutta on joitain vanhoja selaimia, jotka eivät välttämättä tätä tue. Voit itse tehdä arvion kuinka paljon tuet vanhoja selaimia ja voit käyttää arviossa apuna seuraavaa www -sivua https://caniuse.com/woff2. Hyvä tapa on määrittää useampi eri formaatti eli jos selain ei jostain syystä pysty lataamaan pääasiallista formaattia, ladataan toissijainen formaatti.

Käytä mukautuvia fontteja (Variable Fonts)

Mukautuvat fontit mahdollistavat usean eri fonttivariaation lataamisen yhden tiedoston sisällä, joka vähentää pyyntöjen määrää. Pystyt myös muokkaamaan fontin paksuutta ja/tai kaltevuutta täysin vapaasti tai jopa animoida koon muutoksia sivuille! Esimerkiksi fontin paksuuden (weight) ei tarvitse olla tasan 700, vaan paksuus voi olla täysin mielivaltaisella arvolla kuten 678.

Mukautuvat fontit eivät ole ihan vielä valmiita laajempaan käyttöön, mutta tämä teknologia on tuloillaan ja on hyvä olla siitä myös tietoinen. Googlella on loistava artikkeli mukautuvista fonteista, joka kannattaa lukea läpi. Pääset artikkeliin osoitteesta https://web.dev/variable-fonts/

Optimoi ikonien koko

Toinen paikka mistä saamme merkittävästi nipistettyä fonttien kokoa on Font Awesome tai muut ikonit. Hyvin monella www-sivulla on vain muutama ikoni käytössä, joten on parempi ladata sivustolle ne ikonit mitä sinne tarvitaan. Ikonien määrää karsimalla Font Awesome Solid perheen fontin koko tippui esimerkiksi 90 kilotavusta pariin kilotavuun.

1. Mene ensin osoitteeseen https://icomoon.io/app/

2. Valitse kohta “Add Icons from Library” ja valitse Font Awesome (tai muu ikonikirjasto). On tapauksia, joissa saatat joutua käyttämään “Import Icons” toimintoa. Jos optimoit esimerkiksi Font Awesomen kirjastoa, voit ladata ikonit osoitteesta https://fontawesome.com/v5.15/how-to-use/on-the-web/setup/hosting-font-awesome-yourself ja tämän jälkeen ladata ne sivulle. Käytössä olevien ikonien valitseminen tapahtuu samaan tapaan ja voit tämän jälkeen exportata fontin.

3. Valitse haluamasi ikonit ja generoi fontti painamalla “Generate Font” painiketta alakulmasta

4. Lataa fonttitiedostot palvelusta ja lataa nämä sivuston palvelimelle. Lokaalit ikonit kannattaa ladata wp_enqueue funktiolla, josta löytyy esimerkki myöhempää tätä artikkelia. Pääset ohjeeseen tästä.

CDN -palvelut

CDN -verkkojen avulla sivusto voidaan ladata kävijää lähimmästä sijainnista tarjoamalla hänelle kopio sivun sisällöstä. CDN -palveluntarjoajat saattavat harrastaa myös ns. cachetusta ja tallentaa staattisen kopion sivustosta. Tämä tuo kaksi etua eli sivusta ladataan selvästi kevyempi versio ja tämä ladataan kävijää lähimmästä sijainnista.

Suomessa sijaitsevalle palvelimelle, joka palvelee suomalaisia, CDN -palvelun käyttö ei tuo toiminnan kannalta merkittäviä etuja, mutta sivuston Page Speed -arvot saattavat nousta reilustikkin sillä Google lataa sisällön lähempää heidän mittauspistettä.

Hyviä CDN -tarjoajia ovat esimerkiksi Cloudflare tai Quic.cloud, jotka myös integroituvat Litespeed -lisäosan kanssa. Louhen Sovellushotelleihin sisältyy Litespeed Enterprise -lisenssin tuoma Quic.cloud valmius eli saat hyvän määrän krediittejä CDN -palvelun käyttöön.

Cache -lisäosien käyttö

Cache -lisäosat tekevät monesti sivustolle optimointia kuten koodin tiivistystä (minify) ja yhdistämistä (combine). Nämä luovat välimuistiin liittyviä sääntöjä eli käskevät selainta lataamaan sisältöä selaimen välimuistiin, jolloin kaikkea sisältöä ei tarvitse ladata toiseen kertaan, vaan tiedostot voidaan hakea paikallisesti kävijän tietokoneelta. Lisäosissa voi olla myös muita toimintoja kuten skriptien lataamisen myöhästyttämistä, kuvien optimointia tai Lazy Load -toimintoja. Lisäosien käyttö on käytännössä viimeinen kerros, jolla varmistetaan sivun nopea toiminta.

Monesti lisäosien käyttö ei itsessään ole sen monimutkaisempaa kuin pistää rastin ruuttuun ja hyvin tehdyillä sivuilla myös rikkoutumisen riski on pieni. Muista kuitenkin tarkastaa sivun toiminta jokaisen toimenpiteen jälkeen.

Litespeed Cache

Litespeed on Headless WP:n jälkeen ehkä puhutuimpia teknologioita. Tämä poikkeaa tavanomaisemmasta välimuistista sillä tavalla, että LSCache keskustelee ja on integroitu tiukasti serverin kanssa yhteen. Nykyisin LSCachea on mahdollista käyttää myös (lue lisää täältä) ilman Litespeed -serveriä, mutta tällöin välimuistiin liittyvät toiminnot eivät ole toiminnassa ja lisäosa toimii pelkkänä sivuston optimointityökaluna.

Litespeed itsessään on todella helppokäyttöinen ja ennen kaikkea tehokas, joka tekeekin siitä Louhen suosituksen jokaiselle WordPress -sivulle.

Muita cache -lisäosia ovat esimerkiksi W3 Total Cache, WP SuperCache, WP Rocket, Cache Enabler tai WP Fastest Cache. Nämä toimivat hieman perinteisemmän välimuistin tavoin eli ne eivät hyödynnä ns. server-side toimintoja.

wp_dequeue ja wp_enqueue ovat ovat WordPressin funktioita, joiden avulla on mahdollista estää skriptien ja tyylitiedostojen latautuminen tai rekisteröidä uusia tyylitiedostoja. Samoihin toimenpiteisiin liittyy vielä wp_register_script ja wp_deregister_script funktiot.

CSS -ja JavaScript tiedostojen lataamisen estäminen ja rekisteröinnin poisto

Tiedosto handlen etsiminen 

Ensimmäinen vaihe kun haluat estää tiedoston lataamisen sivustolla on selvittää tämän handle eli tunniste. Voit käyttää apuna Cameron Jonesin luomaa skriptiä tai lataamalla WP Query Monitor lisäosan, jolla pystyt katsomaan mitä skriptejä tai tiedostoja sivu lataa.

CSS -tiedostojen kanssa handlen etsiminen ei vaadi ylimääräisten skriptien lisäämistä vaan pystyt hakemaan sen suoraan sivun lähdekoodista. Etsi lähdekoodin seasta <link> tagin ID:n ja poista perästä ‘-css’ -lopuke. Esimerkiksi jos tagin ID on ‘wp-block-library-css’, handle on tässä tapauksessa ‘wp-block-library’

Tiedoston latauksen estäminen ja rekisteröinnin poisto eli dequeue/deregister

Kun tiedät tiedoston handlen, pystyt estämään sen latautumisen hyvin helposti. Lisää alla oleva skripti sivuston functions.php tiedostoon tai käytä Code Snippets tai Advanced Scripts nimisiä lisäosia.

Alla olevalla skriptillä pystyt poistamaan JavaScript -tiedostojen latautumisen.

Vastaavasti jos haluat estää tyylitiedostojen eli CSS-tiedostojen latautumisen voit käyttää seuraavaa skriptiä.

Muista korvata $handle varsinaisella tiedoston handlella.

Uuden tiedoston rekisteröinti (esimerkkinä Font Awesome kirjaston lataaminen)

Kun vanhojen tiedostojen lataaminen on estetty, on aika rekisteröidä uudet tyylit sekä tiedostot. CSS -tiedostojen lataaminen onnistuu seuraavalla tavalla:
1. Lataa haluttu tiedosto haluamaasi alikansioon (tai luo oma) wp-content sisällä. Tähän voi esimerkiksi käyttää esimerkiksi ‘uploads’ -kansiota, jota käytämme alla olevassa esimerkissä.

2. Luo uusi PHP -funktio, jolla rekisteröidään ja ladataan haluttu tiedosto

3. Rikotaan skriptin toiminta palasiksi.

wp_register_style(’$handle’, $url);

Ensin rekisteröidään uusi tyyli. Funktio koostuu kahdesta palasesta, handlesta ja tiedoston URL-osoitteesta. Tiedoston ‘handle’ voi periaatteessa olla mikä tahansa ja tätä vain kutsutaan jäljempänä. Tee siitä kuitenkin mahdollisimman ymmärrettävä. URL -osoitteen kohdalla on suositeltavaa käyttää dynaamisia polkuja.

Näistä pari esimerkkiä ovat seuraavat:

get_template_directory_uri() hakee aktiivisen teeman kansion osoitteen
wp_upload_dir()[’baseurl’] hakee ‘uploads’ kansion osoitteen

Jos halutaan hakea esimerkiksi uploads -kansiosta jokin tiedosto, voidaan polku kirjoittaa seuraavalla tavalla:

wp_upload_dir()[’baseurl’] . ’/fonts/FontAwesome/solid.min.css’

Osoite tarkoittaa samaa kuin www.domain.tld/wp-content/uploads/fonts/FontAwesome/solid.min.css.

‘ ’ -merkkien sisällä oleva polku voidaan korvata polulla, missä tiedosto varsinaisesti on.

wp_enqueue_style( ’$handle’ );

Seuraavana tiedosto ladataan WordPressiin tyylitiedostona. Tässä käytetään aiemmin määriteltyä handlea.

add_action( ’wp_enqueue_scripts’, ’funktion_nimi’ );

Viimeisenä luodaan uusi hook, joka käyttää aiemmin luotua funktiota.

Samaa tyyppiä olevien tiedostojen yhdistäminen keskenään (CSS tai JS)

Yksi kikka millä saat sivuston pyyntöjä vähennettyä on CSS -taulujen tai Javascript tiedostojen yhdistäminen käsin. Kannattaa muistaa, että moni lisäosa tekee tämän toimenpiteen sinun puolesta eli hyvin harvoissa tapauksissa on edes kannattavaa yhdistää tiedostoja käsin. On kuitenkin hyvä tietää teoria kyseisen toimenpiteen taustalla.

Huomioithan sen, että voit yhdistää vain CSS -tiedostoja keskenään ja JS -tiedostoja keskenään eli et pysty yhdistämään näitä ristiin.

Tiedoston yhdistäminen on kuitenkin kohtuullisen suoraviivainen toimenpide

1. Luo uusi tiedosto (tänne kopioidaan yhdistettävien tiedostojen sisältö)
2. Tarkastele hiiren oikealla klikkauksella sivuston pohjakoodia (View Page Source)
3. Etsi sivuston head -osiosta kaikki CSS-tiedostot (tai jos yhdistät Javascript tiedostoja niin nämä) jotka latautuvat sivulatauksen yhteydessä

   

4. Avaa tiedosto klikkaamalla tätä. Sinun pitäisi nyt nähdä tiedoston sisältö
   Kopio tiedoston sisältö uuteen tekstitiedostoon
5. Toista sama kaikille sivulla oleville CSS -tiedostoille.

Käytännössä kaikki erilliset CSS-tiedostot yhdistetään yhdeksi isoksi CSS-tiedostoksi.

Jos teet yhdistämistä Javascript -tiedostoille niin prosessi on kutakuinkin sama. Varmista, että sinun skriptit lataavat oikeassa järjestyksessä!

Käytä WordPressille -optimoituja palvelimia ja alustoja

Vaikka nykyisin palvelimen merkitys ei ole niin isossa roolissa kuin se miten sivu on rakennettu, on silti hyvä valita omaan käyttötarkoitukseen sopiva alusta. Hyvä sääntö palvelua valittaessa on se, että mitä enemmän liikevaihtoa verkkosivuston kautta liikkuu, sitä enemmän palvelimeen kannattaa rahallisesti satsata.

Jokaiselta palveluntarjoajalta kuten Louheltakin löytyy yleensä monen eri tason alustoja. Meidän palveluista Webhotellit (Perus, Rajaton, Voima) soveltuvat loistavasti pienille verkkosivuille. Jos taustalla on pieni verkkokauppa tai blogi, niin monesti järkevin ratkaisu on WordPressille optimoitu Sovellushotelli. WordPressille optimoidut hosting-alustat ovat yleisesti nopeampia sekä vikasietoisempia ja kestävät myös isomman määrän samanaikaista liikennettä.

Valitse riittävän iso palvelin verkkosivulle

Hyvin merkittävä tekijä palvelinta valittaessa on myös sen koko. Jaetussa ympäristössä sijaitsevat palvelut kuten tavalliset Webhotellit tai Sovellushotellit ovat edullisia ja ylläpidon kannalta helppoja ratkaisuja, ja soveltuvat loistavasti pienemmille verkkosivuille.

Kun sivuston kokoluokka kasvaa eli puhutaan esimerkiksi ruuhkaisemmasta blogista tai vähän isommasta verkkokaupasta, jaetun ympäristön ratkaisut käyvät hyvin äkkiä pieneksi. Omalla dedikoidulla palvelimella olevat ratkaisut vaativat ylläpidollisesti enemmän toimia, mutta koska kyseessä on sinun oma palvelin, kapasiteettia voi nostaa teoriassa niin paljon kuin sivusto tarvitsee. Toinen merkittävä ero jaettuun ympäristöön nähden on se, että jos sivuston resurssinkäyttö menee täyteen, dedikoidussa ympäristössä olevan sivuston toiminta vain hidastuu. Toisin kuin jaetun ympäristön resurssien täyttyminen näkyy sivuston kävijälle virheilmoituksena. Louhella on hyvin kätevä Sovelluskartano -palvelu, joka on periaatteessa Webhotelli omalla 24/7 ylläpidetyllä palvelimella. Tässä yhdistyy oman palvelimen tehokkuus ja webhotelli -palvelun helppous.

Kolmas kategoria on ns. klusteroidut ympäristöt, jossa palvelimille kohdistuvaa kuormitusta jaetaan useammalle palvelimelle. Tämä auttaa sivuston vikasietoisuudessa ja jos kyseessä on hyvin iso sivu, niin on keskimäärin tehokkaampaa jakaa palvelinten kapasiteetti muutamalle hieman pienemmälle palvelimelle kuin keskittää kaikki kapasiteetti yhteen isoon palvelimeen. Klusteroidut ympäristöt tulevat kyseeseen kun puhutaan hyvin isoista sivustoista kuten IS tai verkkokauppa.com kaltaiset isot verkkokaupat.

Se mikä tekee sivustokapasiteetin määrityksestä ikävän asian on se, että kapasiteetti täytyy määrittää aina isoimman piikin mukaisesti. Tämän takia puhutaan yhtäaikaisista kävijöistä.

Nyrkkisääntönä voidaan pitää seuraavaa:

Palvelun sietokykyä on mahdoton ennustaa etukäteen eli todellisen kuormituksen näkee vasta kun sivusto pyörii palvelimella. Hyvin rakennettu sivusto ja tehokkaat välimuistisäännöt auttavat parantamaan kuorman sietokykyä eli käytännössä, jos rakennat sivustosi hyvin, säästät myös selvää rahaa.

Tarkasta PHP -versio ja sen asetukset

PHP -versio on ehkä isoin merkittävä tekijä palvelinasetusten puolelta, jolla pystyt helposti vaikuttamaan sivuston toimintaan ja kannattaa aina käyttää niin tuoretta versiota kuin suinkin mahdollista. Yhteensopivuuden testaaminen on hyvinkin helppoa.

1. Ota ensin varmuuskopio WordPressistä
2. Päivitä kaikki lisäosat, WordPress sekä teema
3. Kirjaudu tämän jälkeen palvelimelle tai hallintapaneeliin kuten cPanel tai Plesk
4. Valitse PHP -asetuksista tuorein versio ja tarkasta tämän jälkeen sivuston toiminta. Jos sivusto toimii moitteetta, voit jättää tuoreimman version käyttöön. Jos sivusto rikkoutuu, vaihda toiseen versioon ja kokeile toiminta uudestaan

Varsinaista riskiä PHP-version vaihtamisesta ei ole eli voit huoletta kokeilla kuinka tuoreella versiolla sivustosi toimii.

PHP -asetuksista on mahdollista säätää esimerkiksi asetuksia kuten:

max_execution_time
Aika (sekunneissa), joka skriptin ajo voi maksimissaan kestää ennen kuin palvelin keskeyttää prosessin. Tämä estää huonosti kirjoitettujen skriptien ylikuormittamasta palvelinta.

Suositus: 600

max_input_time
Aika (sekunneissa), joka skriptillä voi maksimissaan kestää syötedatan (input data) parsimisessa (POST, GET, tiedostojen lataus).

Suositus: 400

max_input_vars
Muuttujien maksimimäärä, joita voi olla yksittäisessä pyynnössä.

Suositus: 1000

memory_limit
Määrää muistin määrän maksimissaan, joka annetaan skriptin käyttöön. Estää heikosti kirjoitetun skriptin syömästä kaikkea palvelimen muistia. Jos haluat asettaa rajoituksen pois, voit antaa arvoksi -1.

Suositus: 256M tai pienempi

post_max_size
Määrää postauksen maksimi koon. Vaikuttaa myös tiedostojen lataamiseen. Jotta pystyt lataamaan isoja tiedostoja, tämän arvon pitäisi olla suurempi kuin upload_max_file_size. Yleisesti post_max_size arvon pitäisi olla suurempi kuin upload_max_filesize.

Suositus: 128M

upload_max_filesize
Palvelimelle ladatun tiedoston maksimikoko.

Suositus: 64M

Tarkasta WordPressin muistiasetukset

PHP -muistirajan lisäksi myös WordPressillä on oma muistiraja. Käytännössä se missä PHP:n MEMORY_LIMIT määrittää kuinka paljon muistia palvelin voi käyttää kokonaisuudessaan, WP_MEMORY_LIMIT määrittää kuinka paljon WordPress saa käyttää muistia. Oletuksena WordPressin muistiraja on 40Mt.

Voit lisätä seuraavan rivin WordPressin wp-config.php tiedostoon. Suositus on minimissään 64Mt, mutta voit nostaa tämän myös korkeammaksi. Jokin rajoitus kannattaa kuitenkin pitää ettei sivusto imaise koko palvelimen muistia.

define(’WP_MEMORY_LIMIT’, ’128M’);

Optimoi tietokanta

WordPress hakee oletusarvoisesti kaiken tiedon tietokannasta, joka tarkoittaa myös sitä, että kaikki tieto tallentuu tietokantaan. Sivuston ylläpitäjän kannalta tämä tarkoittaa sitä, että ajan kanssa sivuston tietokantaan voi tallentua turhaa rojua, joka pitkässä juoksussa hidastaa sivuston toimintaa. Tämän takia on hyvä välillä tehdä siivouksia ja tarkistuksia tietokannalle.

Ensimmäinen asia mikä kannattaa laittaa päälle on revisioiden rajoitukset eli kirjoitusten eri versioiden automaattinen poisto. Tämä tarkoittaa sitä, että WordPress ei tallenna tietokantaan kuin maksimissaan sinun määrittämän määrän eri versioita, jolloin pitkällä juoksulla kanta ei pääse tukkeutumaan. Voit määrittää maksimirajan lisäämällä seuraavan rivin sivun wp-config.php tiedostoon. Litespeed Cache -lisäosa tarjoaa myös mahdollisuuden tälle asetukselle, jos sinulla on kyseinen lisäosa käytössä

define(’WP_POST_REVISIONS’, 3);

WordPressin toiminnasta on myös hyvä muistaa se, että kun asennat lisäosan sivulle, tämä lisää monesti tietokantaan uuden taulun. Monen lisäosan kohdalla se tarkoittaa myös sitä, että vaikka poistaisit kyseisen lisäsosan, tietokannassa oleva taulu ei poistu samalla. Täydellinen poisto vaatii siis taulun poistamisen manuaalisesti suoraan kannasta. Tästä syystä välillä on hyvä tehdä tarkistuksia mitä sivuston tietokannassa on ja tehdä tarvittavia toimenpiteitä sen mukaisesti.

Mitä tarkoittaa Core Web Vitals

Maaliskuussa 2021 Google toi hakukoneeseensa uudet Core Web Vitals arvot, joiden he kertoivat vaikuttavan SEO-tuloksiin enemmän kuin koskaan ennen. Arvojen on myös määrä mitata mahdollisimman tarkasti sivuston kävijälle oikeasti merkityksellisiä asioita. Core Web Vitals jakautuu kolmeen palaan:

LCP – Sivuston ensimmäisen sisällön latautumiseen kestävä aika

LCP mittaa sivuston ensimmäisen sisällön latautumiseen kestävää aikaa eli se on aika, jolloin verkkosivuston kävijän ruudulle ilmestyy jotain merkityksellistä. Käytännössä tämä tarkoittaa sitä, että missä ajassa kävijän näkökentässä oleva kuva tai teksti latautuu.

LCP -arvon tulisi olla alle 2,5 sekuntia ja pääset lukemaan syvemmin tämän arvon toiminnasta osoitteesta https://web.dev/lcp/

FID – Kävijän toimintojen viive

Kävijän toimintojen viive (FID) mittaa kuinka nopeasti sivusto reagoi kävijän tekemiin toimintoihin. Yleisesti viivettä tapahtuu silloin, jos selain ei kerkiä prosessoimaan kaikkia haluttuja toimintoja riittävän nopeasti. Käytännössä sivustolla voi syntyä viivettä kun selain joutuu parsimaan ja käsittelemään isoa JavaScript -tiedostoa, jonka aikana selain ei pysty käsittelemään muita pyyntöjä samanaikaisesti. FID:n pitäisi olla alle 100ms, jotta sivusto läpäisee Core Web Vitals testin.

FID mittaa ainoastaan tapahtumien suorittamisessa syntyvää viivettä eli tämä ei ota huomioon kokonaisaikaa, joka voi syntyä skriptin ajamisessa. Voit tutustua arvoon syvemmin täältä https://web.dev/fid/

CLS – Sivuston elementtien vakaus

Sivuston elementtien vakaus (CLS) mittaa sivuston visuaalista vakautta. Käytännössä tämä tarkoittaa sitä, että kuinka hyvin sivuston elementit pysyvät paikoillaan sivulatauksen aikana.

Jotta käyttökokemus säilyy hyvänä, arvon pitäisi pysyä alle 0.1. Voit tutustua arvoon syvemmin Googlen omasta artikkelista https://web.dev/cls/

Työkalut nopeuden mittaamiseksi

WordPress Debug työkalut

WordPressille löytyy erinomainen WP Query Monitor lisäosa, jolla on mahdollista paikantaa mm. sivustolla olevia virheitä, kyselyissä kestävää aikaa, JS/CSS tiedostojen handleja sekä selvittää mitä kaikkea sivusto konkreettisesti lataa. Lisäosa on arvioitu WordPressin sovelluskaupassa viidellä tähdellä ja tämä on täysin ansaittu arvosana.

Selaimen kehittäjän työkalut

Firefox ja Chrome ovat suosittuja kehittäjien piirissä selainten monipuolisten työkalujen vuoksi. Jos työskentelet CSS kanssa, niin Firefox on ehdoton ykkönen mitä tulee kehittäjien työkaluihin.

Kehittäjien työkalujen kautta pystyt tarkastelemaan mitä sivusto esimerkiksi kirjoittaa konsoliin eli syntyykö sivuston toiminnassa virheitä. Kannattaa huomioida, että kaikki virheet eivät kirjoitu konsoliin eli tämä on vain yksi monista keinoista tarkastella sivun toimintaa. Voit myös tarkastella yksittäisiä HTML -elementtejä tai miltä sivuston lähdekoodi näyttää.

GTMetrix & Pingdom

GTMetrix ja Pingdom ovat lähtökohtaisesti ensimmäisten paikkojen joukossa millä sivuston suorituskyvyn pullonkauloja pystyy selvittämään. Nämä antavat tuloksia hyvin selkokielisessä muodossa.

GTMetrix mahdollistaa hyvin kätevästi sivuston Waterfall näkymän eli mitä ja missä järjestyksessä sivu lataa asioita. Tätä kautta voi helposti tarkastella esimerkiksi mistä lähteistä sivusto lataa asioita tai tekeekö sivu ylimääräisiä redirecteja. Hyvin tyypillinen ja iso hidastava tekijä voi esimerkiksi olla se, että kun sivustolle menee pelkällä juuridomainilla, kävijä ohjataan ensin www-versioon, josta hänet ohjataan vielä suojattuun versioon. Tästä yhtälöstä on helposti tiputettavissa yksi ohjaus kokonaan pois ohjaamalla kävijä suoraan suojattuun varsinaiseen osoitteeseen, jolloin säästöt voivat olla jopa useita satoja millisekunteja.

Toinen asia mikä kannattaa tarkastaa on sivun kriittiset virheet. Näitä voi olla esimerkiksi liian isojen kuvien käyttö tai vaikka liian suuri DOM. Jaottelu menee kriittisyyden mukaan ja yleisesti jos puhutaan korkean tai keskitason ongelmista, nämä on syytä korjata.

Google Pagespeed ja web.dev

Pagespeed ja Web.dev ovat molemmat Googlen omia työkaluja nopeuden tarkastelussa. Nämä eivät ole ihan niin helposti ymmärrettävissä kuin esimerkiksi GTMetrix, mutta ovat arvioinniltaan hieman tiukempia ja kertovat syvemmin sivuston mahdollisista ongelmista. Web.dev ja Pagespeed kertovat myös onko sivulla vaikka SEO tai saavutettavuusongelmia. Mobiiliselauksen Pagespeed arvo on nykyisin se tärkein ja merkittävin mittari, jota Googlekin käyttää omassa hakukoneen tarkastelussa. Se on samalla myös kaikista tiukin ja vaikein arvo saada korkeaksi, sillä puhelinten suorituskyky ei ole niin hyvä kuin esimerkiksi tietokoneilla.

Koska käyttökokemus on GTMetrixin kanssa hieman parempi, monesti oma workflow saattaa mennä sillä tavalla, että optimoin ensin GTMetrixin kanssa isoimmat asiat kuntoon ja tämän jälkeen siirrytään hieromaan Pagespeed ja Web.dev arvoja.

Server-side Tagging (Google Tag Manager)

Server-side Tagging on käytännössä täysin uusi Googlen konsepti, joka tuli mahdolliseksi Tag Managerin server-side tekniikan myötä. Teoria tämän takana on se, että Tag Manageria ja sen sisällä olevia skriptejä pyöritetään omalla serverillä, jolloin nämä eivät ole hidastamassa varsinaisen käyttäjän selainta. Server-side tekniikka auttaa myös datan prosessoinnissa ja hallinnassa, koska tieto käsitellään sinun omalla palvelimella. Tietyissä käyttötapauksissa tämä voi olla myös GDPR -ystävällisempi tapa toteuttaa analytiikkaa sillä sinä omistat sekä sinulla on täysi hallinta dataan mitä keräät.

Jotkut arvioivat, että tämä on tulevaisuuden tapa hoitaa data-analytiikkaa ja hyötyihin nähden voi olla mahdollista, että tämä tuleekin yleistymään keskisuurilla organisaatioilla.

Jos aihe kiinnostaa, katso Simo Ahavan loistava artikkeli aiheesta täältä