Accelerated Mobile Pages and Progressive Web Apps, the future of the Web designed by Google

Google’s two latest projects refer to the websites of the future and are mostly focused on content loading speed and user experience. These two issues have become an obsession for Google, not only in terms of the media but also as referents to the whole World Wide Web. Accelerated Mobile Pages (AMP) and Progressive Web Apps (PWA) seek to offer a fast and satisfactory reading experience where friction and frustration are reduced to the minimum and user engagement skyrockets.

AMP is a new way of developing static content web pages so that, when they are rendered by a browser, the loading speed is as fast as possible.

An AMP web page consists of three simple elements:

1. HTML AMP, a traditional HTML document with some restrictions. In the end, these restrictions allow the web page to load at full speed (the enriched content is always handled through extensions).

2. An AMP-specific JavaScript library, responsible for quick HMTL rendering.

3. The AMP cache, which makes it possible for the browser to render an AMP cache (this typical web page element speeds up content loading even more).

PWA aims to add to the quick-loading web page some of the features that ensure the power of native mobile applications, such as push notifications and high availability using a desktop icon, besides always rendering under a secure HTTPs protocol domain.

Google’s idea is to facilitate the load of content always instantaneously, even when the connectivity is not good; ensure quick response to the user’s interactions with smooth animations; and guarantee greater user engagement through an immersive ecosystem.

First steps in AMP’s roadmap for 2017

At the start of this year, Google has made some interesting changes to the AMP roadmap. Google has improved some of the project’s major elements, e.g. it has polished some of the interactive formats such as the galleries, carousels or modules with small images (for example, the forms). Additionally, it has improved the optimization of advertising loading in AMP web pages. And lastly, it has improved analytics, particularly for pages with steppers and forms such as e-commerce (improves data gathering when processes are stringed within a website). 

• Interactive forms: the amp-bind resource allows developers to create interactive formats and modules in addition to the default AMP components, primarily AMP-carousel, AMP-img, AMP-selector and AMP-video. Some of these default elements have also been improved as a result of the requirements of common web projects such as e-commerce, where forms are used extensively. There is also AMP Start, a set of code fragments that act as a fast start-up package that developers can use to create and customize the AMP code on their web pages.
• Advertising: this was one of the major gaps in AMP, which Google has decided to correct during the first quarter of 2017. Moving forward, the rendered code of advertising in AMP will be faster, with an underlying warning background to reduce loading times as much as possible and avoid blank spaces that do not provide any information to the user. Also, Google has improved some fixed advertising formats such as the amp-sticky-ad, which is fixed to the bottom of the interface.
   

• Analytics: Google will soon make it possible to include customized variables as user IDs within the pages to obtain data from stringed processes in the same page, such as a shopping cart or a form, and generate actual metric-related value. This is a major factor in ensuring that AMP expands to vital digital economy sectors and, as such, becomes a commonly used solution. ●      Analytics: Google will soon make it possible to include customized variables as user IDs within the pages to obtain data from stringed processes in the same page, such as a shopping cart or a form, and generate actual metric-related value. This is a major factor in ensuring that AMP expands to vital digital economy sectors and, as such, becomes a commonly used solution.

2017 changes to PWA

One of the latest changes to PWA focuses on improving content loading times, mainly linked to the service worker, a JavaScript file that runs in the background and ensures that PWA pages have the same offline functionality as native applications, for instance. Service workers are located between the customer and the network and act as a proxy to cache content.

To a large extent, the loading speed of this type of page relies on these service workers since they include a shell, a series of HTML, CSS and JavaScript files that are immediately loaded to the interface.

Until now, the service worker returned the result of a request to the browser when requested but this always happened after launching. Under normal conditions, a service worker takes 50 ms on average to launch and serve content the browser is able to render. In mobile devices, this may go up to 250 ms in the fastest models and 500 ms in the slowest models. Even though the service worker stays active in the background between browser requests, sometimes there are requests for a different website or from a different tab.

To correct this situation, Google has changed its approach: instead of beginning to load the request to send it to the browser after the service worker launches, these two actions take place in parallel: the request is the object of a sort of pre-load without having to wait for the service worker. The request could never be served before the service worker launches but this parallel action reduces the times. 

Are you interested in financial APIs? Discover all the APIs we can offer you at BBVA