How You Can Improve Your Page Speed

Who wants to make more money? Get more conversions? Have more traffic?

One of the simplest ways to achieve those things is to improve your page speed.

This article tells you how to do it properly by focusing on your infrastructure first.

Read it now, and get on with making your site faster.

#SEO #SEOTutorials #PageSpeed #Revenue #Conversions

Why should you improve your Page Speed?

If you care about users and their experience, you should make your pages and content load faster. Doing this will improve the following things on your website:

• Revenue

  • Quicker loading times have a direct relationship with increased sales.
  • Users are more likely to buy things from sites which load quickly. They can see more product and get down their user journey quicker.

• Conversions

  • This is a corollary of revenue, but is different.
  • The more people look at your content, the more they are likely to convert even if that conversion is non-monetary.

• Pages per Visit

  • Quick loading content makes people want to engage and click around.
  • You still need compelling content and reasons to click.

• Time on Site

  • Slightly counter-intuitively, increased load speed of your pages will encourage them to hang around more, mainly because they will go visit more content.

• Traffic

  • More visitors will get to the point where the analytics tag loads, so more visitors count.
  • Also, more people will reach the point where the page actually loads.

• Inbound links

  • Other websites and people are more likely to link to and share quicker websites.

• Engagement

  • Once you get beyond opening the door wider and effectively allowing more people into the site, every other metric is a factor of engagement.
  • Increasing your page speed is the quickest way to increase your engagement with the resulting benefits.
  • It won’t change a dog of a site into a super-performaer, but it will increase every metric proportionally.

Does PageSpeed affect Google rankings?

• Not Directly

  • Despite what some people would have you believe, the answer is no, not directly.

• Google cares about Page Speed but does not rank websites on speed as a primary factor.

  • Until it goes entirely pay-to-play, Google is still a relevance search engine with “washes” like page speed, PageRank, security, applied *after* relevancy factors have been taken into account. These post-relevancy factors allow Google to select between very closely competing options.
  • All other things being equal, if your page loads quicker, people are more engaged, inbound links flow, you will see that rankings increase as a result of page speed affecting these factors.
  • If you and a competitor are almost exactly the same in terms of direct ranking metrics, you may see a small boost on a page by page and ranking by rankings  basis if those pages load faster on a regular basis than your competitors.

What are the elements of Page Speed?

Outside of the arcane technical elements which affect page speed, the main elements from a user’s perspective are:

• Time-To-First-Byte (TTFB).

  • This is the time from when the first request is made, DNS responses are given, routes are allocated, servers are pinged and the first byte of content is delivered to the user’s browser or app.

• Time-To-First Paint (TTFP).

  • This is the time from the first request to enough content being received and processed to start drawing something on the screen.
  • This is important because nobody likes staring at a blank-screen.
  • Painting the first screen quickly will ensure your users get *something*. They are then more patient with loading.

• Time to Interaction Ability (TTIA) is the most important.

  • Some users, like your grandma, wait until the whole page is loaded until doing anything. Most don’t however, so getting the ability to do something, like scroll, click, read, is the single most important metric of all. All the rest is belly-button fluff in comparison.
  • It is however the most difficult to measure effectively.

• Time to First Screen (TTFS).

  • This is an extension of Time to First Paint in that the user’s screen  (without scrolling) is loaded and looks pretty.

• Time to Full Load (TTFL).

  • This is the most misleading statistic in the panoply of Page Speed statistics.
  • It is only important if your users cannot interact unless the page is fully-loaded, in which case you should fire your developers and get better ones.
  • The other instance in which it is important is if your grandma is still sitting there waiting for the page to fully load before doing anything.

How you can improve Page Speed:

• Improve your infrastructure

  • The fastest, and best, way to improve your page speed is to improve your hosting and content delivery infrastructure.
  • This will improve *everything*, not just individual lines of code.

• Upgrade your server.

  • If you are on a poorly managed shared server, or virtual server, you have lots of room for improvement.
  • Go up a level, or two.
  • Go to a dedicated server, or go to a load-balanced solution with multiple servers, each optimised for their roles (front-end / database / media, etc).
  • This will enables your bytes and cycles to be processed and delivered out of the door to an internet connection near you much faster.
  • If you have been on your server for a while, upgrading to a newer model can seriously improve your speed – better processors, more RAM, less cruft dragging it down.

