Verkkosivustoja nopeutetaan usein väärässä järjestyksessä: joku asentaa optimointilisäosan, ottaa kaikki valinnat käyttöön ja alkaa sitten selvittää, miksi lomake ei enää toimi. Oikea järjestys on mittaus, hypoteesi, yksi muutos, toimivuuden tarkistus ja uusi mittaus.
Aiemmassa versiossa kuvasin myös lähestymistapoja, joita en enää suosittele, kuten muiden tuottamien skriptien välittämistä paikallisesti tai yleistä AMP- ja PWA-toteutusta. Ne toivat osittaista parannusta laboratoriomittauksissa, mutta lisäsivät vanhentuneen koodin riskiä, rikkoutuvia päivityksiä ja monimutkaisempaa ylläpitoa. Nykyaikaisen verkkosivuston pitäisi olla nopea pääversiossaan.
Mitä kannattaa mitata tänään
Core Web Vitals -mittareissa Google käyttää kolmea vakiintunutta mittaria:
- LCP: pääsisällön latautuminen; hyvä arvo on enintään 2.5 sekuntia.
- INP: vuorovaikutusten vaste; hyvä arvo on alle 200 millisekuntia.
- CLS: odottamattomat asettelun muutokset; hyvä arvo on enintään 0.1.
Kynnysarvot koskevat 75. persentiiliä, ja ne on koottu viralliseen Google-haun Core Web Vitals -yleiskatsaukseen. Todellisten kävijöiden tulokset Search Consolesta tai CrUXista ovat tärkeämpiä kuin yksi laboratoriotesti kannettavallani.
Laboratoriotyökalut ovat silti tärkeitä: ne näyttävät vesiputouksen, pääsäikeen, käyttämättömän koodin ja konkreettiset korjausehdokkaat. Kenttädata kertoo, että ongelma on olemassa; laboratorio auttaa selittämään miksi.
Määritä ensin ongelman laajuus
- Vertaa mobiili- ja työpöytäversiota.
- Erottele sivupohjat: etusivu, artikkeli, palvelu, listaus, lomake ja verkkokauppa.
- Tarkista nopeat ja hitaat maat, laitteet ja liikenteen lähteet.
- Etsi URL-ryhmät, joiden kenttädata on heikkoa.
- Tallenna toistettava laboratoriotallenne edustavalta sivulta.
Yksi nopea etusivu ei tarkoita, että verkkosivusto olisi nopea. Yksi hidas käynti vanhalla puhelimella ei tarkoita, että koko järjestelmä pitäisi kirjoittaa uudelleen.
Toimenpiteet, joilla on yleensä suurin vaikutus
1. Palvelin ja HTML
Mittaa aika ensimmäiseen tavuun ja jaa se DNS:ään, yhteyteen, palvelimen odotukseen ja uudelleenohjauksiin. Pitkät odotusajat voivat johtua palveluntarjoajasta, tietokannasta, välimuistittamattomasta sivusta, hitaasta API:sta tai uudelleenohjausketjuista. Ota julkiselle sisällölle sopiva sivuvälimuisti ja tarvittaessa objektivälimuisti käyttöön. Rajaa kirjautuneet käyttäjät, ostoskorit ja personointi asianmukaisesti välimuistin ulkopuolelle.
2. Pääkuva
LCP on usein pääkuva. Toimita sen näyttökokoa vastaava versio, käytä srcset-määritettä, pakkausta ja nykyaikaista WebP- tai AVIF-muotoa järkevällä varamuodolla. Älä lataa pääkuvaa laiskasti; käytä lazy loadingia ensimmäisen näkymän alapuolisille kuville. Aseta kuvan leveys ja korkeus, jotta selain varaa sille tilan ja CLS pysyy pienenä.
3. CSS ja fontit
Poista käyttämättömät tyylit varovasti ja pidä kriittinen CSS pienenä. Rajoita fontit tarvittaviin leikkauksiin ja merkistöihin, välimuistita paikalliset tiedostot pitkäksi aikaa ja esilataa vain aidosti aikaisin tarvittava fontti. Kymmenen fontin esilataaminen luo vain uuden jonon.
4. JavaScript ja vuorovaikutus
Jaa suuret paketit osiin, siirrä ei-kriittinen koodi myöhemmäksi ja lataa kolmansien osapuolten sisältöä vain tarvittaessa ja suostumuksen salliessa. async ja defer eivät ole taikakeinoja; testaa skriptien järjestys ja riippuvuudet. Pilko pitkät pääsäikeen tehtävät äläkä laita klikkausta odottamaan analytiikkaa.
5. Kolmannet osapuolet
Chatit, lämpökartat, mainospikselit, videot ja A/B-työkalut lisäävät verkkopyyntöjä ja prosessorin kuormaa. Jokaisella skriptillä on oltava omistaja ja liiketoiminnallinen syy. Älä lataa sitä synkronisesti ylätunnisteessa vain siksi, että asennusohje on lyhin. Analytiikkaa voi hallita Google Tag Managerin kautta, mutta säilö itsessään ei pelasta suorituskykyä.
WordPress: vähemmän kerroksia, enemmän hallintaa
WordPressin dokumentaatio suosittelee suorituskyvyn parantamista palveluntarjoajan, lisäosien määrän ja laadun, kuvien, välimuistin ja jakeluverkon kautta. Lue sen optimointiyleiskatsaus ja erillinen välimuistin selitys.
- Päivitä WordPress, PHP, teema ja lisäosat ensin testiympäristössä.
- Poista käyttämättömät lisäosat sekä päällekkäiset välimuisti- ja minifiointityökalut.
- Profiloi tietokantakyselyt ja hitaat ulkoiset kutsut.
- Suunnittele tietokannan ylläpito, mutta älä poista versioita tai metatietoja sokeasti.
- Testaa jokaisen optimoinnin jälkeen lomakkeet, haku, kirjautuminen ja ostopolku.
Keskustelen järkevästä lisäosien valinnasta artikkelissa parhaat WordPress-lisäosat.
Mitä ei pidä tehdä
- Älä lataa muiden analytiikka- tai mainosskriptejä omalle palvelimellesi vain tuloksen vuoksi; voit menettää tietoturva- ja toiminnallisuuspäivitykset.
- Älä aseta muuttuville tiedostoille vuoden mittaista välimuistia ilman nimen versiointia.
- Älä poista CSS:ää tai JavaScriptiä automaattisen raportin perusteella testaamatta jokaista sivupohjaa.
- Älä arvioi onnistumista vain Lighthousen perusteella. Google sanoo suoraan, etteivät hyvät Core Web Vitals -tulokset yksin takaa korkeita sijoituksia tai erinomaista käyttökokemusta.
- Älä nopeuta verkkosivustoa piilottamalla asiakkaan tarvitsemaa sisältöä tai toimintoa.
Neljän viikon suunnitelma
- Viikko 1: kenttädatan lähtötaso, laboratoriomittaukset ja sivupohjaluettelo.
- Viikko 2: palvelin, välimuisti, uudelleenohjaukset ja suurimmat LCP-resurssit.
- Viikko 3: kuvat, fontit, CSS, JavaScript ja kolmannet osapuolet.
- Viikko 4: regressiotesti, uudet mittaukset, seuranta ja dokumentointi.
Kirjaa jokaisesta muutoksesta päivämäärä, URL, mittari ennen ja jälkeen, toiminnallinen vaikutus sekä palautusvaihtoehto. Seuraa myös konversioastetta, lomakkeiden täyttämistä ja virheitä; nopeampi sivu, joka myy vähemmän, ei ole valmis optimointi.
Aloita tarkistamalla verkkosivuston tekninen perusta ja analytiikka teknisessä auditoinnissa ja GA4. Jos sinun on priorisoitava korjaukset vaikutuksen ja kustannusten perusteella, ota yhteyttä yhteydenottosivun kautta.