Mikä on PWA? Mobiilisovellus vai verkko?

01Mitä progressive web app tarkoittaa?

Progressive web app on lähestymistapa, joka lisää tavalliseen verkkosivustoon sovellusominaisuuksia. Käyttäjä avaa sivuston selaimessa ja lisää sen tykätessään yhdellä napautuksella aloitusnäyttöönsä. Seuraavilla kerroilla se käynnistyy sovelluksen tavoin ilman osoiterivia, omalla kuvakkeellaan ja avausnäytöllään.

Nimen sana “progressive” on tärkeä. Sovellus saa ominaisuuksia sen mukaan, mitä selain tukee: vanhassa selaimessa se toimii tavallisena sivustona, nykyaikaisessa selaimessa taas offline-tila, ilmoitukset ja aloitusnäytölle asennus tulevat käyttöön. Kukaan ei jää ulkopuolelle.

Lähestymistavan perustana ovat verkkostandardit; se ei ole sidottu tiettyyn alustaan tai kehykseen. Jokainen Reactilla, Vuella tai pelkällä JavaScriptillä tehty sivusto voidaan muuttaa PWA:ksi oikeilla vaiheilla.

02Kolme osaa, jotka tekevät sivustosta PWA:n

Teknisesti sivuston katsomiseen PWA:ksi tarvitaan kolme perusosaa. Kaikki kolme ovat standardeja, ja viralliset kuvaukset löytyvät esimerkiksi lähteestä web.dev.

