Verkkosivun nopeuttaminen: käytännön tarkistuslista

Verkkosivua nopeutetaan mittaamalla ensin PageSpeed Insightsilla ja korjaamalla sitten suurin syy, jonka se osoittaa — yleensä liian suuret kuvat, liikaa JavaScriptiä, raskaat fontit tai kolmannen osapuolen skriptit. Tavoittele Googlen Core Web Vitals -mittareiden ”hyvä”-tasoja: pääsisältö näkyy 2,5 sekunnissa, napautuksiin vastataan 200 millisekunnissa ja sivu ei hyppi juuri lainkaan. Useimmat sivustot pääsevät tähän muutamalla muutoksella, ei uudelleenkirjoituksella.

Mittaa ennen kuin muutat mitään

Arvaaminen vie aikaa hukkaan. Kaksi ilmaista työkalua riittää lähes kaikille:

• PageSpeed Insights (pagespeed.web.dev) — liitä live-osoite. Se näyttää kenttädataa todellisilta Chrome-käyttäjiltä (jos sivustolla on tarpeeksi liikennettä) ja labradataa simuloidulta lataukselta sekä listan konkreettisista ongelmista.
• Lighthouse Chromen DevTools-työkaluissa — sama labratesti millä tahansa sivulla, jonka voit avata, myös esikatselussa. Testaa mobiilitilassa; hitaammilla verkoilla olevat puhelimet ovat paikka, jossa ongelmat näkyvät.

Luvut, jotka ratkaisevat, ovat Googlen Core Web Vitals -mittareita. Syyskuusta 2026 lähtien Googlen web.dev-dokumentaatio antaa näille ”hyvä”-rajat, mitattuna sivunlatausten 75. persentiilistä:

INP korvasi vanhemman First Input Delay -mittarin vuonna 2024. Jos jokin työkalu raportoi yhä FID:n, se on vanhentunut.

Kirjaa lähtölukemasi ylös. Testaa jokaisen korjauksen jälkeen uudelleen, jotta tiedät, mikä auttoi.

Missä aika kuluu: vaihtoehdot ja kompromissit

Jokaisella yleisellä syyllä on korjaus, ja jokaisella korjauksella on hintansa. Aloita yläreunasta — ne ovat halvimpia ja yleisimpiä.

Kuvat

Kuvat ovat yleisin ongelma ja helpoin korjata. 4000 pikselin valokuva, joka näytetään 800 pikselin leveänä, pakottaa jokaisen kävijän lataamaan viisi kertaa enemmän kuin hän näkee.

• Tarjoa kuvat siinä koossa, jossa ne näytetään, responsiivisilla srcset-koilla puhelimille ja työpöydille.
• Käytä moderneja muotoja (WebP tai AVIF) ja järkevää pakkausta.
• Aseta width ja height jokaiseen kuvaan, jotta selain varaa tilan. Tämä yksin korjaa suurimman osan asettelun hypyistä.
• Lataa taitteen alapuolella olevat kuvat laiskasti attribuutilla loading="lazy".
• Älä lataa laiskasti sivun yläosan pääkuvaa. Googlen LCP-ohjeet ovat tässä suoria: pääkuvan laiska lataus viivästyttää sitä aina. Anna sille fetchpriority="high".

JavaScript

Monet tekoälyllä rakennetut sivustot ovat yksisivuisia sovelluksia (SPA): selain lataa JavaScript-paketin ja piirtää sitten sivun. Mitä suurempi paketti, sitä pidempi tyhjä ruutu. Korjaukset järjestyksessä vaivan mukaan:

