Is AMP simply a system that enforces rigorous page speed rules? Can we not achieve the same without using AMP? What is special about AMP? How does it work?
I can provide you a simpler, cleaner understanding of the why's and how's behind fast loading AMP pages. Even if you decide not to implement AMP, you can still use alternate optimisation techniques to overcome the hurdles discussed here and achieve faster pages.
AMP optimises your Scripts. How?
I can provide you a simpler, cleaner understanding of the why's and how's behind fast loading AMP pages. Even if you decide not to implement AMP, you can still use alternate optimisation techniques to overcome the hurdles discussed here and achieve faster pages.
AMP optimises your Scripts. How?
Problem - Render-blocking javascript is the biggest page speed issue, affecting most webpages today.
Example - jquery. If a webpage is built relying upon jquery based javascripts, jQuery needs to be loaded prior to those scripts. So until jquery and the connected scripts on page get loaded, the webpage does not get rendered.
AMP Solution - To ensure no javascript is render-blocking, AMP allows loading only asynchronous scripts. On seeing an async declaration, the browser understands that it need not wait for the resource to build the page. The page render does not stop even if the javascript starts loading.
AMP blocks third-party Javascript. Why?
Problem - Lack of control over third-party software makes it impossible to prevent the use of document.write or synchronous calls. This can block the page render significantly.
Example - Ads. If you have 5 ads, and each does 3 sync loads, with a 1 second latency connection, you’re in for 18 seconds of load time just for JS loading.
AMP Solution - AMP restricts such javascripts by allowing them to run in sandboxed iframes. Such iframes optimize the critical rendering path and saves the time required for initial page load.
AMP defers extension mechanisms. Why?
Problem - Extension mechanisms may make use of your layout to display unknown things. Such things may require HTTP requests additionally.
Example - Webpage should load first before the ads in it. The webpage render should not have to wait for the embedded objects.
AMP solution - AMP calls a script that can identify special tags (eg. amp-iframe) so that it can create an empty box( eg. iframe box) before it is even aware of it's contents.
AMP changes CSS framework? Why?
Problem - Nothing gets displayed in a browser until the CSS is dealt with. Hence css in general is render-blocking.
Example - CSS frameworks. CSS frameworks tend to call hundreds of KBs of CSS, which can create bloated code. This slows down the entire website.
AMP solution - AMP restricts css size by setting a limit(50k) on the css size. AMP does not validate any page that has more than 50k of css and hence those pages will not work using AMP.
AMP minimizes style recalculation. Why?
Problem - The more css, bigger is the mess of recalculations for every frame and costlier is your page load in terms of time and efforts to recalculate.
Example - Sometimes an embedded content block or the external javascript or ad might call in new styles or animations of varying sizes. This could affect the layout and so all the page elements including the h1, h2, font-size, divs, images, etc need to be recalculated.
AMP Solution - AMP imposed css size limit of 50k and static declaration of page element sizes, DOM reads before the writes, effectively removes style recalculation cost.
AMP sizes resources statically. How?
Problem - On rendering a webpage, the many style recalculations involved, amounts to a great work being done by the browser. All of it can be avoided if the browser is made to understand the sizes of elements before downloading it.
Example - When an image is called from a webpage with no size information, the browser has to recalculate everything on page to allow the image to be seen. All these recalculations could be avoided if the browser knew the size of the image to be downloaded.
AMP solution - AMP specific tags like amp-img can understand that the sizes declared explicitly are to used as a guide rather than an absolute measurement to be displayed in.
AMP makes font triggering efficient. How?
Problem - The basic way that the browsers use to deal with the pageload, is to take care of the js and css files before the font files. But font files are bulkier resulting in delayed pageload.
Example - To have the browsers load the font file before all other files is optimal. But there is no way to make the resource download happen this way, with little delay.
AMP solution - AMP files are created with the basic plan to load the pages incredibly fast. For this purpose, AMP employs a hack to trick a browser into thinking that the page has loaded enough to start downloading the font. This enables the css and js files to load first before the font does.
AMP animations are GPA enabled. How?
Problem - Using animations is becoming so popular today that trivial things like interface acknowledgement are replaced by graphic animations.
Example - CPU does the job of rendering the page efficiently. GPU does all the animation math and renders cleaner animation. Together CPU and GPU render cleaner and faster animations.
AMP solution - While there is no command to restrict animations to GPU, AMP promotes the element to be animated but restricts animation to just transforming and changing opacity.
AMP prioritizes resource loading. Why?
Problem - Which resources will load before another, cannot be determined easily. Resource loading is a common issue of page speed.
Example - When the font file is loaded after other resources it can restrict the user from seeing any text. Webages are faster when css is loaded before js than the pages that loads js before css.
AMP solution - AMP loads above-the-fold content and enforces best practices like prefetching lazy-loaded resources for below-the-fold contents.
AMP uses preconnect to prerender. How?
Problem - Preconnect, prerender, prefetch are all commonly misused ideas. When overused, pages tend to load slower, use more CPU resources and so.
Example - By prerendering, pages show up instantly to the user because the browser has already done the work. But prerendering everything cannot be an ideal solution because the CPU cycles could get wasted.
AMP solution - AMP is designed to be efficienctly prerenderable. It intelligently prefetches above the fold content and resources. But it refuses to prerender things that will take too heavy CPU cycles.
If all of these can be implemented without AMP, what is really special about AMP? Special caching? Google supported CDN? Both!!! Isn't that the best special?