• Upgrade your routing.

  • Routes are how internet traffic travels from your servers to the user’s ISP and eventually to their machine and browser.
  • The only piece of that route you cannot affect is the “last mile” from ISP to browser. Everything else is up to you.
  • Some routes are like country roads: narrow, windy, lots of stops.
  • Other routes are like empty highways: direct, speedy, no stopping allowed.
  • Talk to your host about how you can upgrade your routing.
  • Often a better server, or hosting package will come with better routing attached.
  • NB – it’s really important you don’t believe your host uses the same routing for all packets. They don’t. It’s how they make money on bandwidth.

• Upgrade your host.

  • Not all hosts are created equal, and frankly some of them are poor.
  • Moving hosting can be a real pain depending on the complexity of your implementation, but if you feel your host is under-performing, or doesn’t have modern servers, fast routing available, you need to move for the long term.
  • The other fun thing with hosts, is some of them will take a default installation of a distro (either OS or web server and other related bits and pieces) and load it onto servers.
  • Others will tweak and optimise them until the web server runs blazing fast.
  • You want to be on a host who knows when to optimise, and when to install the default package.

• Use server-side caching everywhere.

  • Your webserver should cache content intelligently, ready for delivery on request, without need to generate the content from the CMS.
  • This includes dynamic content which has not changed.
  • Your CMS should spend its time creating content and delivering to the webserver when there’s an update, not delivering fresh each time there’s a request.
  • To balance resources, your webserver will need to know when to fetch fresh content, and when to serve its cache.
  • It may need to keep really popular content in its cache constantly, other content may rotate as needed.

• Use internet caching & common resources.

  •  There is a particular fault with all the Page Speed tools in that they do a fresh load of everything every time. This is useful for benchmarking, but isn’t real-world usage.
  • Take bootstrap. The CSS is quite big and bloated because it is all things to all people. A Page Speed tool will advise you to do x, ya and z to it. But, if you use the default bootstrap from their CDN, it will already by cached by the majority of users, their ISPs, or any of the upstream ISPs  between your server and the end-user.
  • In the real-world, it is quicker to load from cache, and load any modified resources separately, even accounting for round-trip time.
  • You will need to investigate which of your resources can be loaded from web caches rather than your own server.
  • This is an intelligent use of the internet and aligns with how it was designed to operate.

• Upgrade your CDN

  • Unless you are close you all your users, or running very light code, you will want to use a Content Delivery Network.
  • These initially started out hosting the large media files which a lot of websites used, but have developed to a point where entire websites are loaded from their points-of-presence on the internet.
  • Like servers, hosts and routing, there are different levels and qualities of CDNs.
  • Use the best you can afford.
  • It will serve your content faster from a point closer to the end-user than you are because everything on their infrastructure is “better”.
  • This reinforces the point about improving your infrastructure rather than working on code initially.

• Update your code bases and libraries.

  • Even though you may have optimised your code to the nth degree, updating the code base and updating the ancillary libraries can bring significant speed advantages, especially if the code base has been re-written with performance improvements in mind.
  • With luck, you can update these without having to do a major code rewrite.
  • Think things like latest version of OS, webserver, PHP, MySQL and other assorted libraries.

• Limit Dynamic Code / JavaScript to what’s needed.

  • It’s a sad fact of recent web development that developers have started to try and load *everything* into the page via JavaScript. This is a nonsense and causes significant issues with end-users and performance.
  • Of course, developers are lucky enough to work on high-end MacBook Pros, with the latest iPhones, Samsung or Pixels. They forget that the vast majority of users run on poorly specified, cheap machines. These are not the best to run swishy dynamic code on.
  • The simple truth is that JavaScript and other dynamic elements should only be loaded and run if they are needed to run dynamically.
  • If you are running JS for basic construction and display, you have almost no control over the end-user load experience and are relying on an often under-powered machine which may be busy doing other things. Do you really want that? Or do you want to be able to know that the only really variable factor in load time is the speed of the pipes over which your website data travels?
  • Dynamic libraries, JavaScript and other code should only be used when absolutely necessary. Any other instance is developer laziness.

• Cache your data

  • We’ve talked about common resources and internet caching, the same applies to your server and the user’s browser.
  • The more you can tell browsers, ISPs, users to store data on their machine the faster their load experience will be.
  • You should not try to load and cache everything on first load, since that will impair initial performance (remember that first impressions count).
  • Load sequentially in order of non-render blocking use, and you can get quite a lot stored along the way.
  • Of course, if you can cache things at the ISP, or routing level, even better, since the overall roundtrip load time is much reduced.

