How long will a user wait for a mobile/web page to load?
40% of the users will leave the page if it loads more than 3 secs.
But the fact is most of the sites take around 6.9 seconds to load which is more than double the amount of time 40% of the users wait before quitting the page.
The worst thing is that the users will not only quit from the page, but 79% of users won’t come back once they had a slow experience on a web page.
To ensure that the users should not bounce from the web pages due to slow loading its significant to amplify the pages.
What is AMP?
- AMP is an open-source HTML framework, introduced by Google in October of 2015.
- It was developed to optimize the speed of the web pages.
- AMP is used for designing fast-loading web pages without losing page layout.
- AMP’s main intention is to provide a lightning-speed and interesting experience to mobile/website users, making mobile content faster and easier to consume.
- With AMP, we can create fast and smooth-loading websites that give priority to user experience.
How do AMP pages load instantly?
AMP restricts some HTML/CSS and JS and allows faster rendering of mobile web pages.
AMP pages are automatically cached by Google AMP cache and render faster loading on Google search.
The Pros and Cons of AMP:
How AMP works?
AMP pages are built with the following 3 core components:
- AMP HTML
- AMP JS
- AMP Cache
AMP HTML is a normal HTML with some restrictions for better performance.
Normal HTML tags are used in AMP HTML but some are replaced with AMP-specific tags(custom tags).
AMP JS is a library for the fast rendering of AMP HTML and manages the loading of the custom Html tags.
AMP Cache, a proxy-based content delivery network (CDN) for delivering valid AMP documents. It automatically improves performance since it loads the document, images, and JS files from the same place that uses HTTP 2.0 for max efficiency. Also, AMP cache comes with a built-in validation system.
How to Setup Accelerated Mobile Pages?
Accelerated mobile pages can be developed from standard HTML websites where few adjustments must be made:
- At the beginning of each AMP HTML document there should be <!doctype html>.
- An AMP page must have a <html ⚡> tag with symbol (<html amp> is accepted as well).
- <head> and <body> tags must be added(They are optional in HTML).
- There should be canonical tag <link rel=”canonical” href=”$SOME_URL”> where the URL refers to the original non-AMP html page or to itself(AMP page) if no such HTML version exists. If we add the original HTML URL to the canonical tag, search engines include the original non-AMP page also in the search results, and if no such html version exists, it will only include the AMP version in the search results
- <meta charset=”utf-8"> tag must be added as the first child of the head tag.
- <meta name=”viewport” content=”width=device-width,minimum-scale=1"> must be added for the AMP pages to be perfectly adjusted to the respective output screen.
- The AMP runtime is loaded via the mandatory <script async src=”https://cdn.ampproject.org/v0.js"></script> tag which is added inside the head tag.
- AMP boilerplate code (head > style[amp-boilerplate] and noscript > style[amp-boilerplate]) has to be added in the head tag. Refer the AMP boilerplate code here.
Below is an example of the basic setup:
Now the basic setup for creating an AMP page has been done. Now let’s see how to add the custom AMP HTML tags and styling the AMP pages.
Adding Custom AMP HTML Tags
Some of the normal HTML tags are replaced by the custom AMP tags with a prefix amp. Here is a list of tags that replace their HTML counterparts to optimize resource loading and enforce best security practices:
- [amp-img] — Replaces the img tag and optimizes resource loading by taking into account factors such as viewport position, system resources, and connectivity.
- [amp-video] — Replaces the HTML5 video tag, so that video content can be lazily loaded (considering the viewport)
- [amp-audio] — Replaces the HTML5 audio tag so that audio content can be lazily loaded (considering the viewport).
Example for inserting an image in the AMP Document:
Adjust the HTML code to display the images on the AMP pages properly:
- Replace the img tags in the source code — <img src> with <amp-img src>
- All externally loaded resources must have width, height, and layout properties specified to calculate a final layout as quickly as possible.
- These are the supported layout values — fill, fixed, fixed-height, flex-item, intrinsic, nodisplay, and responsive.
Here is an example of an <amp-img src> tag.
Styling AMP HTML
AMP documents can be styled with standard CSS and while styling, keep in mind several things:
- AMP styling must be done with an inline style sheet. Externally linked style sheets and element-level inline styles are not allowed since externally linked style sheets would require an additional document to be downloaded before the layout could be calculated.
- Styles are limited to 50 KB.
- Inline style sheet must have the <style amp-custom>attribute.
- The @ rules like @font-face, @keyframes and @media are allowed.
- The !important qualifier is banned.
Here is an example for adding styles to an AMP HTML:
We’ve seen how to create a basic AMP HTML page and styling it. Let us see how to make those pages more dynamic by adding custom JS.
1.From a remote URL
2. From a local element
- Set the script attribute of the amp-script to the local script element’s id.
- Include target=”amp-script” in the script.
- Include type=”text/plain” in the script. This way, the browser won’t execute the script, allowing amp-script to control it.
How does it work?
AMP mainly focuses on the web pages’ speed and performance. AMP has some restrictions over the HTML, CSS, and JS that a developer could embed into a web page to increase the page rendering speed. So, AMP alone will not be suitable for web pages with complex requirements and designs.
Although AMP has fantastic speed and performance, it has not been as popular as PWA(Progressive Web App). One of the main reasons behind this is AMPs’ limited features. Both PWA and AMP are different from each other, and they also achieve a separate set of goals. AMP’s uniqueness lies within the lightning-speed, while PWA provides features like working offline, push notification, and caching.
Let’s see how to combine AMP and PWA.
Before that, if you are not aware of PWA, please refer to the PWA blog.
PWAs with Amp
PWAs work through a technology called Service Worker, a client-side proxy that only kicks in after the second request which means that the first time a user loads a site, it could load slow.
We all know, the slower the site’s load time, the higher the bounce rate will be, which brings mobile/websites to trouble, even those using PWA. To overcome this, all PWA users have to do is increase that initial load time.
And that’s where AMP comes in.
If both were integrated, it would allow them to “deliver fast initial loading and reliable second-visit performance, and also advanced features like offline reading and richer UI treatment.”
How to Integrate PWAs and AMP?
There are three ways to integrate PWA and AMP
- AMP as PWA
- AMP to PWA
- AMP in PWA
AMP as PWA
For sites with static activity and not much interactivity, we can have an AMP that’s also a PWA.
In AMP as PWA, first, the user will visit the AMP-supported site. As they click through the site, they will navigate away from the AMP cache to the origin, allowing the site to add a service worker and deliver added functionality, including:
- Components that are customized/only relevant to the site
To add PWA to the AMP site, we’ll need to add a Web App Manifest. This ensures that users can install the site on their home screen.
To do so, we’ll first create the manifest, then link to it from the head of the AMP page.
Next, we’ll install a Service Worker. To do that, we’ll need to include the service worker script on the page
From there, we can modify the response via the Service Workers fetch to return any response we want.
AMP to PWA:
Essentially, AMP to PWA uses AMP as an entry point for the site, then “warms up” the PWA behind the scenes so it can switch over. That way, when a user clicks on any AMP site present in the search results, they’ll be served a fast-loading AMP page. As they navigate through the site, the service worker will kick in.
The process involves three steps:
- User discovers content
- Service worker installs in the background
- User is instantly upgraded to PWA
Using AMP to PWA allows:
- All content “leaf” pages (those that have specific content, not overview pages) are published as AMPs for the instant loading experience.
- These AMPs use AMP’s special element <amp-install-serviceworker> to warm up a cache and the PWA shell while the user is enjoying the content.
- When the user clicks another link on the website (for example, the call to action at the bottom for a more app-like experience), the service worker intercepts the request, takes the control of the page and loads the PWA shell instead.
AMP in PWA:
We don’t need to build all the pages with AMP. We also don’t need to separate AMP and PWA’s as hook and rod either. Now, we can actually AMP only a small subsection of a single page, thereby decreasing its size and lowering its load time without the complete tradeoff of dynamic functionality.
Another form of AMP called “Shadow AMP” is used here, which allows AMP to nest within an area of a web page. The result is AMP within the shell of a progressive web application.
AMP is really powerful. If the web pages are experiencing high bounce rates because of the slow page load speed, then creating AMP pages is the best solution. The majority of the developers who have used AMP have experienced better performance and speed in their web pages. But always keep in mind that AMP alone will not be suitable for designing complex and dynamic web pages.