Mitä web-kehitys on?

Juttelin vähän aikaa sitten erään henkilön (akateeminen nuorimies) kanssa työstäni ja kerroin hänelle, että käytännössä teemme verkkosivustoja yrityksille. ”Eikös niitä webbisivuja rakenneta HTML-kielellä?”, kuului kysymys herralta varsin aikaisessa vaiheessa. Tämä onkin melko usein se, mitä moni mieltää web-kehityksen olevan: HTML-koodin kirjoittamista.

HTML-koodi on kuitenkin usein vain lopputulos, joka välitetään palvelimelta selaimelle. Hyvin usein kehittäjä ei ole kirjoittanut merkkiäkään varsinaista HTML:ää, vaan luonut jollakin ohjelmointikielellä tai työkalulla logiikan, jonka perusteella palvelin tuottaa selaimelle välitettävän HTML-dokumentin.

HTML-dokumentin kaverit

Yksinkertainen tapa lähteä miettimään sitä, miten sivusto on rakennettu, on purkaa osiin lopputulos, eli selvittää, mitä kaikkea selain tarvitsee varsinaisen sivun esittämiseksi kävijälle. Sivun voidaan ajatella koostuvan seuraavista osista:

1. HTML-dokumentti, joka määrittelee sivun rakenteen ja sisällön. Tämä dokumentti myös kertoo selaimelle, mitä muita tiedostoja sen pitää ladata verkon yli palvelimelta.
2. CSS-tyylitiedostot, jotka määrittelevät, miltä dokumentti ja sen elementit näyttävät. Tyylitiedostot voivat viitata tiedostoihin (muihin tyylitiedostoihin, kirjasimiin tai kuviin), jotka selaimen pitää myös ladata palvelimelta, jotta halutut tyylimäärittelyt voidaan ottaa käyttöön.
3. JavaScript-skriptitiedostot, jotka toteuttavat sivun esittämiseen tarvittavat interaktiot ja muut selainpäässä ajettavat toiminnallisuudet. JavaScript-tiedostot voivat mm. muokata alkuperäisen HTML-dokumentin rakennetta, joten ne voivat esimerkiksi lisätä avoinna olevaan HTML-dokumenttiin viittauksia muihin JavaScript- tai CSS-tiedostoihin.
4. Kuvat ja muut datatiedostot, joihin viitataan HTML-dokumentissa tai joissakin sen käyttämissä JS- tai CSS-tiedostoissa.

Kaiken pohjana on siis HTML-dokumentti, joka kertoo selaimelle sivun rakenteen ja viittaa muihin sivun tarvitsemiin tiedostoihin. Se, miten nämä kaikki HTML-, CSS- ja JavaScript-koodit tuotetaan, onkin varsin huikea sekamelska erilaisia teknisiä ratkaisuja.

Staattinen vs. dynaaminen

Sivustot voidaan karkeasti jaotella staattisiin ja dynaamisiin. Staattiset sivustot ovat toimintaperiaatteeltaan yksinkertaisempia, sillä ajatuksena on, että ne luodaan kertajulkaisuna ja tarjoillaan palvelimelta tämän jälkeen muuttumattomana seuraavaan julkaisukierrokseen asti. Dynaamisissa sivustoissa ajatuksena taas on, että näytettävät sivut luodaan esimerkiksi tietokannassa olevien tietojen pohjalta pyydettäessä. Tämä asettaa luonnollisestikin paljon enemmän vaatimuksia palvelimelle, mutta tarjoaa staattiseen sivustoon verrattuna huomattavasti joustavamman ympäristön sisällön tuottamiselle ja julkaisulle.

Vaikka staattiset sivustot ovatkin luonteeltaan jokaisen julkaisukierroksen jälkeen HTML-lähdekoodiltaan muuttumattomia, nekin syntyvät nykyään usein jonkin automatisoidun prosessin kautta. Käytännössä näissä prosesseissa yleensä käännetään sivuston varsinainen sisältö HTML-muotoon, upotetaan se osaksi sivupohjia ja rakennetaan navigaatiot ym. sisällön mukaan päivittyvät osat sivustosta. Näillä työnkuluilla julkaisuprosessiin voidaan rakentaa hyvinkin pitkälle vietyä automaatiota, eikä varsinaisessa sisällöntuotannossa silti välttämättä tarvita ollenkaan ohjelmointiosaamista. Pienten, sisällöltään kohtuullisen muuttumattomien sivustojen rakentaminen staattisena voikin olla perusteltua, sillä ne eivät pääsääntöisesti juurikaan aseta vaatimuksia palvelimelle eikä niiden kanssa tarvitse miettiä sovellustason tietoturvaa ja alustapäivityksiä.

