Verkkosivun nopeus: miksi se ratkaisee ja miten sitä mitataan

Nopeus on yksi harvoista verkkosivun ominaisuuksista, jota voi mitata numerona ja jonka vaikutus näkyy sekä käyttäjän kokemuksessa että hakukonenäkyvyydessä. Silti se on yleensä viimeinen asia, jota projektissa katsotaan.

Olen tehnyt verkkosivu- ja SEO-työtä yli 12 vuotta ja yli 200 projektissa. Valtaosassa hitaista sivustoista ongelma ei ole palvelin eikä alusta, vaan se että kukaan ei ole koskaan mitannut mitään.

TL;DR

Verkkosivun nopeus mitataan Core Web Vitals -mittareilla: LCP alle 2,5 sekuntia, CLS alle 0,1 ja INP alle 200 millisekuntia. Google arvioi arvot todellisten käyttäjien 75. persentiilistä, ei yksittäisestä testiajosta. Yleisimmät hidasteet ovat optimoimattomat kuvat, ulkopuoliset seurantaskriptit ja raskas alusta. Korjaa ne siinä järjestyksessä, missä säästö on suurin suhteessa työmäärään, ja mittaa jokaisen muutoksen jälkeen uudelleen.

Mitä verkkosivun nopeus tarkoittaa käytännössä?

Verkkosivun nopeus tarkoittaa aikaa, joka kuluu siitä kun käyttäjä klikkaa linkkiä siihen kun hän näkee etsimänsä sisällön ja voi käyttää sitä. Se ei ole yksi luku vaan ketju: palvelimen vasteaika, tiedostojen lataus, selaimen piirtotyö ja lopulta hetki, jolloin sivu reagoi klikkaukseen. Ketju on juuri niin nopea kuin sen hitain lenkki.

Käytännön työssä nopeus kannattaa jakaa kolmeen kysymykseen, joihin vastataan eri keinoilla:

• Milloin sisältö näkyy? Tähän vaikuttavat palvelinvaste, sivun kuvat ja se, estääkö jokin tiedosto piirtämisen. Mittarina LCP.
• Pysyykö sisältö paikallaan? Kun kuva tai mainos latautuu jälkikäteen ilman varattua tilaa, teksti hyppää alaspäin. Mittarina CLS.
• Reagoiko sivu? Sivu voi näyttää valmiilta mutta jumittaa, koska selain suorittaa yhä JavaScriptiä. Mittarina INP.

Nämä kolme ovat toisistaan riippumattomia. Sivusto voi piirtyä sekunnissa ja silti tuntua rikkinäiseltä, jos valikko ei avaudu ensimmäisellä klikkauksella tai jos evästebanneri siirtää koko sisällön alaspäin sekunnin kuluttua.

Käytännön ero näkyy siinä, kenen laitteella mitataan. Toimiston valokuituyhteydellä ja uudella työpöytäkoneella lähes jokainen sivusto on nopea, mutta vanhemmalla puhelimella mobiiliverkossa sama sivusto voi olla moninkertaisesti hitaampi — JavaScriptin suoritus riippuu laitteen suorittimesta eikä pelkästä yhteysnopeudesta. Tästä syystä nopeus koetaan usein sisäisesti hyväksi ja mitataan silti huonoksi.

Pelkkä latausajan seuraaminen antaa siis harhaisen kuvan siitä, miten sivusto toimii.

Miksi nopeus vaikuttaa sekä myyntiin että hakukonenäkyvyyteen?

Nopeus vaikuttaa myyntiin, koska jokainen odotettu sekunti on kohta, jossa käyttäjä voi palata hakutuloksiin. Se vaikuttaa hakukonenäkyvyyteen, koska Google käyttää Core Web Vitals -arvoja osana sivukokemuksen arviointia. Kumpikin vaikutus on todellinen, mutta kumpikaan ei ole yksinään ratkaiseva — sisältö ja relevanssi painavat enemmän.

Kolme mekanismia, joiden kautta hitaus maksaa:

