Mozilla-selaimen versiossa 1.2 ja sitä uudemmissa on mukana esihaku, joka mahdollistaa sivujen hakemisen taustalla samalla aikaa, kun käyttäjä vielä lueskelee edellistä sivua. Tässä jutussa käsitellään joitain esihakutekniikkaan liittyviä kysymyksiä. Mozillan esihausta on erillinen juttu.
Vaikka tämä juttu onkin kirjoitettu Mozillan uuden ominaisuuden inspiroimana, tekniikka itsessään ei ole mitenkään uutta. Esimerkiksi NetAccelerator-niminen surffailunnopeuttajaksi itseään mainostama ohjelma on toteuttanut esihaun ajatusta jo kauan sitten. Myös Mac-mikroilla toimivan iCab-selaimen betaversiot tukevat eräänlaista esihakutekniikkaa. Mozillan panos markkinoilla on merkittävä lähinnä siksi, että Netscapen selainrunkona se saavuttaa huomattavasti laajemman yleisön kuin aiemmat välineet. Olennainen muutos on sekin, että Mozilla tarjoaa web-sivujen tekijöille selkeän (vaikkakaan ei standardoidun) tavan ohjata esihaun toimintaa.
Kokonaisuutena esihakua ja sen yleistymistä voidaan pitää positiivisena ilmiönä, varsinkin eräissä erityistilanteissa. Siihen liittyy kuitenkin eräitä ongelmia ja väärinkäyttömahdollisuuksia. Järkevän ja hyvin käyttäytyvän esihakutoiminnon toteuttaminen ei ole helppoa sen paremmin selaimen kuin www-kehittäjänkään kannalta.
Mozillan esihaun toimintatapa on kuvailtu erillisessä jutussa.
Varsinkin dialup-yhteyksillä (modeemit ja ISDN:t) merkittävä osa surffailun hitaudesta johtuu verkkoyhteyden hitaudesta - siis datan siirtoon liittyvistä viiveistä. Useimmiten verkkokaistan käyttö on kuitenkin voimakkaasti vaihtelevaa: koko kapasiteetti on hetkellisesti käytössä käyttäjän tehtyä jotain (yleensä linkin klikkauksen jälkeen), toisaalta dataa ei liikutella juuri ollenkaan sillä aikaa, kun käyttäjä lukee sivua. Tästä aiheutuu turhia viiveitä puolin ja toisin: siirtoyhteys odottaa käyttäjän reaktiota ja käyttäjä odottaa siirtoyhteyden suoritusta. Ongelmaan on perinteisesti pyritty pureutumaan kahdella pääasiallisella keinolla: lisäytyvällä piirrolla (incremental rendering) ja esihaulla (prefetch).
Ennen nopeutustapojen ja niiden ongelmien käsittelyä on todettava, että aiempaa huomautusta dialup-yhteyksistä pitää tulkita harkiten. Tosiasia on se, että kiinteällä yhteydellä siirtokaistaan liittyvät ongelmat ovat pienempi osa surffailun hitaudesta (vastaavasti korostuvat käyttöliittymälliset ongelmat ja palvelinten hitaus). Tämä ei kuitenkaan tee esihausta turhaa ominaisuutta kiinteilläkään yhteyksillä, sillä jo HTTP-yhteyden avaamiseen nimipalveluhakuineen kuluu helposti sekunti. Lisäksi itse tiedonsiirtokin kestää, vaikka se onkin nopeaa - tämän voi helposti todeta surffaamalla oman koneen kiintolevylle tallennetuilla sivuilla. Sivujen esiinräpsähtämisestä voi harvoin puhua kiinteälläkään yhteydellä. Tärkeä huomio on myös se, että kiinteällä yhteydellä surffatessa ihminen toimii usein kärsimättömämmin ja odottaa välittömämpiä vasteita. Pienikin viive siis korostuu. Näin perustein on turvallista sanoa, että esihakutekniikalle on tarvetta myös kiinteiden yhteyksien käyttäjien keskuudessa.
Lisäytyvän piirron ideana on näyttää sivun sisältöä sitä mukaa kuin sitä ladataan, jolloin käyttäjä voi aloittaa oman suorituksensa (sivun lukemisen) vielä siirtoyhteyden ollessa käynnissä. Tähän tekniikkaan liittyy myös esim. gif- ja jpeg-kuvanpakkausalgoritmeihin kuuluva mahdollisuus näyttää kuvaa ensin epätarkkana ja tarkentaa näkymää sitä mukaa kun tietoa latautuu verkosta. Lisäytyvä piirtotekniikka sisältää usein myös sen, että teksti ladataan ennen kuvia - tämä perustuu oletukseen siitä, että teksti on kuvia kiinnostavampaa ja tavumääräisesti vähemmän raskasta, ja yleensä tämä pitääkin paikkansa. Käytännössä kaikki graafiset selaimet toteuttavat lisäytyvää piirtoa nykyisin jo varsin mallikkaasti.
Piirtotekniikan parannukset eivät kuitenkaan ratkaise toista puolta viipeiden ongelmasta: siirtoyhteys odottaa edelleen käyttäjän tekemisiä. Lisäytyvä piirto ontuu joillain sivuilla myös siksi, että jo sivun rungon piirtäminen vaatii huomattavia tietomääriä; itse sisältöön päästään vasta kymmenien kilotavujen kuluttua. Lisäksi on huomattava, että lisäytyvän piirron soveltamisalaan kuuluvat lähinnä tekstidokumentit (sisältäen HTML:n) ja erityisesti sitä tarkoitusta varten suunnitellut binäärimuodot (esim. gif ja progressive jpeg -tekniikka). Vastaava ajatus on myös eräissä videoformaateissa, joiden katselun voi aloittaa vaikka koko tiedosto ei olisikaan saapunut. Esimerkiksi Word-dokumentit ja PDF-tiedostot on usein mahdollista muotoilla vasta koko dokumentin ladattua. Eräs tulevaisuutta koskeva näkökulma on se, että myöskään lennossa muotoiltujen XML-dokumenttien osalta lisäytyvä piirto ei välttämättä ole mahdollista, koska tietolähteen ja www-esityksen järjestys ei välttämättä ole sama.
Esihaku pyrkii siihen, että siirtoyhteys voisi ennakoida käyttäjän tekemisiä. Tämä mahdollistaisi sen, että yhteyttä voitaisiin käyttää jo sillä aikaa, kun käyttäjä lukee sivua. Täydellisesti toimiva esihaku johtaisi siihen, että käyttäjän siirtyessä uudelle sivulle seuraavia sivuja alettaisiin jo lataamaan, ja käyttäjän klikatessa linkkiä uusi sivu avautuisi välittömästi. Näin sekä siirtoyhteys että käyttäjä selviäisivät sivunvaihdosta viiveettä. Ongelma on siis vain siinä, miten tehdä esihausta niin hyvä, että se aiheuttaa enemmän hyvää kuin pahaa.
Positiivisesti täydellinen esihakualgoritmi olisi sellainen, joka lataisi aina käyttäjän seuraavaksi tarvitseman sivun muistiin - eli edellisessä kappaleessa kuvattu optimaalinen sivunvaihto tapahtuisi joka kerralla. Tämä on tietenkin vain teoreettinen rakennelma, koska käytännössä edes kaikkien sivulla olevien linkkien seuraaminen ei ole mahdollista (selain ei ehdi hakemaan tietoja, sivuja ei välttämättä voi hakea valmiiksi jne.). Tämän lisäksihän käyttäjän seuraava suunta voisi tulla esimerkiksi kirjanmerkeistä tai mistä tahansa muusta osoitteesta (joko selaimelle kirjoitettuna tai esim. sähköpostiviestistä klikattuna). Lisäksi on muistettava, että esihaku kohdistuu optimaalisimmillaan paljon muuhunkin kuin HTML-sivuihin: myös esimerkiksi kuvien esihakeminen on usein järkevää ja tarpeellista.
Täydellisen algoritmin ajatus tuhoutuu viimeistään silloin, kun algoritmille esitetään vaatimus negatiivisesta täydellisyydestä: sen lisäksi, että se hakee aina käyttäjän seuraavaksi haluaman dokumentin, se hakee vain tuon nimenomaisen dokumentin eikä mitään muuta. Negatiivista vaatimusta koskee kuitenkin eräs erityisongelma: tiettyjä poikkeustilanteita lukuunottamatta yksittäisen käyttäjän kannalta optimaalista on esihakea mahdollisimman paljon, jotta todennäköisyys juuri sen oikean dokumentin löytymisestä olisi mahdollisimman suuri. Toisaalta verkon ja palvelinten kannalta jokainen turha esihaku aiheuttaa tarpeetonta kuormaa. Ongelman taloustieteellinen nimi on ulkoiskustannukset: esihausta aiheutuu kuluja, mutta ne eivät kohdistu hyödynsaajiin.
Edellä esitetystä problematiikasta on seurannut se, että monet surffikiihdytinohjelmat käyttävät esihakua melko suruttomasti, kulkien jopa useita tasoja linkkihierarkiaa etukäteen. Erityisesti kiinteillä yhteyksillä kiihdytin voi hyvin ehtiä hakemaan melkoisen määrän dataa sillä aikaa, kun käyttäjä lueskelee jotain sivua tai täyttää lomaketta. Parhaimmillaan hyvinkin monet näistä hauista ovat hyödyllisiä, mutta harvoin kaikki. Pahimmillaan kaikki tai ainakin lähes kaikki menevät huti - jos esimerkiksi käyttäjä kirjoittaa Googleen huonon hakusanan, kiihdytin voinut ehtiä hakemaan useamman hakutulossivun (ehkä jopa kuvineen) ennen kuin käyttäjä onnistuu tuottamaan paremman hakusanan ja painamaan hakunappia. Syntyi kovasti liikennettä ilman yhtään hyvää tulosta.
Pitkälti esihakuohjelmien kuorma- ja tilastovaikutukset ovat hävinneet Internet-liikenteen massaan. Mozillan uusi ominaisuus saattaa kuitenkin vaikuttaa kehitykseen. Siinä missä NetAcceleratorin kaltaiset ohjelmat ovat harvinaisia, selain on kaikilla. Jos esihakutoiminnallisuus yleistyy selaimissa, kysymys toiminnon "negatiivisesta täydellisyydestä" korostuu. Kyse on toisin sanoen siis esihaun hyötysuhteesta: mikä prosenttiosuus esiladatuista sivuista oikeasti voidaan hyödyntää? Todettakoon, että erinäiset tutkimukset (esim. Dan Duchampin Prefetching Hyperlinks vuodelta 1999) osoittavat erittäin monimutkaistenkin algoritmien tuottavan parhaimmillaan vain reilun 60 prosentin hyötysuhteen, ja monet yksinkertaisemmat ratkaisut jäävät pahimmillaan vain muutamaan prosenttiin. Tämä heijastaa sitä, että Duchampin tutkimuksen mukaan vain keskimäärin 5,4 prosenttia www-sivuilla olevista linkeistä käytetään (yhden sivulatauksen seurauksena).
Hyvän esihakualgoritmin toteutusta on pohdittu lukuisten väitöskirjojen ja muiden teosten verran. Koska tässä jutussa on tarkoitus käsitellä esihakutekniikkaa ja siihen liittyviä pulmia vain yleisellä tasolla, jätetään algoritmin yksityiskohtien pohdinta sikseen. Asiaa raapaistaan vain pinnalta, jotta erityisesti Mozillan käyttämän algoritmin hyvät ja huonot puolet kävisivät ilmi.
Esihakualgoritmit voidaan jakaa kahtia: historiaa käyttäviin ja spekulatiivisiin. Historiaa käyttävässä esihaussa on kyse siitä, että käyttäjän arvioidaan liikkuvan verkossa konservatiivisen mallin mukaisesti: hän käyttää usein sivuja, joilla hän on käynyt aikaisemminkin. Tämän vuoksi esihaku painottuu jo käytettyihin linkkeihin, ja jotkut toteutukset toimivat juuri tämän mukaan: esihakevat sivulta juuri ne linkit, joita käyttäjä on aikaisemminkin seurannut (luonnollisesti edellyttäen, ettei sivun sisältö ole jo valmiiksi jossain välimuistissa).
Spekulatiiviset algoritmit eivät luota historiaan vaan pyrkivät ennustamaan käyttäjien tulevaa käytöstä. Kyse on surffailumallin mukaisesta verkon käytöstä: Käyttäjä liikkuu villisti sivulta toiselle, eikä ole oletettavaa, että hän yleensä valitsisi saman polun kuin aiemmin. Tällaisen käytöksen analysointiin on hyvin monenlaisia tapoja. Eräs yksinkertaisimmista on tutkia html-lähdekoodia ja etsiä sieltä hyvin näkyviä linkkejä. Monimutkaisemmat algoritmit käyttävät tekoälyä analysoidakseen aikaisempien käyttäjien kulkureittejä (tämä toiminto löytyy myös joistain web-mittauspalveluista). Aikaisempien käyttäjien toimintaan perustuvien algoritmien ongelma on kuitenkin se, ettei niitä voida helposti sijoittaa vain selaimeen, koska selain ei pääse käsiksi palvelimen lokitietoihin. Kirjallisuudessa onkin ehdotettu erilaisia menetelmiä, joiden avulla palvelin keräisi reaaliaikaista tietoa käyttäytymismalleista (kulkureiteistä) ja välittäisi sitä selaimelle.
Molempia edellä kuvattuja algoritmityyppejä yhdistävä piirre on läpinäkyvyys: esihaut voitaisiin toteuttaa tarvittaessa sekä selainta että palvelinta muuttamatta, jos väliin sijoitettaisiin sopivasti älykkäät välimuistipalvelimet. Jos läpinäkyvyysvaatimuksesta ei pidetä kiinni, päästään uudenlaisten mahdollisuuksien ääreen. Entä jos valinta esihaettavista dokumenteista annetaankin käyttäjälle tai sivun tekijälle?
Käyttäjän valintaan pohjautuva esihaku on käytännössä ongelmallinen lähinnä siksi, että esihaun hyödyllisyys perustuu pitkälti surffauksen helpottamiseen, ja manuaalisesti tehtävät teknisluonteiset valinnat eivät yleensä paranna kokonaiskäytettävyyttä. Toisaalta rajoitetusti tekoälykäs esihaku voi hyvin toimia käyttäjän opastuksella: esimerkiksi usein käytetyt tai mahdollisesti muuten valitut selaimen kirjanmerkkien viittaamat sivut voisi esihakea selaimen käynnistyksen yhteydessä. NetAccelerator-ohjelma sisältää myös mahdollisuuden määritellä ajastettuja hakutöitä, jolloin ohjelma hakee halutut sivut tietyin väliajoin aina selaimen välimuistiin. Tällaisissa tapauksissa käyttäjän valinta voi toimia, mutta valtaosassa tilanteista esihaun esittäminen käyttäjälle on vain pahasta.
Esihaun ohjailun vallan antaminen sivun tekijälle on huomattavasti mielenkiintoisempi ja käytännönläheisempi asia - eikä vähiten siksi, että se on Mozillan valitsema (ja kiistatta selainvalmistajan kannalta helpoin) tie. Voisi ajatella, että sivun sisällön semantiikan kaikkein parhaiten tunteva tekijä olisi myös kaikkein paras taho päättämään siitä, mitä on järkevää hakea ennalta. Tämä päätelmä pitänee paikkansa vain siinä tilanteessa, kun sivustoa ylläpidetään aktiivisesti nimenomaan esihaku mielessä. Käytännössä tämä vaatisi sitä, että käyttäjien toimintaa olisi nimenomaisesti analysoitava jotenkin ja syntyneet tulokset olisi siirrettävä sivulle, eli muutettava sivun esihakua koskevia ohjeita vastaamaan tuoreita kulkureittejä sivustolla.
Kun käytännössä sivujen tekijät yleensä vain luovat sivut kerran ja hädin tuskin ylläpitävät niitä sen jälkeen (tämä pätee varsinkin sivujen perusrakenteeseen), on epätodennäköistä, että tekijän ohjaama esihaku voisi parantaa suorituskykyä merkittävästi tavanomaisessa surffailussa. Toisaalta esihakualgoritmi voidaan määritellä siten, että mitään ei haeta ellei sivun tekijä erityisesti niin kehota tekemään. Tällöin keskivertosaitilla surffailija ei ehkä hyödy mitään, mutta toisaalta myöskään esihaun haittavaikutukset eivät pure niin pahasti. Oikein toteutettuna ja sopivasti käytettynä tällainen esihakutoiminto voi itse asiassa tuottaa hyvinkin korkeita hyötysuhteita niillä sivuilla, joilla sitä käytetään.
Edellä esittämäni pessimistinen kanta voi muuttua, jos hyviä automaattisia työkaluja polkuanalyysien kehittämiseen toteutetaan. Open source -piireissä sellaisista on puhuttukin; saa nähdä, miten käy. Joka tapauksessa olennainen este ylläpitäjän ohjaaman esihaun käytölle on nimenomaan ylläpitotyön raskaus pitkällä aikavälillä. Tätä helpottavilla työkaluilla on mahdollisuus parantaa Mozillankin algoritmin toimivuutta olennaisesti.
Eräs mielenkiintoinen kysymys on se, kuinka pitkälle esihakuja kannattaa suorittaa. Usein jo yhden tason linkkien hakeminen on tarpeeksi. Hakusyvyyden lisääminen pahentaa hutien riskiä. Jos sivulta A on linkit sivuille B, C ja D ja B:stä edelleen linkit sivuille E, F ja G, kaksitasoinen esihakualgoritmi (oletetaan tässä, että kaikki linkit olisi jollain logiikalla valittu esihaettaviksi) hakisi A:lle saavuttaessa kaikki sivut B-G. Jos käyttäjä sitten jatkaisikin matkaansa C:hen, olisi haettu turhaan B, D ja E-G eli 5 sivua (osumaprosentti siis 1/6 ~ 17%). Yhden tason syvyyteen hakeva algoritmi olisi hakenut turhaan vain B:n ja D:n (osumia 1/3 ~ 33%).
Hutien lisäksi toinen hakusyvyyteen (ja -määriin ylipäätäänkin) liittyvä ongelma on sivujen vanhentuminen. HTTP/1.1-protokolla määrittelee varsin yksityiskohtaiset käytännöt, joilla palvelin voi ilmaista sivun vanhenemisajan eli sen, jonka jälkeen sivu on haettava uudelleen palvelimelta. Jos esimerkiksi sivun A latautuessa selain esihakee sivun B, koko esihaku voi mennä hukkaan sillä, että sivu B ehtii vanhentua ennen kuin edes käyttäjä klikkaa sille johtavaa linkkiä. Näin sivu B täytyykin itse asiassa hakea kahdesti: ensin kerran turhana esihakuna ja sitten varsinaisen sivun näytön yhteydessä.
Oikeastaan kysymys esihaettavien sivujen valinnasta täytyykin siis muotoilla näin: "Mille sivulle käyttäjä todennäköisimmin siirtyy siten, että siirtymä tapahtuu ennen sivun sisällön vanhenemista?". Kysymys voi tuntua vähämerkityksiseltä, mutta esim. kellonajan sisältävän sivun kohdalla tällä saattaa olla huomattavakin vaikutus. Lisäksi on muistettava, että joitain sivuja ei yksinkertaisesti voi ollenkaan tallentaa välimuistiin, jolloin myöskään esihaku ei ole yleensä järkevää.
Käytännössä esihakutekniikan osalta eletään varsin ongelmallista vaihetta. Mozillan myötä esihaku on saanut huomattavasti uusia käyttäjiä, mutta toisaalta valtaosa surffaajista (Internet Explorerin käyttäjät) eivät vielä tunne ominaisuutta. Microsoft ei ole toteuttanut minkäänlaista esihakutoimintoa selaimeensa, ja kun se toteutetaan, lopputulos ei todennäköisesti ole yhteensopiva Mozillan kanssa. Voi olla että Microsoftkin päätyy sivun tekijän valtaa painottavaan näkökulmaan, mutta muitakin mahdollisuuksia on. Mikäli Internet Explorer tulee toteuttaa esihaettavan materiaalin valinnan olennaisesti eri tavalla kuin Mozilla, voi esihakujen toiminnan ennustaminen osoittautua hyvin vaikeaksi.
Mozillan esimerkki tullee liittämään esihakutoiminnon muihinkin pienempiin selaimiin, erityisesti Mozillan koodipohjaa käyttäviin. Lisäksi luonnollisesti Netscape tulee ottamaan prefetch-ominaisuuden käyttöön. Näin ollen on todennäköistä, että erilaisia toteutuksia ja algoritmeja ilmestyy markkinoille lähiaikoina. Käytännössä kuitenkin merkittävät markkinoiden jakajat tuntuvat tällä hetkellä olevan joko esihausta mitään ymmärtämättömät (Internet Explorer, Opera jne.), www-sivun tekijälle hallinnan jättävät (Mozilla sukulaisineen) ja massaesihakua harrastavat apuvälineet (NetAccelerator ym.).
Näiden tietojen perusteella on helppo tehdä se johtopäätös, että jos jotain esihakuvaraumia omille sivuille kannattaa tehdä, ne kannattaa tehdä nimenomaan Mozilla-perhettä silmälläpitäen - tulevat (esimerkiksi Microsoftin) ratkaisut saattavat vaatia muutoksia, mutta niiden ennustaminen on joka tapauksessa mahdotonta.
Esihakutekniikalle on ryhmiteltävissä eräitä erityisiä käyttökohteita. Tämä ryhmittely on eroteltava tilanteesta, jossa käytetään automaattista ja läpinäkyvää esihakutoiminnallisuutta. Automaattitilanteessahan esihaettavien kohteiden valinta perustuu tilastolliseen analyysiin tai vastaaviin menetelmiin, eikä käyttökohteiden valintaan liity samanlaista problematiikkaa kuin silloin, kun valinta jätetään ihmisen (ja erityisesti sivun tekijän) huoleksi.
Eräs jo muutaman vuoden aktiivikäytössä ollut esihaun sovellus on Javascript-pohjaiset navigaatio- ym. rimat, joissa kuvat usein muuttavat ulkoasuaan hiiren siirtyessä niiden päälle. Ongelmana tässä on ollut se, että varsinkin hitaalla yhteydellä kuvan vaihtuminen kestää, kun kuvaa aletaan lataamaan vasta hiirikursorin siirtyessä kyseisen navilinkin päälle.
Kehittyneemmissä Javascript-toteutuksissa sivun latautumisen yhteydessä suoritetaan koodinpätkä, joka lataa kuvat valmiiksi muistiin. Tämä on sinänsä järkevä ja navigaatioriman toimintaa selkeyttävä esihakutavoite. Ongelmana on oikeastaan vain se, että Javascript-toteutus ei ole koodillisesti erityisen selkeä eikä tarjoa selaimelle semanttista ymmärrystä siitä, että oikeasti on kyse esihausta. Käytännössä tämä näkyy esimerkiksi siten, että käyttäjä ei voi halutessaan kytkeä esihakua pois päältä (ks. poiskytkentään liittyvien ongelmien käsittelyä).
Se, että selain tarjoaa www-sivun tekijälle selkeän tavan määritellä esihaettavat kohteet, on ehdottomasti hyvä asia. Jos kaikki selaimet tukisivat esim. Mozillan mallin mukaista esihakua, voisi Javascript-pohjaiset kuvien lataukset korvata semantiikkaa sisältävällä esihakumerkinnällä. Tähän tosin liittyy mielenkiintoinen kysymys siitä, että olisiko lopputulos parempi; tällöinhän kuvat esihaettaisiin myös silloin, kun Javascript ei ole selaimessa käytössä ja navipalkin osakuvien "valittuja" versioita ei ikinä edes näytettäisi. Asiaan liittyvän problematiikan läpikotainen pohtiminen ei kuulu tähän esitykseen, eikä se tämänhetkisen tilanteen huomioon ottaen ole ajankohtaistakaan. Olennaista kuitenkin on se, että nykytoteutuksilla Javascript-malli ja Mozilla-tyyppinen esihaku eivät ole keskinäisessä ristiriidassa missään tuntemassani selainympäristössä.
Varsin houkutteleva käyttökohde esihaulle on sellainen tilanne, jossa dokumenttia luontevasti seuraa toinen dokumentti, ja on varsin todennäköistä että käyttäjä tulee etenemään tässä järjestyksessä. Tällainen tilanne on esimerkiksi käyttöehtojen hyväksyminen. On varsin luultavaa, että käyttäjä tulee ehdot hyväksymään, joten seuraavan sivun esihakeminen tuottaa yleensä varsin hyvän hyötysuhteen (tosin asiaan saattaa liittyä ongelmia mm. sivujen rajoitetun varastoitavuuden seurauksena). Hieman vastaava esimerkki on (huonoa www-suunnittelua edustava) ovimattosivu, joka voi olla esim. tervetulotoivotus johonkin www-palveluun; siitä yleensä jatketaan juuri yhtä nimenomaista linkkiä klikkaamalla.
Toinen hyvä esimerkki on lukuihin jaettu kirjallinen teos (esimerkiksi käyköön HTML-spesifikaatio). Sellaista usein luetaan luvuittain järjestyksessä, olkoonkin että hakukoneiden ja ylipäätään hyperlinkityksen tehostuminen on lisännyt hyppivän lukemisen todennäköisyyttä. Silti useissa teoksissa sarjamaista lukemista voi olennaisesti nopeuttaa se, että seuraava sivu on valmiiksi ladattu.
Sarjamuotoisten dokumenttien tunnistamista helpottaa olennaisesti se, että jo standardi HTML tarjoaa mahdollisuuden ilmaista sarjassa seuraavan dokumentin osoite link-elementin avulla. Toistaiseksi link-elementtiin pohjautuvan navigaatiotuen tarjoaminen saiteilla on tosin melko harvinaista, mutta esihaku tarjoaa yhden hyvän syyn tämän käytön lisäämiseen - erityisesti, kun Mozillan esihaku perustuu pitkälti juuri link-elementteihin liittyviin hakumahdollisuuksiin.
Sarjamuotoisten dokumenttien satunnaislukeminen (esim. HTML-spesifikaatioon osoittava linkki, jota käyttäjä seuraa selvittääkseen jonkin yksittäisen asian) aiheuttaa esihaun osalta yleensä turhaa verkkokuormaa sikäli, että satunnaisesti dokumentin keskelle pulpahtanut henkilö ei erityisen todennäköisesti jatka matkaansa juuri seuraavalle sivulle. Tämän sivun hakeminen olisi siis turhaa. Optimaalisempaa olisi, jos käyttäjän selain osaisi olla esihakematta seuraavaa sivua silloin, kun on todennäköistä, ettei käyttäjä tule sitä kuitenkaan lukemaan.
Kyse on siis siitä, että sivuttain jaetun sarjamuotoisen dokumentin lukutavatkin jakautuvat kahtia. Esihakualgoritmin tehostaminen näissä tapauksissa vaatii sitä, että nämä kaksi lukutapaa erotetaan sivulatauskohtaisesti. Eräs tapa, jolla sivujen tekijän kontrolliin luottavassa mallissa voidaan toimia, on se, että dynaamisesti muodostettava sivu tarkastelee HTTP Referer -otsaketta, josta selviää, mistä käyttäjä on tälle sivulle tullut. Se tieto usein auttaa "Mihin käyttäjä on seuraavaksi menossa?"-kysymyksen ratkaisemisessa.
Huomattavaa on, että tällaista logiikkaa rakennettaessa ei olla enää kovin kaukana yleisistä spekulatiivisista esihakualgoritmeista, ja pidemmälle vietynä tekniikka käy sivujen toteuttajan kannalta helposti varsin työlääksi. Mozillassa tällaista kevyttä heuristiikkaa on suunniteltu toteutettavaksi itse selainpäähän; ks. next-relaatioon liittyviä poikkeuksia.
Silloin kun dokumenttiin liittyy useita laajoja ulkoisia objekteja, voi näiden esihakeminen olla hyödyllistä. Tällainen tilanne on esimerkiksi silloin, kun itse HTML-sivu on vain tiivistelmä tai johdanto johonkin vaikkapa PDF-muodossa olevaan asiakirjaan (ks. esimerkkiä oikeusministeriön sivuilta). Itse PDF:n esihakeminen saattaa olla käyttäjän kannalta merkittäväkin suorituskykyä parantava tekijä, jos voidaan pitää todennäköisenä sitä, että käyttäjä todella etenee itse sivulle.
Tietyissä tilanteissa vastaavassa roolissa ovat myös pikkukuvasta aukeavat kuvien täyskokoiset versiot. Ongelmana on kuitenkin se, että näissä tilanteissa kuvan katsomistodennäköisyyden arviointi ei ole helppoa: läheskään aina käyttäjä ei ole kiinnostunut klikkaamaan kuvaa isommaksi. Toisaalta on myös niin, että osa haluttomuudesta johtuu myös toiminnon yleisestä hitaudesta, ja tässä tapahtuva parannus voisi myös lisätä käyttäjän halua katsoa varsinaista isoa kuvaa.
Ulkoisia dokumentin osia esihaettaessa korostuu helposti myös haettava tavumäärä. Siinä missä seuraavan HTML-sivun hakeminen ei tyypillisesti aiheuta ainakaan monien kymmenien kilotavujen dataliikennettä, valokuvan täyskokoinen versio voi imaista kaistaa parisataa kiloa, ja painolaatuinen PDF on helposti jo megaluokassa. Tämänkokoisten tiedostojen esihakumäärityksissä on oltava varovainen. Jos käyttäjä oikeasti katsoo tiedostoa, esihaku on hyvä juttu tavumääristä riippumatta. Jos hän sen sijaan ei katso sitä, palvelinta ja verkkoa on kuormitettu turhaan suoritetuilla esihauilla.
Esihaun yleistyminen tuo mukanaan eräitä huomioitavia seikkoja tietoturvan ja järjestelmien väärinkäytön näkökulmasta. Erityisesti ongelmat liittyvät tilanteeeseen, jossa kontrolli esihaun toiminnasta (vaikka vain "ehdotusten" muodossa) on www-sivujen tekijöillä. Heidän näkökulmastaanhan esihaku tarjoaa merkittävän mahdollisuuden vaikuttaa käyttäjän selaimeen ja verkkoyhteyteen. Seuraavassa pari esimerkkiä tietoturvaan liittyvistä avoimista kysymyksistä.
Esihaku tarjoaa mahdollisuuden ohjata käyttäjän selainta varsin huomaamattomasti, ja tämä voi aiheuttaa varsin mielenkiintoisiakin seurauksia. Esimerkiksi Mozillan esihakutoteutuksessa sivuntekijän ohjeet esihaun käytöstä on mahdollista välittää HTTP-otsakkeissa, joita käyttäjä ei voi mitenkään vaivattomasti huomata (sivuston lähdekoodin tarkastelu ei paljasta mitään!).
Harmia voisi kuvitella syntyvän, jos esimerkiksi ala-asteen oppilas surffailee koulun mikroluokasta sivuille, jotka käynnistävät taustalla massiivisen esihaun, jonka kohteena on esimerkiksi pornoa. Koululla oleva älykäs palomuuriohjelmisto havaitsee sisällön tulevan kielletystä lähteestä ja hälyttää opettajan paikalle. Siinähän sitten selittelee, kun ope tivaa luontokuvien sijaintia koneella.
Palvelinpään skriptauksen ja esihaun avulla voidaan myös vuotaa tietoa muille sivustoille. On esimerkiksi vaivatonta tehdä rekisteröitymislomake, joka lähettämisensä jälkeen huomaamattomasti lähettää käyttäjän tiedot esimerkiksi toiselle sivustolle. Luonnollisesti tämä on ollut tähänkin asti mahdollista sivustojen välisellä yhteistyöllä, mutta esihaku tuo hommaan yhden elementin lisää: käyttäjän selain hoitaa homman huomaamattomasti taustalla, ja jälkikäteen esimerkiksi lokeja tarkastelemalla näyttää siltä, että käyttäjä olisi itse hoitanut rekisteröinnin. Tämä pieni epäselvyyden lisäys voi jossain hämäräpuuhassa tulla tarpeeseen.
Liiallisten epäluulojen välttämiseksi on kuitenkin aiheellista mainita, ettei käyttäjän selaimen ohjailu ole ollut mahdotonta aiemminkaan. Aiemmat tekniikat ovat pohjautuneet pitkälti näkymättömiin kuviin, Javascriptiin, kehyksiin tai inline-kehyksiin (iframe). Esihaku lisää tässä suhteessa vain sen uutuuden, että ohjailu voidaan tehdä HTML-lähdekoodia paremmin piilossa pysyvien HTTP-otsakkeiden kautta. Tarkkaan ottaen tämäkin on kyllä ollut rajoitetusti mahdollista, sillä esim. CSS-tyylitiedostoihin on voinut linkittää HTTP-otsakkeilla.
Esihakua voisi myös käyttää hajautettuihin palvelunestohyökkäyksiin (DDOS): jos vaikkapa Googleen murtautunut vahingontekijä sijoittaisi ko. palvelun etusivulle ohjeen ladata esim. Windowsin uusimman service packin Microsoftin palvelimelta, voisi verkkoliikenteen määrä yllättää isommatkin palveluntarjoajat.
DDOS-hyökkäyksiä voidaan tosin hillitä tarjoamalla seurantatietoa siitä, mistä sivulta esihaku tehtiin tai esimerkiksi rajoittamalla esihakua siten, että vain samalla palvelimella tai samassa domainissa olevia URL-osoitteita seurattaisiin esihaussa. Tämä on kohtuullista, mutta ei silti estä pahantekoa täysin; Googleen murtautunut henkilö voisi kyykyttää tosin vain Googlea itseään. Lisäksi on huomattava, ettei domain- tai palvelinrajoitus esihaussa yleensä estä samalla palveluntarjoajalla toimivien kuluttajasivujen tms. välistä häiriköintiä (jos osoitteet ovat esim. muotoa http://www.isp.example/~kayttaja/).
Vaikka DDOS-hyökkäys ei yltyisikään verkkoja ja palvelimia tukkivalle tasolle, kevyempikin liikenteen lisäys voi häiritä esimerkiksi sellaisissa web-hotelleissa, joissa on alhainen kilotavua kuukaudessa -mallinen raja sivustolta sallittavalle liikenteelle. Samaan tapaan voidaan arvioida, etteivät aiheuttamansa liikennemäärän perusteella maksavat www-sivujen ylläpitäjät riemastu vähästäkään lisäliikenteestä. Kevyttä esihakuliikennettä voi kuitenkin olla varsin vaikea havaita, koska sen lähteenä ei ole yksittäinen IP-osoite.
Esihaku saattaa tarjota houkuttelevia käyttömahdollisuuksia sellaisille sivujen tekijöille, jotka ovat mukana sellaisissa mainostusjärjestelmissä, joissa sivun tekijä saa rahaa sillä perusteella, paljonko hän on ohjannut liikennettä mainostetuille sivuille. Ovela webmaster voisi esimerkiksi sijoittaa sivulleen ohjeen esihakea mainostajan etusivu, jolloin käyttäjä tulisi kartuttaneeksi sivuntekijän ansioita, vaikkei ikinä mainosta klikkaisikaan. Mainostajan näkökulmasta tilanne vaikuttaa helposti aivan autenttiselta.
Tämäntyyppiset huijaukset on usein helposti eliminoitu sillä, jos esihakurobotit merkkaavat esihakupyynnöt näkyvästi erilleen, jolloin ne voidaan sivuuttaa esim. mainosjärjestelmien läpiklikkauslukemia laskettaessa. Ei kuitenkaan ole perusteltua olettaa, että kaikki esihakujärjestelmät tulisivat pyyntöjä merkitsemään; Mozilla tosin merkitsee omansa, mutta lähimainkaan kaikki muut toteutukset eivät.
Silloinkin, kun esihaku olisi dokumentin muodon ja käyttäjän surffailutavan ("kulkureittien") puolesta järkevää ja tehostaisi suoritusta, sen käyttäminen ei aina ole mahdollista tai se tuottaa ei-toivottuja sivuvaikutuksia. Tässä luvussa käsitellään joitain huomionarvoisia erityiskysymyksiä, jotka vaikuttavat esihaun käytettävyyteen erityistilanteissa.
Joskus sivuja ei voida hakea etukäteen yksinkertaisesti sen takia, että sivun sisällön muodostaminen on mahdotonta etukäteen. Tämä on luontevasti tilanne esimerkiksi tilausvahvistuksen kohdalla; sitähän ei voida muodostaa eikä tietenkään myöskään hakea ennen kuin sitä edeltävät lomakkeet on täytetty. Hieman kevyemmän luokan esimerkki on sellainen dynaamisesti generoitu sivu, joka näyttää esim. viimeisen puolen minuutin mittaustuloksia verkkoliikenteestä. Tällaisen esihaulla olisi tietenkin huonot seuraukset.
Vastaava vaikutus voi sisältyä myös sellaiseen tilanteeseen, jossa sivun lataamiseen liittyy palvelinpään toimenpiteitä. Jos aiemmin mainitussa käyttöehtojen hyväksymisesimerkissä käyttäjän suostumus kirjataan palvelimella talteen esim. tietokantaan käyttäjän klikattua "Hyväksyn"-linkkiä, jo selaimen esihaku voi aikaansaada merkinnän ehtojen hyväksymisestä. Tämän seikan vuoksi palvelinlogiikkaa sisältävien sivujen esihaku on usein hyvin ongelmallista.
Edellämainittu tapahtumankulku ei ole tietenkään ongelmallinen silloin, kun kontrolli esihakujen toteutuksesta on jätetty sivujen toteuttajalle - kukaan tuskin itse ohjastaisi selainta hakemaan hyväksymissivua edeltäkäsin. NetAcceleratorin kaltaisia ohjelmia on kuitenkin käytössä jo nyt, ja ne saattavat suhtautua hyväksymislinkkeihin mustavalkoisemmin. Tämän vuoksi onkin erityisen tärkeää muistaa HTTP:n GET- ja POST-metodien ero (ks. RFC 2616, luku 9.1: "Safe and idempotent methods") sivuja suunnitellessa: kaikki pysyviä vaikutuksia omaavat toiminnot on syytä sijoittaa post-tyyppisen lomakekäsittelyn taakse.
Joissain tilanteissa ongelmia voi tulla siitäkin, että sivu muodostetaan käyttämällä esimerkiksi selaimen kekseissä, kieliasetuksissa tai vastaavissa olevaa tietoa. Tämä muodostaa hieman samantyyppisen ongelman kuin lomakkeet: helposti löydettävissä oleva URL-osoite ei sisällä kaikkea sivun muodostamiseksi tarvittavaa informaatiota. Osittain tilannetta voidaan helpottaa sillä, että esihakupyynnöt sisältävät selaimen keksit ja asetukset (tämä onnistuu vaivattomimmin silloin, kun esihakutoiminto nimenomaan on selaimessa; esim. välimuistipalvelinten tasolla toteutetussa esihaussa problematiikka on huomattavasti monitahoisempi).
Edellä kuvatun perusteella on kuitenkin selvää, että on olemassa joukko sivuja, joiden tallentaminen on pääsääntöisesti mahdotonta. Keskeiseksi ongelmaksi jää se, miten selaimet voivat tunnistaa tallennuskelvottomat sivut; selainhan ei voi mitenkään sataprosenttisen varmasti päätellä sitä, onko keksi tai jokin kieliasetus vaikuttanut sivun muodostamiseen vai ei.
Periaatteessa HTTP/1.1-protokolla sisältää välineet tällaisten tietojen välittämiseen ja hyvinkin tarkkojen vanhenemisaikojen määrittelyyn, mutta käytännössä tuki näille on usein ontuvaa. Vielä vähemmän vanhenemisaikoja on määritelty älykkäästi ja ajatuksen kanssa. Useilla dynaamisesti generoitavilla sivustoilla onkin joko automaattisesti tai ylläpitäjän toimesta asetettu sellainen vanhenemispolitiikka, jonka mukaan sivuja ei saa varastoida välimuisteihin ollenkaan. Käytännössä valtaosalla dynaamisistakin sivuista esimerkiksi 15 minuutin vanhenemisaika olisi vielä aivan kohtuullinen.
Vanhentumisaikojen epäluotettavuudesta huolimatta ne ovat käytännössä ainoa tapa aistia sivujen esihaettavuutta. Esimerkiksi Mozilla ei varastoi sivuja, joiden HTTP-vastauksessa välitetyt Cache-Control-otsakkeet (ks. RFC 2616, luku 13) sen kieltävät. Tätä voidaankin pitää järkevänä tulkintana. Esihaun hyötyjen irtoaminen dynaamisilla sivustoilla edellyttää kuitenkin myös sivustojen tekijöiden panosta: on esihakualgoritmi miten älykäs tahansa, se ei (oikein toimiessaan) tartu materiaaliin, jonka tallentaminen on kielletty.
On eräitä tilanteita, joissa esihakua ei voida pitää edes käyttäjän etujen mukaisena. Erityisesti tämä ilmenee silloin, kun rajoitetulle kaistalle olisi muutakin käyttöä (esimerkiksi taustalla olevat kopioinnit) ja esihaku siirtää huomattavia määriä materiaalia.
Vastaavan tapainen ongelma ilmenee, kun käyttäjä maksaa verkkoyhteydestään siirretyn tavumäärän mukaan. Suomen oloissa tämä ilmiö on nykyisin melko vieras, mutta monissa muissa maissa kyseessä on tavallinen käytäntö. Tällöin käyttäjän itsemääräämisoikeus ja taloudellinen turvallisuus ovat ristiriidassa esihaun etujen kanssa: koska mikään algoritmi ei toimi negatiivisessa merkityksessä täydellisesti, esihaku väistämättä lisää käyttäjän surffikustannuksia.
Näitä ratkaisuja silmälläpitäen on mielenkiintoinen kysymys siitä, pitäisikö esihakutoiminnon poiskytkeminen mahdollistaa? Kysymykseen on äkkiä ajateltuna helppo vastata kyllä, koska käyttäjän oikeus hallita selaintaan tulisi olla lähes rajaton. Toisaalta Mozilla-projektissa on otettu asiaan kielteisempi kanta, koska katsotaan, että sivustot voivat kuitenkin toteuttaa esihaun Javascriptillä (joka kiistatta on yleisesti ottaen huonompi ratkaisu).
Mozilla-piireissä valittua perustelua voidaan puolustella yleisen www-sivustojen kehityksen näkökulmasta, mutta esihaun ongelmista (erityisesti tietoturva- ja kustannuskysymykset) huolestuneita se ei paljon lohduta. Omien välineiden hallintaa voidaan kuitenkin pitää vielä yleisiä www:n kehitykseen liittyviä periaatteita tärkeämpänä lähtökohtana. Tätä tukee sekin, että esihaun poiskytkemistä ei kuitenkaan voida pitää yleisesti muita haittaavana ratkaisuna (ehkä enemmänkin vielä päinvastoin).
Se, että esihaku lisää palvelinten ja verkkojen kuormaa, tuo sivuvaikutuksena myös vaikutuksensa www-tilastoihin. Koska esihaku on sivulataus siinä missä tavallisetkin lataukset, ainakin sivujen näyttömäärien voi olettaa kasvavan. Tätä voi pitää vääristymänä tai sitten ei - osa webmastereista ehkä haluaisi sivunlataustilaston kertovan ihmisten katsomien sivujen määrän, kun taas osalle sivulatauslukema kelpaa sellaisenaan. Joka tapauksessa on syytä huomioida www-laskureihin luontaisesti liittyvä epäluotettavuus.
Mikäli esihakujen toteuttajat kattavasti ja standardoidusti erottelisivat esihakupyynnöt tavallisista sivunlatauksista HTTP-teknisellä tasolla, ero voitaisiin jollain tavalla huomioida (ainakin palvelimen lokeihin perustuvassa) laskennassa. Ongelmallista tässä on kuitenkin se, ettei esimerkiksi kaikkien esihakujen poistaminen tilastoista ole sekään tyydyttävä ratkaisu: jos esihaku toimii (positiivisessa merkityksessä) täydellisesti, käyttäjän visiitistä ei jäisi mitään tilastojälkiä, koska hän ei tekisi yhtään normaalia sivunlatausta vaan käyttäisi pelkkiä esihaettuja sivukopioita.
Aika näyttää, miten www-tilastot tulevat suhtautumaan esihakuihin. Ongelma on pienehkö niin kauan, kun suosituimmissa algoritmeissa kyse on juuri www-sivujen tekijän valinnasta. Tällöin esihaettavien sivujen joukko pysynee pääosin melko pienenä ja vastaavasti niiden volyymikin jäänee kohtuulliseksi.
Mozillan panostus esihakuun voi merkitä tekniikalle uutta tulemista. On vaikea arvioida, yleistyykö esihaku lähitulevaisuudessa siten, että sillä olisi olennaista merkitystä esimerkiksi palvelinkuormaan tai www-tilastoihin. On kuitenkin selvää, että mikäli Mozillan esihaku on jatkossakin oletusarvoisesti päällekytkettynä ja Mozillan koodiytimeen pohjautuvien selainten leviäminen jatkuu, esihaku tulee vaikuttamaan yhä useampien käyttäjien surffikokemukseen.
Kirjoitushetkellä (tammikuu 2003) tyypillinen web-sivusto ei saane merkittävää etua siitä, että määrittelee linkkejä esihaettaviksi. Saatu suorituskykyparannus ei ole kovin merkittävä, ja esihaun huolellinen toteuttaminen kysyy jonkin verran aikaa ja vaivaa. Toisaalta sellaisissa tilanteissa, joissa esihaun hyötysuhde on merkittävä ja sopivat esihaun kohteet suoraan sivuilta pääteltävissä (esim. ovimattosivut), esihakumääreiden kirjoittaminen on pieni vaiva ja helposti parantaa sivuston käyttökokemusta olennaisestikin. Myös esimerkiksi kuvien esihaku voi olla järkevää - ainakin jos sillä korvataan vastaava Javascript-ratkaisu.
Tärkeintä ehkä kuitenkin tässä vaiheessa on se, ettei esihakua ryhdytä väärinkäyttämään. Se johtaisi helposti siihen, että yhä useammat selaajat kytkevät esihaun pois päältä tavalla tai toisella, mikä johtaa jälleen uudenlaiseen tarpeeseen toteuttaa esimerkiksi Javascript-pohjaisia esihakuja. Joka tapauksessa esihaun muodostuminen yleisesti tehokkaaksi tekniikaksi vaatii selainten kehittymistä. Sitä odotellessa on tärkeää, ettei tekniikan orastavaa uutta nousua lytistetä väärinkäytöllä.
Jouni Heikniemi
25.1.2003
Tämä dokumentti kuuluu sivujeni osioon
Kirjalliset tuotokset / Tietotekniikka.