Dynaamiset sivustot ovat perinteisesti rakentuneet jonkin sisällönhallintajärjestelmän (content management system, CMS) päälle. Sisällönhallintajärjestelmiä on lukemattomia määriä ja niissä jokaisessa on varmasti omat hyvät ja huonot puolensa. Sisällönhallintaa lukuunottamatta dynaamisten sivustojen taustajärjestelmän tehtävänä on pelkistetysti sanottuna päätellä, mitä sisältöä kävijä palvelimelta pyytää, rakentaa pyyntöä vastaava dokumentti ja lähettää se vastauksena selaimelle. Dokumentti ei tässä tapauksessa rajoitu pelkästään HTML-sivuun, vaan palvelin voi lähettää selaimelle vastauksena vaikkapa JavaScript-koodia tai kuvan. Koska nämä dokumentit voidaan rakentaa kokonaan lennossa, pystytään niistä tekemään reaaliaikaisesti päivittyviä ja ne voivat ottaa huomioon esimerkiksi käyttäjän edelliset toimet sivustolla. Dynaamisissa sivustoissa on usein mukana myös suuri määrä staattisia osia, joita ovat esimerkiksi CSS- ja JavaScript-tiedostot sekä kuvat. Nämä staattiset osat luodaan usein vastaavanlaisella prosessilla kuin kokonaiset staattiset sivustot.

Loppukäyttäjän sekä hänen käyttämänsä selaimen näkökulmasta staattiset ja dynaamiset sivustot ovat tismalleen samanlaisia. Kummassakin tapauksessa selain saa palvelimelta vastaukseksi samankaltaisia dokumentteja, jotka selain tulkitsee samalla tavalla. Rakentajan näkökulmasta näissä kahdessa toteutustavassa on toki valtavasti eroa, mutta joitakin yhteneviäkin asioita on.

Loppukäyttäjän sekä hänen käyttämänsä selaimen näkökulmasta staattiset ja dynaamiset sivustot ovat tismalleen samanlaisia.

Staattisen sivuston rakentaminen

Staattisen sivuston rakentamisessa yleensä ensimmäisenä isona päätöksenä on se, millaisen ns. sivustogeneraattorin päälle sivustoa lähdetään rakentamaan. Tähän päätökseen vaikuttavat, miten sisältöä sivustolle halutaan tuottaa ja kuinka paljon sivuston julkaisuprosessiin halutaan vaikuttaa, sekä se, millaisessa teknisessä ympäristössä toimitaan. Suosittuja vaihtoehtoja sivustogeneraattoreiksi ovat esimerkiksi Jekyll , Hugo ja MetalSmith.

Tämän päätöksen jälkeen sivustolle pitää suunnitella käytettävät sivupohjat. Useimmiten sivupohjia ei kirjoiteta suoraan HTML:nä, vaan niiden rakentamiseen käytetään jotakin ns. template-kieltä. Tällaisia ovat esimerkiksi Liquid, Handlebars ja Pug (ent. Jade). Useimmiten sivustogeneraattori määrittelee, mitä template-kieltä sivuston rakentamisessa käytetään, joten tämä saattaa vaikuttaa päätökseen siitä, mitä sivustogeneraattoria päädytään käyttämään.

Kun sivupohjat ovat siinä kunnossa, että HTML-dokumentin rakenne vaikuttaa halutunlaiselta, aletaan yleensä kaivata sivustolle CSS-tyylitiedostoja, jotta sivulle saadaan oikeanlainen visuaalinen ilme. Näitäkään ei nykyään enää juurikaan kirjoiteta suoraan CSS-koodina, vaan ne käännetään Sass- (SCSS-), Less– tai Stylus-kielisistä lähdetiedostoista. Nämä kaikki pyrkivät tekemään CSS-tyylien kirjoittamisesta helpompaa, selkeämpää, modulaarisempaa sekä enemmän ”oikean ohjelmoinnin” kaltaista. Lopputuloksena syntyy kuitenkin aina CSS-koodia, joka yleensä vielä tiivistetään käännösvaiheessa mahdollisimman pieneksi, koska lopullisen tuotoksen luettavuudella tai selkeydellä ei ole merkitystä kenellekään, eikä ylimääräisiä tavuja ole mitään järkeä tästä syystä siirtää palvelimelta selaimelle. Yleensä myös useita tyylitiedostoja yhdistetään toisiinsa, jotta selain ei joudu tekemään palvelimelle useaa pyyntöä tyylien lataamiseksi.