• Poistuminen ennen sisältöä. Käyttäjä ei arvioi sivustoa, jota hän ei ole nähnyt. Mobiiliverkossa ero hyvän ja huonon LCP:n välillä on käytännössä ero sen välillä, näkeekö käyttäjä otsikon vai valkoisen ruudun.
• Keskeytynyt toiminto. Lomake tai ostoskori, joka ei reagoi 500 millisekunnissa, tulkitaan rikkinäiseksi. INP-raja huono-luokalle on juuri tuo 500 ms.
• Ranking-signaali. Kun kaksi sivua vastaa hakuun yhtä hyvin, sivukokemus on erotteleva tekijä. Tämä on osa laajempaa kokonaisuutta, joka käydään läpi artikkelissa mitä on hakukoneoptimointi.

Nopeus ei nosta huonoa sivua hyvän ohi. Se ratkaisee tilanteet, joissa sivut ovat muuten tasoissa — ja niitä tilanteita on paljon.

Nopeus kannattaa siis nähdä perustason vaatimuksena eikä kilpailuetuna. Se ei tuo asiakkaita, mutta hitaus vie niitä.

Mitkä ovat Core Web Vitals -mittarit?

Core Web Vitals on Googlen kolmen mittarin kokonaisuus, joka kuvaa sivun latautumista, visuaalista vakautta ja vasteaikaa. Jokaisella on julkaistu raja-arvo, joka jakaa tuloksen kolmeen luokkaan. Arvot mitataan oikeiden käyttäjien istunnoista, ja arviointi tehdään 75. persentiilillä eli kolmen neljäsosan käyttäjistä on ylitettävä raja.

Mittari	Mitä mittaa	Hyvä	Vaatii parannusta	Huono
LCP	Suurimman sisältöelementin piirtoaika	alle 2,5 s	2,5–4,0 s	yli 4,0 s
CLS	Sisällön hyppiminen latauksen aikana	alle 0,1	0,1–0,25	yli 0,25
INP	Vasteaika käyttäjän toimintoon	alle 200 ms	200–500 ms	yli 500 ms

Kolme asiaa, jotka taulukosta on syytä ymmärtää:

• INP korvasi FID:n maaliskuussa 2024. Vanha FID mittasi vain ensimmäisen vuorovaikutuksen viivettä. INP katsoo koko istunnon vuorovaikutuksia, joten se on huomattavasti tiukempi mittari raskaalle JavaScriptille.
• 75. persentiili on olennainen. Keskiarvo piilottaa hitaat istunnot. Persentiili ei piilota.
• Mobiili ja desktop arvioidaan erikseen. Sivusto voi olla hyvällä tasolla työpöydällä ja huonolla mobiilissa, ja mobiili on useimmilla toimialoilla se, joka ratkaisee.

Raja-arvot ovat julkisia ja pysyviä, joten ne kelpaavat tavoitteeksi myös toimittajan kanssa tehtävään sopimukseen.

Miten nopeutta mitataan oikein?

Nopeutta mitataan kahdella eri datalla, joita ei saa sekoittaa: laboratoriodatalla ja kenttädatalla. Laboratoriodata syntyy simuloidusta testiajosta vakioidussa ympäristössä ja kertoo, mikä sivulla on teknisesti pielessä. Kenttädata kertyy oikeiden käyttäjien selaimista ja kertoo, mikä on todellinen tilanne. Päätökset tehdään kenttädatan perusteella, korjaukset laboratoriodatan avulla.

Käytännön mittausjärjestys, jota kannattaa noudattaa:

• PageSpeed Insights. Näyttää samalla sivulla molemmat: ylhäällä kenttädata CrUX-tietokannasta, alhaalla Lighthousen laboratoriotesti. Aloita aina ylimmästä osiosta.
• Search Consolen Core Web Vitals -raportti. Ryhmittelee koko sivuston URL-osoitteet samankaltaisiin joukkoihin. Tämä paljastaa, onko ongelma yksittäisellä sivulla vai koko sivupohjassa.
• Chrome DevToolsin Performance-välilehti. Käytetään vasta, kun tiedetään mikä sivu on hidas ja halutaan nähdä mikä yksittäinen tiedosto sen aiheuttaa.
• Screaming Frog. Ilmaisversio indeksoi 500 URL-osoitetta ja löytää suurikokoiset kuvat ja ohjausketjut koko sivustolta kerralla.

Yksi testiajo ei ole mittaus. Aja sama testi kolme kertaa ja katso mediaania — Lighthousen tulos heittelee itsestään useita pisteitä.

Mittaa aina samalla tavalla ennen ja jälkeen korjauksen, muuten et tiedä kumpi muutos vaikutti.

Mikä hidastaa sivustoa yleisimmin?

