Snart kan du åpne «portaler» i Chrome

I den nye Canary-utgave av Google Chrome er det ny mulig å teste en kommende webteknologi som kalles for portals eller portaler. Den har en god del felles med iframes, men er først og fremst ment for å gjøre overgangen mellom ulike websider mer sømløs.

Det er Google selv som har utviklet teknologien, som på ingen måte er noen webstandard ennå. I stedet er den å anse som svært eksperimentell funksjonalitet.

Google demonstrerte portals under selskapets Chrome Dev Summit i november i fjor. Dette ble gjentatt for et større publikum av Googles Barb Pelser under denne ukens Google I/O-konferanse.

Forhåndslasting og overganger

Ifølge Pelser kan portaler sammenlignes med iframes som du kan navigere til eller bevege deg inn i. Når en bruker åpner en portal, blir den straks den øverste siden i nettleseren, ikke bare et slags kikkhull fra én webside til en annen.

Inkludert i portalkonseptet er også tilknyttede API-er for forhåndslasting (prefetching) og overganger.

I videoen over demonstrerer Pelser hvordan portalene kan gjøre overganger mellom innhold på ulike nettsteder så sømløst at det føles som én og samme opplevelse.

I demoen er Pelser inne på et tenkt nettsted for måltidsplanlegging. Dette nettstedet lister en mengde matoppskrifter fra andre nettsteder.

Dette nettstedet er dessuten integrert med et eksternt, sosialt nettsted hvor det er mulig å lagre og dele oppskriftene.

Skifter adresse

Når Pelser klikker på deleknappen, vises et kort med innhold som egentlig en webside på det sosiale nettstedet. Denne siden er åpnet i en portal. Brukeren har da nokså umerkelig flyttet seg til domenet til det sosiale nettstedet, noe som vises i adressefeltet. Samtidig ser det ut som om kortet vises foran den opprinnelige siden hos måltidsplanleggingsnettstedet.

Ifølge Pelser er dette mulig takket være adoptPredecessor-funksjonen i portalene, som lar den opprinnelige siden dele kontekst med destinasjonssiden, ved at den nå hentes inn som et nytt portal-element.

Etter at Pelser har lagret oppskriften på det sosiale nettstedet, stenger hun portalen og blar videre i oppskriftene på planleggingsnettstedet.

En fordel med portaler, kan demonstreres ved å se på avspillingen av videoen over. Starter du den og ønsker å se om det er noen kommentarer under den, er dette selvfølgelig fullt mulig, men ikke uten at det blir et opphold i avspillingen når YouTube-siden åpnes. Siden åpnes dessuten i en separat fane, men akkurat skyldes et bevisst valg fra YouTubes side og ikke en teknologimangel.

Uten avbrudd

Med bruk av portaler ville avspillingen kunne fortsette uten avbrudd, som demonstrert i denne videoen – hvor det riktignok er en podcast som avspilles.

Et tilsvarende nettsted for måltidsplanlegging vil i dag kanskje lenke direkte hver oppskrift på oppskriftsnettstedet, men i demoen lastes oppskriftsoppføringene i stedet i portaler. Fordi innholdet i portalen er forhåndslastet, går det for eksempel raskt å ta en sniktitt på enkelte av oppskriftene, uten å forlate planleggingsnettstedet.

Sender brukerdata

Når Pelser til slutt finner en oppskrift hun vil bruke, og klikker på denne oppføringen for å gå til selve oppskriften, så skjer det en svært rask overgang mellom sidene, uten den vesle ventetiden som gjerne oppstår når man blar fra én side til en annen.

Fra oppskriftsiden, som Pelser nå har navigert til, er det mulig å sende listen med ingredienser til et fjerde nettsted, som inneholder hennes handleliste. Med et musklikk eller skjermtrykk så legges ingrediensene i oppskriften til i handlelisten, som i demoen også vises i en portal.

Dette er mulig fordi funksjonen activate, som sørger for overgangen til portalen, kan inkludere valgfrie argumenter for å sende data fra den opprinnelige siden og til destinasjonssiden som vises i portalen.