Jos staattiselle sivustolle halutaan toteuttaa jotakin dynaamista toiminnallisuutta, se pitää tehdä asiakkaan selaimessa. Tähän voidaan käyttää alunperin selainohjelmointiin kehitettyä JavaScript-skriptauskieltä (tunnetaan tästä eteenpäin lyhenteellä JS). Jotta asiat eivät olisi tässäkään ihan niin yksinkertaisia, voidaan JS-koodinkin asemesta käyttää jotakin muuta ohjelmointikieltä, joka sitten käännetään JavaScriptiksi. Vaihtoehtoja ohjelmointikieliksi selainskriptaukseen ovat esimerkiksi Dart, TypeScript ja CoffeeScript. Toisinaan on tarvetta myös kääntää uudempaa ECMAScript-standardia vastaavaa JS-koodia vanhemmille selainversioille, mikä onnistuu näppärästi vaikkapa Babel-kääntäjällä. Käännöksen yhteydessä JS-tiedostoille tehdään usein samanlaisia toimenpiteitä kuin CSS:llekin, eli tiedostot tiivistetään ja niitä yhdistetään toisiinsa turhan verkkoliikenteen eliminoimiseksi.

Kun koodipuoli on muuten valmiina, tarvitaan sivustolle usein grafiikkaa. Nykyaikaisella päätelaitekirjolla katseltavilla, responsiivisilla sivustoilla käytetään usein SVG-formaatissa olevia vektorikuvia. SVG on sikäli mielenkiintoinen kuvaformaatti, että se on XML-muotoista koodia, joka on muokattavissa samalla tavalla kuin kaikki muukin sivuston lähdekoodi. Tästä syystä samantyyppiset toimenpiteet ovat tehtävissä SVG-kuville kuin CSS- ja JS-tiedostoillekin: ne voidaan tiivistää ja yhdistää toisiinsa ns. SVG-spriteksi.

Yhteenvetona siis staattisen sivuston rakennuksessa käytetään usein seuraavia osasia:

• Sivuston varsinaiset sisältösivut esim. Markdown-formaatissa
• Jollakin template-kielellä kirjoitetut sivupohjat, joiden sisään HTML-muotoiltu sisältö upotetaan
• CSS-tyylitiedostoiksi käännettävät lähdekooditiedostot esim. SCSS-muodossa
• JavaScript-tiedostot sekä sellaisiksi käännettävät lähdekooditiedostot
• Kuvat esim. SVG-formaatissa
• Rakennustyönkulkuun tarvittavat asetus- ja prosessitiedostot, kuten esim.Gulpinkäyttämä gulpfile.js-tiedosto

Markdownin, SCSS:n ja vaikkapa CoffeeScriptin käyttäminen HTML:n, CSS:n ja JS:n lähdetiedostoina tekee koodista usein mukavampaa kirjoittaa ja ylläpitää, mutta edellyttää, että kirjoittaja osaa miettiä, millaista koodia käännösprosessin tuloksena syntyy. Niinpä näiden kolmen ohjelmointikielen asemesta pitääkin oikeastaan osata kuutta, jotta hommasta selviää kunnialla. Tämän lisäksi näille kaikille on saatavilla lukemattomat määrät kirjastoja ja sovelluskehyksiä, jotka kaikki tuovat oman mausteensa kehittämistyöhön.

Dynaamisen sivuston rakentaminen

Dynaamisen sivuston rakentaminen eroaa staattisen sivuston rakentamisesta ratkaisevasti, sillä se sisältää oikeastaan kaikki samat asiat kuin staattisenkin sivuston rakennusprosessi, mutta lisäksi usein ämpäreittäin asetuksia, määrityksiä ja jonkun verran myös räätälöityä palvelinpään koodia. Näiden kaikkien suhde riippuu hyvin pitkälti siitä, millaisella alustalla dynaamista sivustoa lähdetään rakentamaan. Meidän tapauksessamme alustana toimii aina Drupal.