Sivustoja hidastavat käytännössä samat viisi asiaa lähes joka projektissa: kuvat, kolmannen osapuolen skriptit, fontit, palvelinvaste ja lisäosien määrä. Järjestys vaihtelee, mutta kuvat ovat useimmiten ensimmäisenä ja ne on myös halvin korjata.

Yleisimmät syyt siinä järjestyksessä, jossa ne kannattaa tarkistaa:

• Kuvat väärässä koossa. Kameran tuottama kuva ladataan sellaisenaan ja skaalataan selaimessa pieneksi. Selain lataa silti koko tiedoston.
• Kolmannen osapuolen skriptit. Analytiikka, mainospikselit, chat-widgetit, upotetut videot ja karttapalvelut. Jokainen tuo mukanaan oman verkkoyhteytensä ja oman JavaScriptinsä, jota et hallitse.
• Fontit. Useita fonttiperheitä, useita leikkauksia ja lataus ulkopuoliselta palvelimelta lisää sekä siirtoaikaa että piirtoviivettä.
• Palvelinvaste. Jos palvelin vastaa vasta 800 millisekunnin jälkeen, hyväkään etupää ei pelasta LCP-arvoa. Tämä on yleistä halvoissa jaetuissa palvelinpaketeissa.
• Lisäosat. Jokainen lisäosa lataa usein oman tyylitiedostonsa ja skriptinsä joka sivulle, myös niille sivuille joilla sitä ei käytetä. Sama vaikutus näkyy myös ylläpidon työmäärässä.

Nämä viisi selittävät valtaosan hitaudesta. Eksoottisempien syiden etsiminen ennen näiden korjaamista on ajanhukkaa.

Miten kuvat optimoidaan?

Kuvat optimoidaan neljällä toimenpiteellä: oikea tiedostomuoto, oikea pikselikoko, latauksen viivästys ruudun ulkopuolisille kuville ja kiinteät mitat asettelun vakauttamiseksi. Näillä neljällä ratkeaa useimmissa yritysten sivustoissa suurin osa LCP-ongelmasta ilman että alustaan kosketaan.

Toimenpiteet järjestyksessä:

• Käytä WebP-muotoa. WebP on tyypillisesti noin 25–35 prosenttia pienempi kuin vastaavan laatuinen JPEG. Kaikki nykyselaimet tukevat sitä.
• Skaalaa kuva näyttökokoon. Jos kuva näkyy 800 pikselin levyisenä, älä lataa 4000 pikselin tiedostoa. Tarjoile eri koot srcset-määrityksellä.
• Käytä lazy loadingia — mutta ei kaikkeen. loading="lazy" sopii ruudun alapuolisiin kuviin. Älä koskaan laita sitä hero-kuvaan, koska se on yleensä juuri se LCP-elementti jota mitataan.
• Määritä width ja height. Kun selain tietää kuvan mittasuhteen etukäteen, se varaa tilan valmiiksi eikä sisältö hyppää. Tämä on suoraviivaisin tapa saada CLS alle 0,1.

Löydä korjattavat kuvat kerralla indeksoimalla sivusto Screaming Frogilla, jonka ilmaisversio kattaa 500 URL-osoitetta, ja järjestämällä kuvat tiedostokoon mukaan laskevasti. Lista alkaa lähes aina samasta paikasta: hero-kuva, referenssigalleria ja artikkelien nostokuvat.

Jos vain yhteen asiaan on aikaa, se on etusivun hero-kuva. Se on useimmiten sekä LCP-elementti että sivuston suurin yksittäinen tiedosto.

Varmista korjaus mittaamalla sama sivu ennen ja jälkeen: laboratorio-osio näyttää muutoksen heti, kenttädata vasta seuraavan mittausjakson jälkeen. Kuvien optimointi on työmäärältään pieni ja vaikutukseltaan suurin yksittäinen toimenpide, minkä takia se tehdään ensin.

Miten fontit vaikuttavat nopeuteen?

Fontit vaikuttavat nopeuteen kahdella tavalla: ne lisäävät ladattavan datan määrää ja ne voivat estää tekstin näkymisen kunnes fonttitiedosto on ladattu. Jälkimmäinen on vakavampi, koska se siirtää suoraan LCP-hetkeä — teksti on monilla sivuilla juuri se suurin sisältöelementti.