Animasjonen over viser hvordan et portalelement først legges til i forkant av en webside og deretter aktiveres i det brukeren klikker på portalinnholdet. Animasjon: Google.

For webapplikasjoner med flere sider

Ifølge Pelser kan portaler også gi bedre opplevelser selv om alt innholdet er hentet fra samme nettsted.

Spesielt gjelder dette webapplikasjoner som avhenger av å skifte mellom flere ulike websider, noe som ofte enklere å få til enn å inkludere hele applikasjonen i én eneste webside. Problemet med flere sider er selvfølgelig at vekslingen mellom sidene ikke alltid oppleves som sømløs og elegant.

Med portaler kan denne lastingen og renderingen av innholdet skje i bakgrunnen mens brukeren vises en fiffig overgang. Dette kan man i og for seg også gjøre ved å bruke iframes, men da vil nettleseren egentlig fortsatt være på den opprinnelige siden, og brukeren mister da de navigasjonsmulighetene som er noe av det sentrale med portalene.

Google har gitt ut et blogginnlegg hvor portalfunksjonaliteten er nærmere beskrevet. Selve spesifikasjonen er tilgjengelig her.

Lazy Loading

Mens portaler til dels handler om å forhåndslaste innhold slik at det kan vises straks brukeren ber om det, er lazy loading nesten det motsatte. Også dette ble omtalt under Google I/O. Se videoen nedenfor.

Ifølge Google inneholder en gjennomsnittlig webside dobbelt så mye bildedata som de gjorde for bare tre år siden. Selv om mange har fått raskere internettforbindelse i løpet av denne perioden, kan det i mange sammenhenger ta ganske lang tid å laste ned alt innholdet.

På enheter på litt begrensede ressurser kan dessuten lasting av bilder føre til at enhet låser seg litt før alt har kommet på plass. Mye av dette kan være bilder som brukeren kanskje aldri kommer til å se, fordi brukeren for eksempel finner ut at dette ikke var en interessant side likevel og straks navigerer seg bort fra den.

Ved behov

Med lazy loading lastes kun de bildene som er på den delen av websiden som er synlig i nettleseren. Når brukeren scroller nedover på siden, vil bildene lastes ned og vises ved behov.

Nøyaktig den samme problemstillingen kan gjelde iframes, så lazy loading fungerer også med dette.

Å ta dette i bruk er temmelig enkelt. Det hele er basert på en ny attributt i img- eller iframe-elementet kalt loading. Attributtet støtter tre ulike verdier, lazy, eager og auto, som indikerer hvor godt egnet elementet er for utsatt lasting.

Standardverdien er auto, så dersom loading-attributtet ikke er oppgitt, vil nettleseren selv bestemme når bildet eller iframe'en bør lastes. Eager indikerer at det dreier seg om et element som ikke er godt egnet for utsatt lasting, mens lazy selvfølgelig indikerer det motsatte.

Mer kontroll

Det er mulig å endre verdien til loading-attributtet fra for eksempel lazy til eager etter at lastingen av elementet allerede har blitt utsatt, dersom det ønskes mer kontroll over når lastingen faktisk skal foregå.

Det allerede finnes JavaScript-biblioteker som tilbyr tilsvarende funksjonalitet til nettlesere som ikke har innebygd støtte for lazy loading. Ett eksempel er LazySizes.

Det er tilsynelatende noen fordeler med den innebygde løsningen i Chrome, i tillegg til at den nok er enklere å bruke. Blant annet registrerer nettleser nedlastingshastigheten mellom brukeren og webserveren, slik at den bedre kan beregne når nedlastingen bør starte. I tillegg laster nettleseren ned de to første kilobytene av hvert bilde for å kunne avgjøre mye plass på siden som skal settes av til dette bildet.

Google har implementert støtte for lazy loading i den nyeste Canary-utgaven av Chrome 76.

Flere detaljer om lazy loading finnes både her og her.

I likhet med portalene, er ikke lazy loading noen webstandard. Så langt er det knapt noe mer enn et forslag som Googles ingeniører er i ferd med å implementere. Om det vil støttes av andre nettlesere, er foreløpig uvisst.