Yksinkertaisimmillaan www-sivuston palvelintoteutuksen tarkoituksena on vastata selaimen tekemään HTTP-pyyntöön HTML-dokumentilla. Tämä edellyttää, että palvelin pystyy vastaanottamaan ja tulkitsemaan HTTP-pyyntöjä siten, että vastaukseksi voidaan tarjoilla jokin seuraavista:

• Dynaamisesti rakennettu HTML- tai jokin muu dokumentti (dynaamisesti voidaan tietysti rakentaa mitä vain, vaikkapa JavaScript-tiedostoja tai kuvia
• Palvelimen tiedostojärjestelmästä löytyvä staattinen tiedosto (esim. JS- tai CSS-tiedosto)
• Pelkät HTTP-otsakkeet sisältävä vastaus, joka esim. ohjaa selaimen toiseen osoitteeseen

Palvelimella käytettävästä teknologiasta riippuen tämä voidaan toteuttaa joko niin, että palvelinsovellus vastaa kaikesta tästä itse, tai niin, että käytetään erillistä HTTP-palvelinohjelmistoa, joka ohjaa vain dynaamiset pyynnöt palvelinsovellukselle jonkin rajapinnan kautta. Meidän Drupal-toteutuksissamme käytössä on aina malli, jossa sovellus (eli Drupal) on erillisen HTTP-palvelimen (meillä Nginx) takana ja viestintä HTTP-palvelimen ja sovelluksen välillä tapahtuu FastCGI-rajapinnan kautta.

Tietovarasto

Dynaamisen sivuston taustalla on yleensä tietovarastona toimiva tietokantajärjestelmä, johon tallennetaan sivuston sisältöä, käyttäjätietoja ja rakennetta sekä muita sivuston tietoja. Perinteisten relaatiotietokantojen kanssa tietoja käsitellään yleensä SQL-kielellä, mutta uudempien ns. NoSQL-kantojen kanssa toimintatavat voivat vaihdella hyvinkin paljon. SQL- ja NoSQL-kannat eivät millään tavalla sulje toisiaan pois, vaan hyvin usein yhden sovelluksen taustalla käytetään molempia tietokantatyyppejä ja vielä lisäksi ns. avain-arvopari-varastoa (key value store). Tietovarastovalinta kannattaa yleensä tehdä sen perusteella, mikä varastomalli toimii parhaiten kulloisenkin tietorakenteen kanssa, mutta valmista sovellusalustaa käytettäessä joudutaan ratkaisussa toimimaan sen ehdoilla, mitä vaatimuksia alusta asettaa käytetyille tietovarastoille. Tämä vaikuttaa usein myös tietovarastojen konfiguraatioihin sekä palvelinympäristön topologiaan.

Sivustoa rakennettaessa on tärkeää suunnitella se, miten tietovarastoissa olevia tietoja voidaan liikutella kehitys-, testaus- ja tuotantoympäristöjen välillä. Tämä on usein hyvinkin vaikea ongelma ratkaistavaksi ja saattaa olla joissakin tapauksissa lähes mahdotonta saada automatisoitua. Tätä kutsutaan tietojen migraatiotyönkuluksi ja se saattaa usein vaatia hyvin runsaastikin käsityötä, mikäli ympäristöjen välillä siirrettäviä tietoja ei saada selkeästi määriteltyä loogisiksi kokonaisuuksiksi.

Varsinaisen kehitystyön tuloksena syntyvässä koodissa tietovarastoja käytetään usein jonkin abstraktiokerroksen (esim. jokin ORM-toteutus) kautta, jolloin ”suoraa” interaktiota tietovarastojen kanssa ei synny. Tämä yleensä tekee toteutuksesta tietoturvallisemman ja auttaa pitämään koodin sisäisen ”maailmankuvan” helpommin hahmotettavana.

Sovellus

Tietovarastoa käyttävä sovellus on vastuussa varsinaisen vastauksen rakentamisesta selaimen esittämälle pyynnölle. Palvelimilla ajettavien sovellusten rakentamiseen on valittavissa lukemattomia määriä erilaisia alustoja ja sovelluskehyksiä. Meidän käyttämämme Drupal-järjestelmä pohjautuu PHP-skriptikieleen, joka on varmastikin laajimmin tuettu palvelinsovellusten rakentamisessa käytetty ohjelmointikieli.

Valittu sovellusalusta sanelee hyvin pitkälti sen, millaisen ns. teknologiapinon päälle sivustoa lähdetään rakentamaan. Teknologiapino puolestaan jonkin verran määrittää, mitä asioita ympäristössä voidaan tehdä ja miten. Onkin ensiarvoisen tärkeää ymmärtää käytettävien teknologioiden vahvuudet, heikkoudet, mahdollisuudet ja rajoitukset, jotta vältytään mittavilta muutostöiltä myöhemmin.

Kun käytetään esimerkiksi valmista sisällönhallintajärjestelmää sivuston alustana, on suuri osa kehitystyötä järjestelmän konfiguroiminen. Tämä yleensä pitää sisällään sivuston tietomallien suunnittelun sekä sisällön viittaussuhteiden määrittelyn. Usein myös suuri osa sivuston listauksista ja rakenteesta luodaan suoraan järjestelmässä. Jopa kohtuullisen monimutkaisenkin sivuston saa varsin nopeasti pystyyn ilman minkäänlaista tarvetta kirjoittaa riviäkään koodia.

Valmiiden palikoiden käyttäminen valitun sovellusalustan kanssa onkin erittäin järkevää, sillä se paitsi nopeuttaa sivuston kehitystyötä, myös vähentää tarvetta itse ylläpitää sivuston koodia. Tämä kuitenkin tarkoittaa, että käytettyjen palikoiden koodin pitäisi olla todettu turvalliseksi. Jonkin ulkopuolisen tahon tarjoamien komponenttien käyttäminen sivuston osana avaa potentiaalisesti valtavan tietoturva-aukon sivustolle, mistä saattaa pahimmillaan koitua hyvinkin mittavaa vahinkoa niin sivustolle kuin sen käyttäjillekin. Eri alustoilla on erilaiset mekanismit tietoturvaongelmien minimoimiseksi – Drupalin tapauksessa se on jatkuvaa ekosysteemin tietoturvavalvontaa (loistavalla tehokkuudella) tekevä tietoturvatiimi.

Kaikkeen ei aina löydy valmista palikkaa tai saatavilla olevat valmiit ratkaisut eivät toimi ihan toivotulla tavalla. Tällöin ei oikein ole muuta mahdollisuutta kuin koodata sovelluksen päälle oma ratkaisu. Omaa koodia tuotettaessa kannattaa erityisen tarkasti huomioida se, millaisia käytäntöjä valitulla alustalla suositaan ja miten oma koodi integroituu alustaan oikein. Tästä syystä koodia usein joudutaankin kirjoittamaan hieman alustan ehdoilla, vaikka haluttu toiminnallisuus saataisiin mahdollisesti hiukan yksinkertaisemminkin toteutettua.

Ohjelmointityötä itsessään ei kovinkaan usein mielletä luovaksi työksi, mutta todellisuudessa se on varsin lähellä taidetta. Ohjelmointi on pohjimmiltaan ideoiden ilmaisua tekstin keinoin ja muistuttaa prosessina varsin paljon säveltämistä. Sävellystyötä aloitettaessa on yleensä olemassa käsitys siitä, millaisia asioita lopputuloksella halutaan sanoa, mutta toteutuksen yksityiskohdat ovat vielä hyvin pitkälti hämärän peitossa. Hyvä koodi on helppolukuista, hyvin jäsenneltyä ja välittää kehittäjän ajatukset selkeästi lukijalle. Ohjelmistojen lähdekoodin pitäisikin olla ensisijaisesti kirjoitettu muille ihmisille. Alustasta riippuen tämä pyrkimys toteutuu vaihtelevalla menestyksellä, mikä saattaa joissakin tapauksissa vaikuttaa alustavalintaan.

Ohjelmointiprosessi yleensä koostuu seuraavista osa-alueista:

• Erilaisten ohjelmointirajapintojen ja järjestelmien dokumentaatioiden lukeminen
• Testitapausten suunnittelu ja toteuttaminen
• Toteutuksen tietomallien ja prosessien suunnittelu
• Rajapintojen suunnittelu (sis. käyttäjille tarkoitettu käyttöliittymä)
• Ohjelmointitoteutuksen kirjoittaminen
• Ohjelmointitoteutuksen lähdekoodin refaktorointi
• Kommentointi ja dokumentointi
• Versiohallinta

Sovelluksen rakentaminen on siis oikeasti vain todella pieneltä osin lähdekoodin kirjoittamista. Suuri osa rakentamistyöstä on suunnittelua, konfigurointia ja dokumentaation lukemista. Valtaosa tuotettavasta lähdekoodista puolestaan dynaamisella sivustolla menee ns. frontendin toteuttamiseen, eli staattisen sivuston rakentamisesta tuttuihin CSS-tyylitiedostoihin ja JS-skripteihin.

HTTP-palvelinohjelmisto

Kuten aikaisemmin tuli mainittuakin, usein sovelluksen ja asiakkaan selaimen välissä on HTTP-palvelinohjelmisto, joka vastaa HTTP-viestinnästä selaimen ja sovelluksen välillä. HTTP-palvelimen tehtävänä on vastaanottaa selaimelta tulevia pyyntöjä, tulkita ne ja ohjata pyynnöt eteenpäin sovellukselle. Meidän alustamme tapauksessa HTTP-palvelimen tehtävä on seuraavanlainen:

1. Nginx-HTTP-palvelin vastaanottaa HTTP-pyynnön verkosta ja tulkitsee sen.
2. Jos pyyntö koskee tiedostoa, joka löytyy sellaisenaan sopivasta paikasta palvelimen tiedostojärjestelmässä, palvelin lähettää tiedoston vastauksena pyyntöön. Jos tiedostoa ei löydy, palvelin lähettää pyynnön tulkitun datan FastCGI-rajapinnan kautta sovellusalustalle (tässä tapauksessa Drupal, jota ajetaan PHP-FPM:n kautta).
3. Nginx vastaanottaa sovellusalustalta tulevan vastauksen, tekee siihen mahdollisesti muutoksia ja lähettää sen eteenpäin pyynnön tekijälle.

Koska HTTP-palvelinohjelmisto toimii porttina sovellukseen, on erittäin tärkeää, että HTTP-palvelin toimii hyvin yhteen sovellusalustan kanssa. Tässä yhteistyössä suuressa roolissa on periaate siitä, että sovellukselle asti ei koskaan välitettäisi mitään sellaista pyyntöä, jonka HTTP-palvelin pystyy itse käsittelemään. Tämä johtuu siitä, että toimintojen tekeminen sovelluksella on usein erittäin paljon raskaampaa ja hitaampaa (eli konkreettisesti ilmaistuna kalliimpaa) kuin suoraan HTTP-palvelimella. Tästä syystä HTTP-palvelimen konfiguraatio on myös varsin tärkeä osa dynaamisen sivuston rakennusta, vaikka onkin yleensä laajuudeltaan vain murto-osa ajettavan sovelluksen konfiguraatiosta.

Viimeistely ja optimointi

Oli kyseessä sitten staattinen tai dynaaminen sivusto, kävijät ja hakukonerobotit käsittelevät kaikkia sivustoja samalla tavalla. Vaikka tärkeimmässä asemassa aina onkin sivuston sisältö, voidaan käytettävyyteen ja hakukonenäkyvyyteen vaikuttaa myös teknisillä toimenpiteillä. Tässä yleensä auttavat Google PageSpeed Insightsin tyyliset työkalut, jotka kertovat varsin konkreettisesti, mitä toimenpiteitä sivustolla pitäisi tehdä. Jotkin ehdotetuista toimenpiteistä ovat toisinaan mahdottomia toteuttaa sivuston alustan tai vaatimusten vuoksi, mutta ne kuitenkin tarjoavat hyvän pohjan mietittäessä sivuston jatkokehitystä.

Uuden sivuston julkaisun jälkeen kannattaa usein tehdä käyttäjätutkimus. Tutkimustulosten perusteella voidaan päätellä, millaisia toimenpiteitä sivuston sisällölle, rakenteelle ja käyttöliittymälle pitäisi tehdä, jotta sivustolle asetetut tavoitteet saataisiin mahdollisimman hyvin täytettyä. Kannattaa myös huomioida, että käyttäjien tarpeet ja sivuston tavoitteet muuttuvat sivuston elinkaaren aikana usein varsin paljonkin, joten muutoksia todennäköisesti joudutaan suunnittelemaan ja toteuttamaan useaan otteeseen. Parhaaseen lopputulokseen sivuston jatkokehityksessä päästään, kun muutokset tehdään tutkitun, konkreettisen tiedon perusteella.