Neljä korjausta, jotka kannattaa tehdä kerralla:

• Isännöi fontit itse. Ulkopuoliselta palvelimelta ladattu fontti vaatii uuden yhteydenmuodostuksen ennen kuin tiedostoa edes pyydetään. Oma palvelin poistaa tämän välivaiheen.
• Käytä font-display: swap -määritystä. Selain piirtää tekstin heti varafontilla ja vaihtaa oikean tilalle sen latauduttua. Teksti näkyy odottamisen sijaan.
• Lataa vain käytetyt leikkaukset. Kolme paksuutta riittää lähes aina. Jokainen ylimääräinen leikkaus on oma tiedostonsa.
• Preloadaa se fontti, jota käytetään ensimmäisenä. Yksi preload-määritys otsikkofontille riittää; kaikkien esilataaminen kumoaa hyödyn.

Fonttien osuuden näkee helpoiten DevToolsin Network-välilehdeltä suodattamalla näkymän fonttitiedostoihin. Jos rivejä on kuusi tai enemmän, teema lataa todennäköisesti leikkauksia joita mikään tyylimäärittely ei käytä. Sama tilanne syntyy usein huomaamatta, kun sivustolle asennetaan sivunrakennin tai lisäosa, joka tuo mukanaan oman fonttinsa.

Valitse varafontti, joka on mitoiltaan lähellä oikeaa fonttia, niin swap-hetken hyppy jää pieneksi eikä CLS-arvo kärsi tekstin vaihtumisesta.

Kuinka paljon kolmannen osapuolen skriptit maksavat nopeudessa?

Kolmannen osapuolen skriptit ovat tyypillisesti suurin yksittäinen syy huonoon INP-arvoon, koska ne suorittavat JavaScriptiä pääsäikeessä samaan aikaan kun käyttäjä yrittää käyttää sivua. Ne ovat myös ainoa hidaste, jota et voi optimoida — voit vain päättää, ladataanko ne vai ei.

Näin niiden kanssa toimitaan:

• Inventoi ensin. Listaa kaikki ulkopuoliset skriptit ja merkitse jokaisen kohdalle, kuka niitä käyttää ja mihin päätökseen niiden data vaikuttaa. Käytännössä osalla ei ole omistajaa lainkaan.
• Poista vanhat seurantakoodit. Päättyneiden kampanjoiden pikselit jäävät sivustolle vuosiksi ja latautuvat joka käynnillä.
• Lataa raskaat upotukset vasta klikkauksesta. Upotettu video tai kartta korvataan staattisella kuvalla, joka vaihtuu oikeaksi upotukseksi vasta kun käyttäjä sitä pyytää.
• Lykkää se, mitä ei tarvita heti. Chat-widget ja arviointipalvelun upotus voidaan ladata vasta sivun tultua käyttökuntoon.

Vaikutuksen voi todentaa ennen kuin mitään poistetaan: DevToolsin Network-välilehdellä ulkopuoliset pyynnöt voi estää yksitellen ja ajaa saman mittauksen uudelleen. Näin näkee, mikä skripti vastaa mistäkin osuudesta, eikä keskustelu jää arvailun varaan.

Sivustolla, jota ei ole siivottu vuosiin, ulkopuolisia skriptejä on tyypillisesti enemmän kuin kukaan organisaatiossa osaa nimetä.

Skriptien karsiminen on organisatorinen päätös eikä tekninen, ja siksi se on usein hitain korjaus toteuttaa. Käytännössä se kannattaa kytkeä osaksi säännöllistä ylläpitorutiinia, jossa skriptilista tarkistetaan kerran vuodessa.

Miten nopeus korjataan käytännössä?

Nopeus korjataan mittaamalla ensin, korjaamalla suurimmat hidasteet järjestyksessä ja mittaamalla uudelleen jokaisen muutoksen jälkeen. Ilman järjestystä syntyy tilanne, jossa tehdään paljon pieniä optimointeja ja pistemäärä liikkuu satunnaisesti ilman että kukaan tietää mikä vaikutti.

Toimiva järjestys yrityssivustolle:

1. Mittaa lähtötaso. Kenttädata PageSpeed Insightsista ja Search Consolesta, kolme sivutyyppiä: etusivu, palvelusivu, blogiartikkeli.
2. Korjaa kuvat. WebP, oikea koko, width ja height. Halvin työ ja suurin vaikutus.
3. Karsi skriptit. Poista käyttämätön, lykkää ei-kriittinen, korvaa raskaat upotukset.
4. Siivoa fontit ja tyylit. Itse isännöity fontti, rajattu määrä leikkauksia, turhien lisäosatyylien poisto.
5. Tarkista palvelin. Jos palvelinvaste on yhä hidas tyhjällä sivulla, ongelma on hosting-tasolla eikä sisällössä.
6. Mittaa uudelleen 28 päivän kuluttua. CrUX-data on liukuva keskiarvo, joten kenttädata ei päivity heti muutoksen jälkeen.

Tee vaiheet yksi kerrallaan ja kirjaa jokaisen kohdalle mitatut arvot ennen ja jälkeen. Muuten korjauksista jää jäljelle vain tuntuma siitä, että sivusto tuntuu nopeammalta.

Tämä sama vaiheistus kannattaa kirjata jo projektin määrittelyyn, kun yrityksen verkkosivuja rakennetaan — jälkikäteen tehtynä sama työ maksaa enemmän kuin kerralla oikein tehtynä, mikä näkyy myös kokonaishinnassa.

Riittääkö hyvä pistemäärä PageSpeed Insightsissa?

Ei riitä. Pistemäärä on Lighthousen laboratoriotestin painotettu yhteenveto simuloidussa ympäristössä, ei mittaus todellisista käyttäjistä. Sivu voi saada korkean pistemäärän ja silti epäonnistua Core Web Vitals -arvioinnissa, koska oikeat käyttäjät käyttävät hitaampia laitteita, heikompia yhteyksiä ja klikkaavat asioita joita testiajo ei klikkaa.

Kolme syytä, miksi pistemäärään ei kannata tuijottaa:

• Se heittelee. Peräkkäiset ajot samalle sivulle antavat eri tuloksia, koska simulaatio ei ole täysin deterministinen.
• Se ei mittaa INP:tä. Laboratoriotesti ei voi mitata vasteaikaa käyttäjän toimintoihin, koska testissä ei ole käyttäjää. INP saadaan vain kenttädatasta.
• Se palkitsee optimoinnista testiä varten. Sivun voi virittää testiä varten tavalla, joka ei paranna todellista kokemusta lainkaan.

Käytä pistemäärää diagnoosityökaluna ja kenttädataa arvosanana. Ne vastaavat eri kysymykseen.

Pistemäärä on silti hyödyllinen kahdessa tilanteessa. Ensinnäkin se paikantaa ongelman: raportin Diagnostics-osio nimeää yksittäiset tiedostot ja kertoo, mikä elementti oli LCP-elementti. Toiseksi se kertoo nopeasti, meniko korjaus oikeaan suuntaan, kun kenttädata päivittyy vasta viiveellä. Kumpaakaan ei kannata sekoittaa arvosanaan.

Oikea tavoite on, että kolme neljästä oikeasta käyttäjästä pysyy raja-arvojen sisällä — ei se, että testityökalu näyttää vihreää.

Usein kysytyt kysymykset

Mikä on riittävän nopea verkkosivu?

Googlen raja-arvojen mukaan LCP on hyvällä tasolla alle 2,5 sekunnissa, CLS alle 0,1 ja INP alle 200 millisekunnissa. Rajat mitataan todellisten käyttäjien istunnoista 75. persentiilillä, eli kolmen neljästä käyntikerrasta on jäätävä rajan alle. Yksittäinen nopea testiajo omalla koneella ei siis riitä todisteeksi, koska oikeat käyttäjät saapuvat hitaammilla laitteilla ja heikommilla yhteyksillä. Tarkista arvot erikseen mobiilille ja työpöydälle, ja mittaa vähintään kolme sivutyyppiä: etusivu, palvelusivu ja artikkeli. Ne käyttäytyvät lähes aina eri tavalla.

Mitä Core Web Vitals -mittarit ovat?

Core Web Vitals koostuu kolmesta mittarista. LCP eli Largest Contentful Paint mittaa, kuinka nopeasti sivun suurin sisältöelementti piirtyy; hyvä taso on alle 2,5 sekuntia. CLS eli Cumulative Layout Shift mittaa, kuinka paljon sisältö hyppii latautuessaan; hyvä taso on alle 0,1. INP eli Interaction to Next Paint mittaa vasteaikaa käyttäjän toimintoon; hyvä taso on alle 200 millisekuntia. INP korvasi FID-mittarin maaliskuussa 2024 ja on tiukempi, koska se huomioi koko istunnon vuorovaikutukset. Mittarit ovat toisistaan riippumattomia, joten jokainen tarkistetaan erikseen.