1. Poista se, mitä et käytä. Pyydä lista riippuvuuksista ja leikkaa kirjastot, jotka lisättiin kerran ja unohdettiin — päivämäärikirjasto yhtä päivämäärää varten tai koko kuvakekirjasto viittä kuvaketta varten.
2. Jaa reiteittäin. Lataa hallintanäkymän koodi vasta, kun joku avaa sen, ei etusivulla.
3. Esirenderöi julkiset sivut. Markkinointisivu, joka toimitetaan oikeana HTML:nä, näkyy ennen kuin mitään JavaScriptiä ajetaan. Tämä auttaa myös hakukoneita; katso hakukoneoptimointi tekoälyllä rakennetuille verkkosivuille.

Hidas INP johtuu yleensä yhdestä pitkästä tehtävästä, joka blokkaa sivun — esimerkiksi valtavan listan suodattamisesta jokaisella näppäinpainalluksella tai koko taulukon uudelleenrenderöimisestä, kun yksi solu muuttuu. Chromen DevTools-työkalun Performance-paneeli näyttää, mikä se on.

Fontit

Jokainen fonttiperhe ja paino on lisätiedosto. Kaksi perhettä ja kolme tai neljä painoa riittää yleensä. Esilataa taitteen yläpuolella käytetty fontti, käytä font-display: swap-asetusta, jotta teksti näkyy heti, ja isännöi fontit itse, jos ulkoinen fonttipalvelu on hidas kävijöillesi.

Kolmannen osapuolen skriptit

Chat-widgetit, analytiikka, lämpökartat, mainospikselit, upotetut videot ja sosiaalisen median syötteet lataavat koodia muilta palvelimilta. Jokainen näyttää pieneltä; yhdessä ne ovat usein sivun hitain osa. Pidä ne, joita oikeasti katsot. Lataa loput sen jälkeen, kun sivu on vuorovaikutteinen, ja korvaa raskaat upotukset (YouTube-soitin, kartta) kevyellä esikatselulla, joka lataa oikean sisällön napsautuksesta.

Palvelimen vaste

Time to first byte (TTFB) — kuinka kauan palvelin kestää aloittaa vastaus — on kaikkien muiden mittareiden pohjalla. Staattiset sivut, jotka tarjoillaan CDN:stä (verkko palvelimia lähellä kävijöitäsi; katso mikä on CDN), ovat nopeita lähes kaikkialla. Sivut, joita palvelin rakentaa jokaisella pyynnöllä, riippuvat siitä palvelimesta ja sen tietokannasta. Välimuisti toistuvalle työlle ja tietokantaindeksit hitaille kyselyille ovat tavalliset korjaukset.

Kehotteet, jotka toimivat

Ole tarkka: nimeä sivu, mittari ja rajoite. Liitä PageSpeed Insights -löydökset, jos sinulla on ne.

PageSpeed Insights raportoi etusivun LCP:ksi 4,8 s mobiilissa, ja LCP-elementti on hero-kuva. Muuta hero-kuva WebP-muotoon ja pienennä se, tarjoa responsiiviset koot, aseta width ja height, anna sille fetchpriority="high" ja varmista, ettei sitä ladata laiskasti. Lataa laiskasti jokainen taitteen alapuolella oleva kuva. Älä muuta suunnittelua.

Tarkista tämän sovelluksen riippuvuudet. Listaa jokainen paketti, mitä se käyttää ja suunnilleen kuinka paljon se lisää pakettiin. Poista käyttämättömät ja jaa reitit /admin ja /settings erillisiin osiin, jotka latautuvat vasta vierailtaessa.

/products-sivun hakukenttä tuntuu hitaalta. Viivästytä suodatusta, vältä koko listan uudelleenrenderöintiä jokaisella näppäinpainalluksella ja sivuta tai virtualisoi lista, jos siinä on yli 200 kohdetta.

Askel askeleelta

