Three reasons you might not need Google AMP after all
Mobile devices currently account for more than half of all internet use on a global level, and yet, many websites are still not mobile-friendly.
Smartphones have less powerful hardware and network connections than desktop and laptop devices, and Google wants to be sure that the websites they refer people to meet user expectations.
AMP works by limiting the types of elements that web publishers can use, to ensure the pages can be downloaded and displayed quickly. Google’s servers then cache the web’s AMP-powered pages, and they pre-render in the background while people are still perusing their search results, to further help minimize page rendering times.
What Google won’t tell you, of course, is that you may not actually need AMP to maximize your site’s speed. The company has too much riding on the success of the AMP initiative to admit that it’s redundant – at best – in many situations.
In fact, if you’ve already been doing everything you can to improve your site’s mobile loading speed, then implementing AMP may involve more disadvantages for you than advantages.
Does your site have a lot of pages that aren’t articles? Do you depend on third-party tools for lead capture or audience tracking? Do you monetize your site using an ad engine that isn’t among the relatively few supported by AMP?
If you answered yes to any of the above questions, then when it comes to maximizing speed, you’re probably better off using your own knowhow and infrastructure, as opposed to Google’s. There are even mobile-oriented website building tools, such as Duda, that can do everything AMP does, but without many of the disadvantages.
Here are three situations in which AMP isn’t for you.
When you use a CDN to host your image files and other content, your audience queries are routed to the networked server that’s physically closest to each site visitor.
Many CDNs also use smart file caching rules, sophisticated session routing optimization algorithms, purging of unused files and built-in image compression to minimize load times. This is extremely effective for speeding sites up, in many cases reducing latency by up to 50%.
Even if you don’t feel the need to invest in a CDN, though, there’s a lot you can do on your own to minimize the bandwidth demands of your images and code.
You can implement “lazy loading,” or deferred loading of images, so that your audience can begin reading your content before each image appears on the page. In addition, tools like CompressJPEG or CompressPNG can dramatically reduce your image file sizes.
With these solutions in place, you can feel good about sidestepping AMP.
If you’re working in WordPress, then this isn’t actually so hard to set up. All you need to do is adjust your theme’s functions.php file to include some “dequeue” commands by adding a code snippet along the lines of:
wp_dequeue_script( ‘cufon_handle’ );
This particular function will determine if the visitor is on a mobile device, and if so, will disable the Cufon plugin, a useful font replacement tool.
Add additional versions of this code to account for all the plugins and scripts you want to disable. Keep in mind, though, that in order to dequeue a script, it must first be enqueued. If it is not, this solution will have no effect.
Style sheets, as powered by CSS files, are generally relatively small, but if you have several of them, then your audience’s devices will need to query your servers for each one separately.
Often, it’s the query volume, rather than the weight of the files, that can slow down content loads.
The solution is to consolidate all of your style sheets into one master CSS resource. To get started with this, set your website code to reference an external CSS file called from your CDN, rather than placing the CSS in-line through all the pages on the website. Then, use a tool like CSS Minify to clean up your CSS file before hosting it on your CDN.
In this sense, CSS files are similar to images. They should be consolidated, compressed, minified and hosted via a CDN. With all this in place, you’ll kill code bloat and unlock faster load times, once again negating the need for AMP.
If you’re already doing everything you can to reduce the number and sizes of resources required to load your content, then your pages might be as fast as they ever will be.
However, speed isn’t to be taken too lightly. As long ago as 2012 – before the dominance of the mobile web, mind you – Amazon estimated that each second of added load time per page costs the ecommerce giant some $1.6 billion in annual sales.
If you’re struggling to get your page load times down to within four or so seconds, which is where it should be for the optimal user experience, then you may want to consider using AMP.
At this time, Google doesn’t officially consider AMP implementations to be a ranking signal, although some websites have started to see lower click-through rates since AMP pages have started aggregating in mobile SERPs. Carefully consider the costs and benefits of using AMP for mobile speed before you dive in – you may be giving up more than you need to.