Onko PageSpeed Insightsin pistemäärä sama kuin nopeus?

Ei ole. Pistemäärä on Lighthousen laboratoriotestin painotettu yhteenveto simuloidussa ympäristössä, ei mittaus oikeista käyttäjistä. Sama sivu voi antaa eri pisteet peräkkäisillä ajoilla, joten aja testi kolme kertaa ja käytä mediaania. Laboratoriotesti ei myöskään mittaa INP-arvoa lainkaan, koska testissä ei ole käyttäjää joka klikkaisi. Pistemäärä kelpaa ongelmien paikantamiseen ja korjausten vertailuun, mutta lopullinen arvio tehdään kenttädatasta eli CrUX-raportista ja Search Consolen Core Web Vitals -raportista.

Mikä hidastaa verkkosivua yleisimmin?

Selvästi yleisin syy on optimoimattomat kuvat: alkuperäiskokoinen valokuva skaalataan selaimessa pieneksi, jolloin turha datamäärä ladataan silti. Toiseksi yleisin on kolmannen osapuolen skriptit, kuten seurantapikselit, chat-työkalut ja upotetut videot, jotka varaavat pääsäikeen aikaa ja heikentävät INP-arvoa. Kolmantena tulee raskas alusta: liikaa lisäosia, hidas palvelinvaste ja teema, joka lataa kaikki tyylitiedostot joka sivulla. Tarkista nämä kolme tässä järjestyksessä ennen kuin etsit harvinaisempia syitä — muuten työaika kuluu vääriin kohteisiin.

Kannattaako nopeus korjata vai rakentaa sivusto uudelleen?

Korjaaminen kannattaa aloittaa ensin, koska kuvien, fonttien ja skriptien optimointi ratkaisee suurimman osan ongelmista ilman uudelleenrakennusta ja vaikutus näkyy laboratoriomittauksessa heti. Uudelleenrakennus on perusteltu vasta, jos palvelinvaste on hidas jo tyhjällä sivulla, teema on rakenteellisesti raskas tai sivusto vaatisi joka tapauksessa uudistuksen muista syistä. Yleisin virhe on päättää uudelleenrakennuksesta ennen mittaamista, jolloin samat ongelmat siirtyvät uuteen toteutukseen sellaisenaan. Mittaa ensin, päätä sitten.

Yhteenveto

Verkkosivun nopeus on mitattava ominaisuus, jolla on julkiset raja-arvot: LCP alle 2,5 sekuntia, CLS alle 0,1 ja INP alle 200 millisekuntia, arvioituna todellisten käyttäjien 75. persentiilistä. Näihin päästään useimmiten ilman uudelleenrakennusta.

Työjärjestys on aina sama: mittaa kenttädata, korjaa kuvat, karsi ulkopuoliset skriptit, siivoa fontit, tarkista palvelinvaste ja mittaa uudelleen. Laboratoriotesti kertoo mikä on pielessä, kenttädata kertoo onko se korjattu.

Yleisin virhe on tehdä useita muutoksia kerralla ja katsoa tulosta vasta lopuksi. Silloin ei tiedetä mikä toimi eikä mitä kannattaisi toistaa muillakin sivutyypeillä. Toinen yleinen virhe on mitata vain etusivua, vaikka valtaosa hakuliikenteestä laskeutuu sisäsivuille — mittaa aina vähintään etusivu, yksi palvelusivu ja yksi artikkeli.

Nopeus ei myöskään ole kertaprojekti. Jokainen uusi lisäosa, seurantakoodi ja kuvagalleria siirtää arvoja huonompaan suuntaan, ellei niitä tarkisteta osana jatkuvaa ylläpitoa.

Nopeus on osa samaa kokonaisuutta kuin sivuston rakenne, sisältö ja jatkuva ylläpito. Käytännön kokonaiskuvan saa artikkelista verkkosivut yritykselle, ja tekninen toteutus kannattaa suunnitella yhdessä sen kanssa, kuka sivustoa ylläpitää julkaisun jälkeen. Näin näitä asioita ratkotaan käytännön projekteissa.