• Compress your data

  • For a long time, I thought compression was standard, but I’m seeing more and more poorly set-up webservers where compression hasn’t been turned on and it’s left to the unsuspecting user to do it.
  • This is a symptom of a poor webhosting company – since if they compress data automatically they have better user experience and use less bandwidth.
  • If my hosting company doesn’t turn these things on automatically, it causes doubts in my mind about their long-term ability to run and manage servers effectively.

• Minify your code

  • Minifying is a tough issue and should be approached with caution.
  • Essentially, it means that the server strips unused white space like line breaks and other things from the code as it passes through.
  • If done on the fly, there is some overhead in processor speed which may actually slow things down.
  • There can be issues with some scripts which needs line-endings to run properly.
  • I would think very carefully about using any code which cannot be run minified.

• Make coding improvements

  • Once you’ve improved your infrastructure, you should improve your code.
  • You can do this asynchronously with infrastructure improvements, but if you do not have the resources to to both side-by-side, I would do it after improving your infrastructure.
  • I’m not going to go into arcane geekery around improving code. That’s what good developers are for.

What tools should you use to measure Page Speed?

Outside of Google Analytics, I use two or three really good tools regularly:

• GTMetrix

  • Ever since the old link script days of Gossamer Threads, GT have been producing good quality scripts which do the job.
  • GT Metrix checks a page against Google’s PageSpeed metrics and Yahoo’s YSlow.
  • Setting up an account allows repeated testing from different locations using different browsers. This is really handy for getting a list of on-page fixes and seeing the outcomes of your work.
  • GTMetrix

• Hyperspin

  • This is a very simple old-school tool which will give you load times and breakdowns from entry points around the world.
  • It doesn’t give you fixes, but registering allows you to set up an outage monitor as well.
  • Hyperspin.

• Google’s own PageSpeed tool

  • Even though it has severe limitations, Google’s PageSpeed tool is still a horse’s mouth source of truth.
  • The recommendations are okay, but they focus solely on an on-page approach and ignore the benefits of upgrading your hosting.
  • It’s really worth noting that Google in its quest for speed created its own specific set-up of server farms, data centres and even wrote its own OS. What does that tell you about the importance of infrastructure in the process?

How should you measure improvements in Page Speed?

• Focus on tangible business outcomes

  • Every other metric is irrelevant if your business does not improve as a result of improving page speed.
  • There are no prizes for the quickest page on the internet.
  • I really cannot stress this highly enough: “show me the money”.

• Revenue increases

  • You cannot take a speed measurement to the bank.
  • Being the fastest means nothing apart from bragging rights if you do not make more money out of it.

• Conversion increases

  • Although you cannot bank conversions, if you increase conversions as an absolute number, you should improve other business outcomes like revenue..
  • If your revenue does not improve, your business model, or its reporting and decision-making needs adjusting.

• Traffic increases

  • See above re conversions.
  • Traffic, conversions and revenue should have a direct relationship.
  • If they do not you need to work on improving them until they are aligned and an increase in one is represented in the other.

• Using benchmark metrics

  • It is impossible to know if every user had a great load speed experience, and while you should always focus on the tangible business outcomes, you do need some warning indicators to tell you whether things are doing okay, or if they need huge improvements.
  • You need to keep as many things stable as possible to allow cross-comparison between data points.
  • That means running tests consistently and regularly. Traffic at 4am Sunday is different from 9.30am Monday, so load speed will be affected significantly by this.
  • Set up your testing regime to compare the same points each day / week / month focusing on both busy periods, and quiet periods.
  • Measuring performance at busy periods will give you a real-word view on how users are experiencing your pages when you are busy. This is the critical time. You don’t want users thinking “I’ll come back later”. Some will, but most won’t.
  • Measuring performance at quiet periods is good for seeing if individual changes make a difference, but the metrics from them should not be used as headline performance data.

That’s it! Thanks for reading. Any questions, please contact me.

Return to Top

I recently wrote about how Google’s Mobile First is Not Mobile Friendly. Read it now.

Return to Top

• Improve your Page Speed because you care about your users and because you want to make more money.
• Focus on your improving your infrastructure, routing, caching before you focus on your code.
• Focus on your revenue and other metrics.
• Business outcomes are better than the warm glow of having a quick site.
• PageSpeed does not directly affect Google rankings.
• Read The State of SEO in mid-2017.
• Read about how Google’s Mobile First Index is not Mobile Friendly.
• Finally, get your content ranking well on Google by starting to understand Find Crawl Index.

Thanks for reading. If you would like to discuss what these changes mean for your web property, or would like to know how to implement them, please feel free to contact me.

Return to Top