1. Testaa live-sivu PageSpeed Insightsissa mobiilina. Kirjaa LCP, INP ja CLS sekä listatut kolme suurinta ongelmaa.
2. Korjaa kuvat ensin: koot, muodot, mitat, laiska lataus taitteen alapuolella, prioriteetti hero-kuvalle.
3. Leikkaa kolmannen osapuolen skriptit, joita et käytä, ja lykkää loput.
4. Karsi fontit siihen, mitä suunnittelu tarvitsee.
5. Pienennä JavaScriptiä: poista käyttämättömät paketit ja jaa reittien mukaan.
6. Esirenderöi julkiset sivut, jos ne ovat yhä asiakaspuolella renderöityjä ja LCP on yhä hidas.
7. Tarkista palvelin: välimuisti, tietokantaindeksit, staattinen isännöinti sisällölle, joka harvoin muuttuu.
8. Julkaise uudelleen ja testaa. Kenttädata PageSpeed Insightsissa päivittyy seuraavien viikkojen aikana, kun todellisia käyntejä kertyy, joten arvioi varhaiset tulokset labradatan perusteella.

Yleisiä virheitä

• Testaus vain nopealla kannettavalla. Kävijäsi ovat keskihintaisilla puhelimilla ja epävakaalla mobiilidatalla. Testaa mobiilitilassa.
• Täydellisen 100 pisteen tavoittelu. Labrapistemäärä on ohjenuora. Kun Core Web Vitals ovat hyvällä alueella, sisältö ja käytettävyys ovat tärkeämpiä kuin viimeiset pisteet.
• Kaiken lataaminen laiskasti, pääkuva mukaan lukien. Se heikentää LCP:tä.
• Nopeuslisäosan tai kirjaston lisääminen päälle. Painon poistaminen voittaa lähes aina koodin lisäämisen sen hallitsemiseksi.
• Esikatselun optimoiminen, ei live-sivun. Kehitysesikatselut ajavat optimoimattomia buildeja. Mittaa julkaistu osoite.
• Nopeuden korjaaminen kerran. Jokainen uusi widget, kuva ja ominaisuus lisää painoa. Testaa uudelleen suurten muutosten jälkeen.

Nopeuden tarkistuslista

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 mobiilissa
• Kuvat pienennetty, pakattu, modernissa muodossa, mitoilla varustettuna
• Pääkuvaa ei ladata laiskasti; taitteen alapuolella olevat kuvat ladataan laiskasti
• Ei käyttämättömiä JavaScript-kirjastoja; raskaat reitit eroteltu
• Kaksi fonttiperhettä tai vähemmän, pääfontti esilatautuu
• Vain käyttämäsi kolmannen osapuolen skriptit, ladattuna myöhään
• Julkiset sivut esirenderöity tai staattisia, missä mahdollista
• Testattu uudelleen julkaistulla osoitteella julkaisun jälkeen

Nopeus ja mobiiliasettelu kulkevat käsi kädessä; katso miten tehdä verkkosivusta mobiilisopiva. Kattavaa julkaisua edeltävää tarkistusta varten miten viedä AI-prototyyppi tuotantoon käy läpi loput.

Nopeus Mythexissä

Mythexissä teet nämä muutokset pyytämällä chatissa tai Prolla koodieditorissa. Tarkista julkaistu osoite, älä esikatselua, koska esikatselu ajaa kehityspalvelinta. Staattiset käyttöliittymät julkaistaan staattisina sivustoina (staattiset verkkosivut), mikä sopii sisältösivuille. Palvelinta käyttävät sovellukset skaalautuvat nollaan: ne nukkuvat tyhjäkäynnillä ja herävät seuraavalla käynnillä, joten ensimmäinen pyyntö hiljaisen jakson jälkeen on hitaampi, ja liitetty tietokanta nukkuu 5 minuutin tyhjäkäynnin jälkeen (isännöinnin rajat). Jos julkinen sivu on hidas vain ensimmäisellä käynnillä, syy on todennäköisesti tämä. Markkinointisivujen pitäminen staattisina auttaa. Muutosten jälkeen julkaise uudelleen ja tee kova päivitys selaimessa.

Kysymykset