{
  "name": "Esimerkkikauppa",
  "short_name": "Kauppa",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0b5cff",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

HTTPS

PWA-ominaisuudet toimivat vain suojatun yhteyden kautta. Sivustolla, jolla ei ole SSL-varmennetta, service workeria ei voi rekisteröidä.

Web app manifest

Manifest on pieni JSON-tiedosto, joka kuvaa sovelluksen nimen, kuvakkeet, teemavärin ja sen, miten se avataan. Selain tekee aloitusnäyttöön lisäämisen ehdotuksen tämän tiedoston perusteella.

Service worker

Service worker on JavaScript-tiedosto, joka sijaitsee selaimen ja verkon välissä. Se tallentaa sivut ja tiedostot välimuistiin, näyttää tallennetun sisällön, kun verkkoyhteys katkeaa, ja hallitsee ilmoituksia tuetuilla alustoilla.

03PWA:n edut

Näistä eduista suurin tuntuu usein kustannuksissa. Kahden erillisen mobiilisovelluksen, kahden erillisen ylläpidon ja kahden erillisen kauppaprosessin sijaan hallitaan yhtä verkkoprojektia. Budjettiin vaikuttavat todellisuudessa näyttöjen määrä, offline-skenaarioiden monimutkaisuus ja yhdistettävät järjestelmät.

• Yksi koodikanta: erillistä kehitystä iOS:lle, Androidille ja työpöydälle ei tarvita.
• Riippumattomuus sovelluskaupoista: päivityksen julkaisu ei odota hyväksyntää; muutos tavoittaa kaikki heti.
• Vähän asennuskitkaa: käyttäjä aloittaa suoraan linkistä ilman käyntiä sovelluskaupassa.
• Näkyy hakukoneessa: koska sisältö on verkkosivu, Google voi indeksoida sen.
• Kevyt: puhelimessa se vie yleensä paljon vähemmän tilaa kuin natiivisovellukset.
• Toimii offline-tilassa: välimuistissa oleva sisältö avautuu heikollakin yhteydellä.

04PWA:n rajoitukset

PWA ei vastaa jokaiseen tarpeeseen; rehellistä vertailua varten rajoitukset on tunnettava.

iOS-tuki on rajoitetumpi kuin Androidissa. Ominaisuudet, kuten aloitusnäyttöön lisäys ja ilmoitukset, ovat kehittyneet ajan myötä, mutta jotkin toiminnot poikkeavat edelleen, eikä asennusehdotus tule automaattisesti; käyttäjän on lisättävä sovellus jaa-valikosta.

Laitteistoon pääsy on myös rajallista. Perusominaisuudet kuten kamera, sijainti ja värinä ovat käytettävissä webissä, mutta Bluetooth-laitteissa, taustalla jatkuvassa sijaintiseurannassa tai raskasta grafiikkaa vaativissa peleissä natiivisovellus on edelleen edellä.

Lopuksi on näkyvyys sovelluskaupoissa. Osa käyttäjistä etsii sovellusta vain kaupasta. Androidissa PWA:t voidaan listata Play Kaupassa tietyillä menetelmillä; iOS:ssä tämä tie vaatii yleensä natiivin kuorisovelluksen.

05Mobiilisovellus vai verkkosivusto?

Tämä kysymys on oikeastaan päätös kolmen vaihtoehdon välillä: mobiiliystävällinen verkkosivusto, PWA ja natiivi mobiilisovellus. Alla oleva taulukko tiivistää erot.

06Millaisille yrityksille PWA sopii?

PWA loistaa eniten tilanteissa, joissa käyttäjä palaa usein mutta ei viitsi ladata erillistä sovellusta. Käyttäjälle, jonka puhelimen muisti on täynnä eikä halua asentaa uutta sovellusta, linkistä avautuva ja aloitusnäyttöön lisättävä kevyt kokemus on usein lyhin tie.

• Verkkokaupat: nopeasti avautuva, aloitusnäytöllä pysyvä kauppa toistuvasti asioiville asiakkaille.
• Ravintolat ja kahvilat: pöydän QR-koodista avautuvat ruokalista- ja tilausnäytöt, joita käytetään ilman sovelluksen lataamista.
• Varaukset ja ajanvaraus: nopea uusintavaraus hotellille, klinikalle tai kampaamolle.
• Kenttätiimit: huolto- tai myyntitiimit, jotka täyttävät lomakkeita paikoissa, joissa yhteys on heikko.
• Sisältösivustot: usein luettava sisältö, kuten uutiset, oppaat ja katalogit.

07Mikä määrittää kustannukset?

PWA-projektin budjetti muotoutuu enemmän laajuuden yksityiskohdista kuin kysymyksestä “sovellus vai sivusto”. Yksinkertaiseen sisältösivustoon manifestin ja välimuistin lisäämisen ja offline-tilauksia vastaanottavan kenttäsovelluksen rakentamisen välillä on suuri ero.

Budjettiin eniten vaikuttavat tekijät ovat näyttöjen ja kulkujen määrä, offline-toimintojen monimutkaisuus, ilmoitusskenaariot, yhdistettävät järjestelmät kuten maksu, varasto tai varaus sekä suunnittelun omaperäisyys. Näihin on lisättävä julkaisun jälkeinen ylläpidon ja päivitysten tarve.

Natiivisovellukseen verrattaessa älä katso pelkkää ensimmäistä kehityskustannusta. Kahden alustan erillinen versionhallinta, kauppapäivitykset ja laitetestaus ovat joka vuosi toistuvia kuluja. PWA:ssa merkittävä osa näistä kootaan yhteen verkkoprosessiin; todellinen säästö syntyy usein juuri tässä.

08Ennen PWA-projektin aloittamista

PWA:n koodipuoli kirjoitetaan enimmäkseen JavaScriptillä; suurissa projekteissa tyyppiturvallisuuden vuoksi suositaan TypeScriptiä. Jos mietit, miten työ jakautuu käyttöliittymän ja palvelimen kesken, artikkelimme frontendin ja backendin erosta selittää asian selkeästi. Perusteista aloittavalle hyvä lähtökohta on artikkelimme Mikä JavaScript on.

1. Korjaa mobiilikokemus: nopea, luettava ja kosketukseen sopiva sivusto on perusedellytys.
2. Aseta nopeustavoite: Core Web Vitals -kynnysarvot (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1) ovat hyvä lähtömittari.
3. Määrittele offline-skenaario: mitä käyttäjän pitää nähdä ja voida tehdä, kun nettiyhteyttä ei ole?
4. Päätä ilmoitusstrategia: pyydä lupaa vasta, kun olet näyttänyt arvon, ei ensimmäisellä sekunnilla.
5. Testaa oikeilla laitteilla: kokeile asennus- ja avautumiskäyttäytymistä erikseen iOS:llä ja Androidilla.