Innhold
- 01. Server over HTTPS
- 02. Opprett et applikasjonsskall
- 03. Registrer en servicearbeider
- 04. Legg til pushvarsler
- 05. Legg til et webapp-manifest
- 06. Konfigurer installasjonsprompten
- 07. Analyser appens ytelse
- 08. Kontroller appen din med Lighthouse
Mobil står nå for over halvparten av internettrafikken, og nettapplikasjoner gjør det mulig for brukere å gjøre ting i nettleseren som konkurrerer med innfødte apper, men det er et problem: kvaliteten på tilkoblinger og enheter varierer enormt over hele verden.
Catering både til brukere på lynraske forbindelser i Seoul, og brukere i India på en utdatert telefon, er den siste utfordringen for brukervennlighet, og Progressive Web Apps er løsningen.
PWA-er bruker progressiv forbedring for å laste inn det viktigste innholdet først, og deretter legge til presentasjons- og funksjonelle tilleggsutstyr etter behov, noe som betyr at alle brukerne dine får den samme kjerneopplevelsen så raskt som mulig. Hvis du vil nå et bredest mulig publikum, er PWA-er veien å gå.
- 10 trinn til en engasjerende brukeropplevelse
Selv om Progressive Web Apps gir mange fordeler og funksjonalitet til nettet, krever de ikke omskriving av hele applikasjonen. Enhver app kan konverteres til en PWA ved å legge til noen ekstra lag i den.
For best resultat, vil du legge stor vekt på ytelse fra begynnelsen - men det gjelder alle nettapper. Her går vi gjennom trinnene for å gjøre appen din progressiv.
Hvis du vil bygge et jevnt løpende nettsted, må du sørge for at webhotellet ditt er perfekt og bruke en anstendig nettstedbygger.
01. Server over HTTPS
La oss være ærlige: du burde gjøre dette uansett. SSL legger til et ekstra sikkerhetslag på nettet, slik at brukerne dine føler seg trygge når de bruker nettstedet ditt. Med PWA er HTTPS viktig for å bruke servicearbeidere og tillate installering av startskjermen. Du kan kjøpe et SSL-sertifikat fra domeneregistratoren din med liten kostnad og deretter konfigurere det gjennom hostingtjenesten din.
02. Opprett et applikasjonsskall
Appskallet ditt er det første som lastes inn - det første brukeren ser. Det bør eksistere helt i indeksen ditt HTML-dokument, med innebygd CSS, for å sikre at det vises så raskt som mulig, og at brukeren ikke stirrer på en hvit skjerm lenger enn nødvendig. Søknadsskallet er en del av mønsteret for progressiv forbedring. Appen din skal gi brukerinnholdet så snart som mulig, og deretter gradvis forbedre det etter hvert som mer data (sannsynlig JavaScript) lastes inn.
Eksemplet nedenfor er hentet fra et React.js-program. Brukeren får en oversikt over appen og en lastindikator i index.html. Så når JavaScript lastes inn og React starter opp, blir hele applikasjonen gjengitt i skallet.
! - index.html -> body> div id = "root"> div id = "container"> div> div id = "header"> img src = "/ assets / icon.png" alt = "logo" /> h1> Chat / h1> / div> div id = "loading-container"> img src = "/ assets / icon.png" alt = "logo" id = "loader" /> / div> / div> / div> / div> / body> // index.js ReactDOM.render (App />, document.getElementById ('root'));
03. Registrer en servicearbeider
For å utnytte hele spekteret av PWA-godbiter (push-varsler, caching, installeringsanvisninger) trenger du en servicearbeider.
Heldigvis er de ganske enkle å sette opp. Nedenfor sjekker vi først om brukerens nettleser støtter tjenestearbeidere. Så, i så fall, kan vi gå videre med å registrere tjenestearbeiderfilen, her kalt service-worker.js. Vær oppmerksom på at du ikke trenger noe spesielt i den filen på dette tidspunktet - den kan være tom.
I eksemplet nedenfor viser vi imidlertid hvordan du kan utnytte de tre viktigste livssyklushendelsene for tjenestearbeidere. Dette er 'installer' når brukeren først besøker siden din; ‘Aktivere’, rett før registreringen er fullført; og 'hente', når applikasjonen sender en nettverksforespørsel. Den siste er relevant for caching og offline-funksjonalitet.
skript> hvis ('serviceWorker' i navigatoren) {window.addEventListener ('load', function () {navigator.serviceWorker.register ('service-worker.js'). deretter (funksjon (registrering) {// Registreringen var vellykket) console.log ('Registrert!');}, funksjon (err) {// registrering mislyktes :( console.log ('ServiceWorker-registrering mislyktes:', err);}). fangst (funksjon (err) {console.log (err);});});} annet {console.log ('servicearbeider støttes ikke');} / script> // service-worker.js self.addEventListener ('install', function () {console .log ('Install!');}); self.addEventListener ("aktiver", event => {console.log ('Activate!');}); self.addEventListener ('fetch', function (event) { console.log ('Fetch!', event.request);});
04. Legg til pushvarsler
Tjenestearbeidere tillater brukerne dine å motta push-varsler via Push API på nettet. For å få tilgang til det, kan du bruke self.registration.pushManager fra tjenestearbeiderfilen din. Siden sending av push-varsler er sterkt avhengig av backend-oppsettet ditt, vil vi ikke dykke inn i det her.
Hvis du starter en app fra bunnen av, kommer Googles Firebase-tjeneste med Firebase Cloud Messaging for relativt smertefrie pushvarsler (husk: sørg for at du holder designfilene dine trygge i skylagring). Koden nedenfor viser hvordan du registrerer deg for push-varsler via Push API.
navigator.serviceWorker.ready.then (function (registrering) {if (! registration.pushManager) {alert ('No push notifications support.'); return false;} // For å abonnere på 'push-varsling' fra push manager registrering.pushManager .subscribe ({userVisibleOnly: true // Vis alltid varsel når det mottas}). deretter (funksjon (abonnement) {console.log ('Abonnert.');}) .catch (funksjon (feil) {console.log ('Abonnement) feil: ', feil);});})
05. Legg til et webapp-manifest
For å gjøre applikasjonen din installerbar, må du inkludere en manifest.json i programmets rotkatalog. Du kan tenke på dette som en beskrivelse av søknaden din, i likhet med hva du kan sende til App Store. Den inkluderer ikoner, en sprutskjerm, et navn og en beskrivelse.
Det er også noen konfigurasjoner for hvordan applikasjonen din vises når den startes fra brukerens startskjerm: Vil du vise adressefeltet i nettleseren eller ikke? Hvilken farge ønsker du at statuslinjen skal være? Og så videre. Merk at en skikkelig manifest.json bør inneholde et komplett spekter av ikonstørrelser for forskjellige enheter. Koden nedenfor er en forhåndsvisning av noen av egenskapene manifestet ditt kan inneholde.
{"short_name": "Chat", "name": "Chat", "icons": [{"src": "/ assets / icon.png", "sizes": "192x192", "type": "image / png "}]," start_url ":" /? utm_source = startskjerm "," background_color ":" # e05a47 "," theme_color ":" # e05a47 "," display ":" frittstående "}
06. Konfigurer installasjonsprompten
Når en bruker besøker en PWA med en tjenestearbeider og et manifest, vil Chrome automatisk be dem om å installere den på startskjermen, gitt følgende: brukeren må besøke nettstedet to ganger, med fem minutter mellom besøk.
Tanken her er å vente til brukeren viser interesse for applikasjonen din, og deretter be dem om å gjøre det til et inventar av enheten (dette er i skarp kontrast til den innfødte app-tilnærmingen, som ber om investeringen foran).
Men det kan være tilfeller der du vil vise installasjonsprompten i forskjellige situasjoner, for eksempel etter at brukeren tar en spesiell nyttig handling. For å gjøre det, fanger vi opp før installeringsprompt hendelse og lagre den til senere, og distribuer deretter ledeteksten når vi ønsker det.
window.addEventListener ('beforeinstallprompt', e => {console.log ('beforeinstallprompt Event sparket'); e.preventDefault (); // Stash hendelsen slik at den kan utløses senere. this.deferredPrompt = e; returner false; }); // Når du vil utløse ledetekst: this.deferredPrompt.prompt (); this.deferredPrompt.userChoice.then (choice => {console.log (choice);}); this.deferredPrompt = null;
07. Analyser appens ytelse
Ytelse er hjertet og sjelen til PWA. Appen din skal være rask for brukere under alle nettverksforhold. Caching og offline-funksjonalitet hjelper mye, men på slutten av dagen bør søknaden din være rask, selv om brukeren ikke har nettleseren til å støtte servicearbeiderteknologi. Dette er definisjonen av progressiv forbedring - gi en flott opplevelse for alle, uavhengig av enhetsmodernitet eller nettverksforhold.
For å gjøre det er RAIL-systemet et nyttig sett med beregninger. RAIL er det som Google kaller en 'brukersentrert ytelsesmodell' - et sett med retningslinjer for måling av appens ytelse.
Forkortelsen står for Respons (hvor lang tid det tar før appen din reagerer på brukerhandlinger), Animasjon (holder animasjonshastigheten på 60 bilder per sekund), inaktiv (bruker tid når appen din ikke gjør noe annet for å laste inn og cache ekstra ressurser) og Last inn (laster appen din på ett sekund eller mindre).
Her er en tabell med meningsfylte referanser for applikasjonslasting, som levert av Meggin Kearney, teknologforfatter på Google Web Fundamentals.
08. Kontroller appen din med Lighthouse
Google er den største mesteren som driver Progressive Web Apps som fremtiden for nettet. Som sådan har den levert et nyttig verktøy for å veilede din PWA-utvikling.
Tidligere kalt Lighthouse og ble levert som en Chrome-utvidelse. Fra og med Chrome 60 er den en del av Chrome DevTools, under fanen 'Revisjoner'. Hva Lighthouse gjør er å kjøre søknaden din under forskjellige forhold og måle respons og suksess i henhold til PWA-retningslinjer. Deretter gir den deg en poengsum på 100. Den kan også score appen din på beste praksis på nettet samtidig.
Følgende tekst er en liste over verdiene Lighthouse målt. I bruk viser også beskrivelser.
- Registrerer en servicearbeider
- Svarer med en 200 når den er offline
- Inneholder noe innhold når JavaScript ikke er tilgjengelig
- Bruker HTTPS
- Omdirigerer HTTP-trafikk til HTTPS
- Sidelast er raskt nok på 3G
- Brukeren kan bli bedt om å installere Web-appen
- Konfigurert for en tilpasset sprutskjerm
- Adressefeltet samsvarer med merkevarens farger
- Har en meta name = "viewport"> tag med bredde eller innledende skala
- Innholdet er riktig størrelse for visningsområdet
Denne artikkelen dukket opprinnelig opp i Web Designer; abonner her.
