The comments table has been repopulated! I’m currently working on restoring their hierarchy. For ease, I’m working backwards, from the newest to the oldest posts. Please bear with any site instability/sluggishness you might encounter. Cheers! ☺

Initial Thoughts on Google AMP Project

Written by Raymond Santos Estrella on Thursday, 04 February 2016. Posted in 2016

Initial Thoughts on Google AMP Project

I’ve been tinkering with Google’s Accelerated Mobile Pages Project (hereinafter AMP) to see if I could utilize it on other projects either wholesale or as part of the current main spec. For a brief introduction, Google is pushing AMP as a way of serving a lighter, faster loading content page to users (ideally) coming from its search engine results. By enforcing a stricter set of rules for building an HTML page (asynchronous Javascript, statically-sized resources, inline CSS at < 50Kb in length, CDN-served cached pages, etc.), we’re talking about a significant reduction in page downloading time and faster browser rendering. How the “standard” achieves the speedup is discussed further at their project page with source code hosted at Github.

The first thing I noticed as the vastly simplified page structure you’ll be forced to create given the limits AMP imposes. At the top the list is the banning of third-party Javascript from the critical path. Sure, synchronous JS downloading will always be a pain point and their document.writes add a level of jankiness to page rendering but this limitation abandons a lot of the rich, app-like interactivity of the current web behind and we’re left with pages that may load fast and look good but have the same interactivity as the web back in the 90s. This all but kills all those jQuery plugins and animations you’ve been working on and tweaking for UI/UX usage. Bye!

However, there is one thing I really like and that’s the usage of this code snippet here:

<style>
	body {opacity: 0}
</style>
<noscript><style>
	body {opacity: 1}
</style></noscript>

This is an example of the inline CSS I mentioned above. What this does is it actually hides the whole document body. Before this is a line that asynchronously loads the AMP Javascript library from Google’s CDN like this:

<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>

This script which is required for an AMP page to validate, will eventually change the body’s opacity to 1 once everything is loaded. However, what happens if Google’s CDN is down or the AMP JS fails to load due to some other reason? They have this absolutely cool CSS hack that uses a CSS animation to simulate a timeout via time-delay that goes like this:

<style>
body {
	animation: amp-timeout 0s 5s 1 normal forwards;
}
@keyframes amp-timeout {
0%	 {opacity: 0;}
100% {opacity: 1;}
}
</style>

Pretty cool stuff!

Another thing is batching DOM access so that recalculating page height is done at in batches, first to read all the things that affect page height then writing all those changes to the DOM. This removes a lot of the jankiness of page loading in the traditional model. For laymen, this means that when you load a page and start reading, even notice that sometimes the page suddenly flows up or down and you lose the place where you’re reading? This is caused by recalculations in the page length (height) because something like an ad or an image has loaded somewhere above where you’re currently viewing on the page. This is extremely annoying, not to mention computationally expensive! With AMP, it already calculates everything that needs to load so there’ll be these blank spots on the page while those elements load but at least the page won’t suddenly jerk down or up on you as these elements load. Sample code follows:

window.getComputedStyle...
foo.style.height = '100px';
foo.offsetHeight;
bar.style.height = '100px';
bar.offsetHeight;

In this common example, there are three style recalculations that occur during page loading:

*** Recalc style *** 
window.getComputedStyle...
foo.style.height = '100px';
*** Recalc style *** 
foo.offsetHeight;
bar.style.height = '100px';
*** Recalc style *** 
bar.offsetHeight;

AMP changes this model significantly. Since one of its requirements is that elements must specify their width and height, it knows beforehand the changes to the page’s length and can adjust the DOM accordingly in a single batch of calculations like so:

*** Recalc style ***
window.getComputedStyle...
foo.offsetHeight;
bar.offsetHeight;
foo.style.height = '100px';
bar.style.height = '100px';

and then apply that calculation by writing to the DOM in one flowing operation. Extremely cool stuff!

Analytics

One of the things that AMP does is supporting third-party analytics tracking in a very novel way. Instead of having multiple scripts for each and every analytics service and multiple beacons for user interaction, AMP implements a single tracker that will measure once and then serve the results to multiple chosen analytics packages.

Conclusion

I imagine I can whip up a quick-and-dirty implementation of AMP in an afternoon of coding for a few pages, maybe take a two days for a whole system to grow around it. I’m not sure of the absolute utility for it, though, seeing as I can hardly get the search engine to cooperate and actually show me AMP-ed search results in the first place.

At the top of my head, this would require a connection to the database, custom HTML header information, database-sourced titles, headings, authorship, and content and rel= logic code to point to the full version of the AMP page, and some .htaccess RegEx magic to handle redirects and docID stubs. Then a whole day of unit and comprehensive testing and validation to make sure everything worked and we might actually have something here.

I’m also curious at what kind of server load this might have at scale. I mean the initial crawl will probably put a large strain for at least a week but after that everything will be on Google’s CDN cache, right? The only real thing holding me back on this is that I just can’t, for the life of me, actually find any kind of page that uses the tech deliberately. It might just become some unused gimick that I poured programming hours and computational load into for a marginal, if not nil, benefit.

And now I just suddenly bored myself into stopping here. Bye! 😄

Share This Article

About the Author

Raymond

Raymond Santos Estrella

I guess I should really make a proper writeup here. Something witty or maybe a joke to add some levity. I’ll come back to this when I have time. If you have any suggested copy that I can insert here, drop me a line.

Leave a comment

You are commenting as guest. Optional login below.