AMP (Accelerated Mobile Pages) was introduced by Google back in 2015 as a web development framework to help speed up the web for mobile devices.
AMP has been pushed as a quick and easy solution for websites looking to improve their search results ranking. I strongly disagree with this as AMP imposes extra costs to your website's development and maintenance. While there are certainly advantages with AMP, they can also be replicated on regular non-AMP pages at a lower cost.
Does AMP give you an edge in your SERPs?
The short answer is no.
The longer answer is a little bit more nuanced. If your website is bloated and slow to load on mobile, you will definitely improve your SERPs (search engine ranking positions) implementing AMP.
However, if your website is fast and properly optimized for mobile, you will not see any benefit implementing AMP. Page load speed is one of the top factors Google takes into account when ranking pages. The performance increase from implementing AMP is what improves your SERP, but not the actual implementation of AMP itself, which some people have a misconception of. Google or any other search engines for that matter do not consider AMP as a ranking factor.
So if your website is bloated and slow, why shouldn't you implement AMP then?
How AMP works
It's important to understand how AMP works to make websites faster to appreciate why there are more cost effective and long term alternatives to AMP.
I won't go deep into the technical specifics of how AMP works under the hood, but there are a few points we can take from the AMP website:
- AMP HTML is a restricted set of HTML that emphasizes on performance
- JavaScript must not block rendering and be executed asynchronously
- AMP pages are cached and served from a content delivery network
- CSS must be inline and not more than 50kb
- Efficient handling of web fonts, style recalculations, animations
In short, AMP places some hard restrictions on the moving parts under the hood of AMP websites to ensure performance.
Additional development and maintenance overheads
Most websites that implement AMP do it as an additional version of the website for mobile devices. The AMP mobile pages are usually visible to the user only if they are coming from a web search on mobile. Users who go directly to your site via your URL on mobile see the regular version.
Unlike regular responsive web pages where most of the code behind is the same regardless of mobile or desktop devices, AMP HTML is not compatible with regular HTML. You will need to development and maintain the extra AMP version on top of your regular non-AMP version.
As a result, you have the additional overhead of developing and maintaining the extra AMP version.
This is a huge downside not just because of the extra monetary costs. Time spent working on an extra version of the same thing means time taken away from iterating on new features or changes that improve your product as well.
AMP also has other downsides as well.
Limited control of your content and design
The AMP components used to build AMP pages have a lot of restrictions and it is these restrictions that help make AMP pages fast. CSS can be used to style the components, but the basic behavior and user experience of these components are more or less fixed.
Different AMP sites tend to have a similar feel to them which makes it harder for brands to differentiate themselves.
Limitations on design and the experience of your page also translate to lower conversion rates. Not surprising since design restrictions could mean pages are less optimized for conversions.
Analytics problems
Strangely enough, AMP doesn't play very well with Google Analytics given than Google is a major proponent of AMP. Because AMP pages are served from a content delivery network outside your own domain, extra configuration is needed to have metrics continue being tracked.
There are also other issues associated with GA which have been resolved yet. Some users report data sampling issues for AMP traffic.
How to make your website as fast as AMP
You can make your website as fast as AMP. It will most likely take you the same amount of time to optimize the performance of your website it takes to build an AMP site. In addition, the effort you spend on optimizing performance also benefits desktop users and mobile users who aren't coming from search engines.
Each website's case is unique and would require its own strategy to make it fast, but there are a couple of general pointers that would be relevant across most websites.
Google Lighthouse
Lighthouse is an open-source, automated tool by Google that audits a web page's performance, accessibility, and SEO.
It takes a measurement of a few key performance metrics, as well as gives you a diagnosis of issues that may be impacting your page performance.
It takes a measurement of a few key performance metrics, as well as gives you a diagnosis of issues that may be impacting your page performance.
There are different load times it measures, each of which gives you a different perspective of your page's performance.
First contentful paint - This is how much time it took for the first bit of content to be "painted" on the page. This is quite representative of a typical user's experience, showing you how much time before your user starts receiving useful information (e.g. text, images).
First meaningful paint - Very similar to first contentful paint, but as the name suggests, there is a focus more on time taken before meaningful content appears on screen. This could be the main headline or body of an article. Things like your page header, footer, or navigation are not considered to be part of this.
Speed index - This is actually a calculated metric and is a little trickier. It calculates the average time for the visible parts of a page (what can be seen in the viewport) to be displayed. The reason for this distinction is that while content that is not visible and below the fold would have no impact on the actual user experience even if it resulted in a longer load time.
First CPU idle - The CPU is needed to download and execute page resources (CSS, Javascript, images etc). This is a measure of how much time before the page is minimally interactive.
Time to interactive - If First CPU idle is how long before the page is minimally interactive, then time to interactive is just as the name suggests, how long before the page is interactive. Typically, this includes the execution of third party JavaScript.
Content Delivery Network
Putting your website behind a content delivery network can typically yield very good results for performance if you have not already done so.
A content delivery network saves the final render of your page (the resulting HTML) and saves it on multiple servers across its global network. When a user makes a request for your website, the CDN determines the location of the user and serves your page to them from the server closest to them.
This helps to resolve two issues that are typical causes of slow websites.
Web server bottleneck - The web server is in most cases the bottleneck. On a Wordpress website for example, everytime a user makes a request, the server has to run all the code in Wordpress, retrieve the content from the database, and then build out the HTML / CSS / JavaScript code. It does so for every user and every request. The server can only do so many requests at a time, so if there are too many, then the user has to wait for other requests to finish before the server can fulfill theirs.
CDNs save the final output of the page onto their own servers. It bypasses your Wordpress server and is a lot faster since it does not need to compute and render each request.
Latency - This is another common issue especially when you have a global audience. A user located in Asia viewing your website hosted in a server in the US would need to send a request across the world, and then wait for the information to be sent back across the world again.
CDNs solve this problem by having your page saved on multiple servers in their network in multiple locations around the world. They match each request with the server located closest to the user to reduce the latency,
Removing unnecessary third-party JavaScript
This is again another common culprit of slow websites. Third-party JavaScript often provide really easy, convenient ways of adding extra functionalities to a site. However, these scripts tend to be easily added into a page but seldom removed after they are no longer required.
A good start would be to do an audit of all the third-party JavaScripts loading on a page and determine if they are still being used. Remove them if not.
Optimize your images
Images tend to be overlooked and are great sources of quick wins too.
Do a check for the images being loaded on your page. Are they saved in the wrong format? Have they been optimized for file sizes?
Image formats - Make sure photos and other complex images are saved in JPG format and not in PNG. Images with a small set of colors or with transparency should be saved in PNG.
File size optimization - A lot of image editing software still leave plenty of room for further optimization after saving images. Various tools online can help to compress images further down without any visible loss to quality: TinyPNG, Optimizilla, Kraken.
Speed up your website today
For most websites, AMP is not necessary for fast websites. At most, it is really a temporary solution. As mentioned earlier, the amount of effort one would require to speed up an existing website is most likely equal to that which is needed to make an AMP version.
Even for websites already with AMP pages built, it might be more beneficial in the long run to focus development resources on native HTML pages rather than split them up across HTML and AMP.
What are you waiting for? Speed up your website today!