Techblog

All about web

Future of the web is fast, immersive and usable

4 months ago · 8 MIN READ
#frontend  #amp  #web  #pwa  #webxr 

It has never been more exciting times for the web than now. While there was much cool stuff launched at Google IO '18, there is a lot to cheer about for the web developers. Some of the most exciting ones are on AMP (Accelerated Mobile Pages), PWA (Progressive Web Apps) and WebXR (immersive web AR + web VR). These modern web technologies pan right at the centre of the future of the web. Let's look where these technologies stand:

AMP (Accelerated Mobile Pages)

AMP is a library that helps create web pages that are compelling, smooth, and load near instantaneously for users; learn more. AMP is built with 3 core-components:

  1. AMP HTML (HTML with some restrictions)
  2. AMP JS (fast rendering JavaScript library)
  3. AMP Cache (Google cache server)

To learn more about these AMP core-components or to get started with AMP development visit: http://rahul.my/amp.

At the technical front, AMP leverages 2 main aspects to deliver content that loads fast and renders equally faster, those are:

Fast Content Delivery:

AMP caches a valid AMP page to Google AMP cache server (multiple edge server locations) and delivers to the consumers from the nearest location that reduces the network time to a great deal. On top of that, Google Search Result Page (SERP - Search Engine Result Page) preloads AMP pages in the background keep them ready to be consumed directly from the result page; hence page loads instantaneously.

Note: The median load time of AMP page is under 1 sec worldwide.

Fast Page Rendering

AMP Javascript library is designed to render fast by only allowing asynchronous scripts and cutting down all 3rd party extensions and javascript and only allow them to be loaded in <amp-iframe>. It also enforces to size all resources statically so that the layout of the page can be calculated before the resources are downloaded. All CSS is inlined and has a size limitation of up to 50Kb only. Learn more.

The result of the above is stunning webpage that loads fast! here's an example of popular news sites like Guardian and BBC:

Though the AMP pages work great and load amazingly fast, they were designed with a little caveat, which is more of a trade-off. When an AMP page is loaded from a SERP it is loaded directly from the AMP cache edge server resulting in the URL in the browser to be of the AMP cache server (https://www.google.com.sg/amp/www.example.com).

Challenge and trade-off

The rationale behind the design of AMP was to cater to allow instant loading of a page without sacrificing the privacy of the users. AMP preloads the cached search AMP pages in the background while showing the results to its users, which allows AMP pages to be loaded instantly and allowing publishers to know what users been searching will be a major privacy flaw, hence the pages are loaded directly from the cache which results in the URL to be shown as google.com/amp as prefix.

At the Google IO '18, it was announced that AMP has found a solution to this trade-off using Web-Packaging.

Web Packaging

Web packaging is a standard which allows a publisher to sign an HTTP exchange (request/response pair) using a certificate, which when delivered as a package to the browser can show the publisher's origin URL. Caching server works to actually delivering that exchange to a browser and the package is sent over HTTPS to the cache server. This feature is still under experimental phase and can be enabled on chrome browser from flags chrome://flags#enable-signed-http-exchange. AMP has also launched AMP packager to make it easier for developers to develop signed packages and push it to AMP cache server with ease. It is still very early build but ready for experimentation and can be found here https://github.com/ampproject/amppackager.

Key details about AMP packager

  • Signs the AMP pages that can be consumed by AMP Cache
  • Package is signed with a certificate
  • That certificate’s origin URL will be shown in the browser URL bar which solves the biggest trade-off of AM
  • Max lifetime of the package is 7 days
  • The AMP packager is an HTTP server that sits behind a Frontend server which fetches and signs AMP documents as requested by the AMP Cache.

How to use the AMP packager

  • Configure frontend server to serve certificate and amp packages
  • Setup an URL mapping between AMP URL and corresponding package URL, in the instance below a .htxg extension has been used to correspond to the package file:
  • https://example.com/url/to/amp.html --> https://example.com/url/to/amp.html.htxg
  • Frontend reverse proxies such a request to something like this:
    http://packager.internal/priv/doc?sign=https%3A%2F%2Fexample.com%2Furl%2Fto%2Famp.html

Certificates

  • AMP Packages will contain a certUrl that indicates the certificate that can be used to validate the package. The certUrl may be on any domain, and it may be HTTP or HTTPS, but it will have a path of the form

    /amppkg/cert/<base64 encoding of a hash of the public certificate>

Packager

  • Receives reverse-proxied requests from the frontend
  • Makes an outgoing connection to cdn.ampproject.org on port 443
  • Sends the package to AMP Cache

Signed HTTP Exchange Enabled Browser

  • Loads AMP packager from AMP cache edge server
  • Displays the package's signed origin URL on the browser address bar.

More info at https://github.com/ampproject/amppackager

AMP Stories

Another interesting product that was launched at IO'18 was AMP stories which allow developers, and publishers to immerse readers in tappable, full-screen content which is developed on top of AMP technology and is fast and open. It brings Instagram/Snapchat like full-screen visual storytelling experience to conveys information using images, videos, graphics, audio, and more.

AMP story components

amp-story-components.png

An HTML page can contain a single AMP story <amp-story> which can house multiple <amp-story-page> and each page can have multiple <amp-story-grid-layer> which provides a building block for HTML/AMP elements to fit in a template.

A basic HTML page with AMP story code snippet will look like this:

<!doctype html>
<html ⚡>
  <head>
    <meta charset="utf-8">
    <title>My Awesome AMP story</title>
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <script async custom-element="amp-story"
        src="https://cdn.ampproject.org/v0/amp-story-1.0.js"></script>
  </head>
  <body>

    <amp-story standalone
        title="Joy of Pets"
        publisher="AMP tutorials"
        publisher-logo-src="http://example.com/assets/AMP-Brand-White-Icon.svg"
        poster-portrait-src="http://example.com/assets/cover.jpg">
      <amp-story-page id="cover">
        <amp-story-grid-layer template="fill">
          <amp-img src="http://example.com/assets/cover.jpg"
              width="720" height="1280"
              layout="responsive">
          </amp-img>
        </amp-story-grid-layer>
        <amp-story-grid-layer template="vertical">
          <h1>The Joy of Pets</h1>
          <p>By AMP Tutorials</p>
        </amp-story-grid-layer>
      </amp-story-page>

  </body>
</html>

You can check out a sample amp story I created from some of the moments I captured at Google IO'18 here:

PWA (Progressive Web Apps)

PWA, in my opinion, is one of the most significant improvements to the web in recent history. PWA provides a reliable, fast and engaging means for the web, it can beat the slow internet speeds by allowing websites to work offline, and allow easy availability by letting them add to home screen. PWAs are fast and runs reliably in different network conditions and allows to have app-like smooth animations. They also support full-screen experience and push notification to engage users.

The core of a PWA is a service worker, the basic architecture of service workers looks like this:

service_workers.png

Service workers live in the browsers, works with various APIs like Cache API and help cache important assets in the user's local browser and help in loading website fast, which is one of many features of service workers. They key useful features of service workers in context to PWA are:

  • Is a JavaScript Worker, so it can't access the DOM directly.
  • Use Promises.
  • Runs in the background, separate from a web page.
  • Supports push notification, background sync.
  • Acts like a programmable network proxy.
  • It's terminated when not in use and restarts when needed.

Initially, the service workers were only available to Google Chrome, however, just a couple of months back in March Apple announced the support for service workers for Safari 11.4 on iOS and MacOS. Around the Google IO'18 time, Microsoft also takes a step forward and shipped the support for service workers on Microsoft Edge browser, that means now web developers can develop future-proof PWAs for their users without worrying much about the support for major modern browsers. More information on support for service workers can be found here.

New features in PWA

At Google IO'18, PWA for desktop was announced for the first time, that would mean now developers can develop a similar app like experience for their users. As it might sound intriguing, but is pragmatic. As some of the facts that were shared at Google IO'18 which can be seen in the video here. Summarized here:

The number of global users shows desktop users are still increasing. global_mobile_desktop_users.jpg

Here's the each of these platforms average daily impressions by hour: platform_average_users.jpg

and desktop usage during the average working hours shows upward trends. percent_average_daily.jpg

These pictures clearly show there is a great opportunity for PWAs on the desktop. PWA can provide an edge for developing productivity tools, games and some quick tools for work that doesn't require heavy installation files on a computer, rather have a simple and easy to 'install' add to home screen icon to allow users to discover apps easily.

Other key features for PWA that were announced at Google IO 2018 were: Now chrome won't display the installation prompt by itself, rather, developers have to register Window.addEventListener("beforeinstallprompt") to be able to make app installable. Scope attribute has been made compulsory in manifest.json file in order to keep users in the scope of the PWA application. If the user navigates outside the scope, it returns to a normal web page inside a browser tab/window. Currently, the PWA for desktop is an experimental feature available on Google Chrome Canary. To play around you can enable this chrome flag chrome://flags/#enable-desktop-pwas

I tried to play around with pokedex.org PWA app as below, and it just works!

pokedex_pwa.jpg

WebXR (Web AR & Web VR)

XR => AR + VR: Augmented Reality or Virtual Reality

AR = Brings the virtual world to you VR = Brings you to the virtual world

AR and VR are not new technologies however they were most widely available to native apps like Android, and iOS platforms. However, with the advent of immersive web technologies, led by major web companies like Mozilla and Google, the future of the web looks more immersive than ever before. Mozilla has been doing great work in this field for many years, at Google IO'18, Google announced and showcased various AR and VR on web samples that were not only cool but also very useful. They render as smooth as native apps, widely accessible using common smartphone hardware. In my opinion, AR and VR content fits right on the web, as it makes consumption of such experiences natural and accessible. Think of a scenario where you are researching or learning about something new on some news website, and while reading you can also dig deeper and immerse into the AR world, without a need to install huge mobile apps, wait for it to finish, even worse (sign up in most cases) before even you can have a single bit of experience on AR content you need to go through multiple steps, but not anymore! Such a concept was showcased at the Google IO, Chacmool AR in chrome canary. AR fits greatly under the conventional web ecosystem, around 100 million phones and tablets are capable of playing AR web content, and most of them (if not all) have a web browser, and that's pretty much is what's required to develop immersive content for a website.

Whats new in WebXR?

  • Serves as a foundation for immersive web
  • Replaces the deprecated WebVR API
  • Allows more and more people to be able to use WebVR
    • not just limited to VR devices
    • Enables AR functionality
  • Magic Windows support for VR
  • Enables browsers to add more optimization

Comparing the WebVR, WebXR can pack 2x the pixels at the same frame rate, Default frame buffer size on a Pixel XL for webVR is 1145 x 1807 (~ 2M pixel) however, with WebXR its possible to get 1603 x 2529 (~4M pixels).

WebXR for VR supports Magic windows, that allows users to view 360º content without a need of VR headset. A device's gyroscope or panning-support can be used to consume VR content on Smartphones. It is also capable of viewing monoscopic view of a 3D scene and updates it based on the device's orientation sensors.

To get started

  • Early builds are supported on Chrome Canary >= v69.0.3453
  • Chrome://flags/#webxr
    • Enable #webxr and #webxr-hit-test flags

Sample code.

WebXR has great potential and can be used to create web experiences for various use-cases like shopping, education, entertainment and much more.

With the latest advancements in web technologies, it's very apparent that the future of the web is fast, web and usable!

Helpful resources and credits:

https://www.ampproject.org/

https://codelabs.developers.google.com/

https://developers.google.com/

https://github.com/immersive-web/

···

Rahul Sharma

Product Enthusiast & a clean coder. Strong believer of attention to detail, hungry for optimisations and making things better.

    comments powered by Disqus


    Copyright © Rahul Sharma, 2017 · Sign In