In 2017 there has been a lot of focus around the impending mobile-first index and serving content through HTTPS. But there have also been two other important unfashionable topics lingering in the shadows: cybersecurity and site speed.
Since 2010, Google have publicly acknowledged that they take into account page load speed and site speed, and with tools like Page Speed Insights (along with a number of other third party solutions) we’ve been able to monitor and analyse our seconds.
However, balancing a quick page load speed and a great user experience hasn’t always been easy. As the internet has become a more and more important part of our daily lives, our online experience has evolved and we (as users) prefer much more visual content.
Big visuals also mean big image files, video files and potentially a lot of JS and CSS to fancy up the written text. This also means that there is more to load, therefore increasing load speed.
The reason that this is becoming more of an issue is because in 2015 mobile traffic overtook desktop traffic in a number of verticals, and mobile users browse everywhere; when they’re on the Wi-Fi at home, at work or using roaming data on the go. Users are noticing slow-loading pages; which means Google have noticed users noticing slow loading pages – and now Facebook has noticed slow-loading pages.
Identifying site speed issues
At the moment, with the noise surrounding mobile responsiveness and HTTPS, a lot of webmasters and development teams are being overwhelmed with changes. It’s also worth remembering that not everyone runs modern stacks or has a clean website; there are still a lot of big websites on legacy platforms.
That being said, there are a number of checks you can carry out that could make a big difference to your page load speed by refactoring your code.
Images and graphics play a big role in both delivering the message of the content and improving the user experience on a website. Getting rid of images isn’t viable, but compressing their file sizes is.
In some scenarios, the delivery of the images could also be optimized. If your images are quite far down a piece of content, utilize lazy-load solutions or even better, utilize a CDN like Cloudflare or Amazon CloudFront.
Another (and slightly less common) solution to improving page load speed is to utilize system fonts.
System fonts are the fonts that come pre-installed on your device. These are great options as they don’t have to be loaded, you simply call the system fonts in your CSS. That being said, choosing a system font can be tricky.
System fonts generally fall into two categories, optimized for screen and optimized for print. The main difference between these fonts is the detail. The only other issue with choosing a system font is that they are really over-exposed.
As every computer and device in the world (near enough) has them, they are not unique; so if typography is important to your brand, use custom fonts. But if Helvetica, Garamond or Seravek will do, use them.
Is AMP really the solution?
I couldn’t go through his whole article without mentioning AMP. AMP allows webmasters to create their slow, heavy pages but essentially serve their content through a new AMP page, that canonicals back to the original slow page.
Accelerated Mobile Pages seems on the surface to be an easy solution, especially for the big content publishers. But it’s not really a solution to the problem, more papering over the cracks.
What made these big sites slow and heavy in the first place is often tied very closely to how they generate revenue, advertising. Big banner adverts, banners spliced into content, overlays, auto play videos in the sidebars (yuck), all there to get your view and edge the website ever closer to another CPM payday.
With AMP, you don’t get to do it to the same extent and will lose out on potential revenue and ad views. How content is formatted is also very controlled, and the fact that Google hosts the content makes it a weird position to put the content publisher in.
Google is obviously willing publishers to utilize AMP and take advantage of the ranking benefits (AMP v non-AMP), but it still an odd situation to be in. A lot of webmasters have migrated to AMP as they manage large web properties that command a lot of traffic, but not because it is a logical business sense to do so, but because they are too afraid not to while their competitors make the move.
AMP is the right move for a number of websites, but I would assess all options first to speed up your website before boarding the AMP ship.
Producing a modern website that works for both SEO and users is not easy. It requires a lot of careful technical planning and development to ensure it contains useful, valuable content; that it’s secure; that it works on mobile; and that it’s fast.
Site speed can often be overlooked as a lesser priority, but it’s an extremely important part of the quartet. There are a number of free ways to test your site speed as well, and a lot of them provide good guidance on how to fix a lot of the issues.