Page Speed Optimization Service

How Fast Does Your Website Need to be for SEO?

Before you invest in speeding up your website, you should know how fast it needs to be. Unfortunately, the answer to this question depends on several key factors. What you don't want to do is waste your money chasing a 100/100 PageSpeed Insights score. I'd rather you save that money and invest it in something that will generate you a return on it. How fast your website needs to be depends on 3 main factors:

1

The type of device that most users access your site with

I have some sites that receive ~60% of their users from mobile and 40% from desktop. I have others that receive 70% of their users from desktop, with only 30% coming from mobile. This makes a massive difference. The higher the percentage of your traffic you receive from mobile, and the slower your site currently is, the more expensive it will cost to get it where it needs to be.

2

The most common connection speeds amongst your users

In the USA, if most of your users are in cities and urban areas, a 5G mobile connection is pretty standard. However, in more suburban and rural areas, users are much more likely to find themselves on a 4G or LTE connection. When it comes to page speed, the difference between 5G and 4G is significant. Problems that wouldn't be an issue on 5G we'd have to account for depending on how prevalent 4G is amongst your users.

3

The performance of your competitors' websites

Page Experience can best be understood as a "tie-breaker" when it comes to ranking. If you and I both have pages of essentially the same quality and we both offer just as much value to the user, but I offer a way a better Page Experience I'll likely out-rank you. The reason this is important is because the slower your key competitors are, the lower the bar we need to reach will be.

If you’ve spent any time researching pages speed on Google, you’ve definitely seen the term “Core Web Vitals”. In fact, chances are if you’ve reached this page you’re looking to improve yours. First off, it is a common misconception that Core Web Vitals is a rankings factor in Google’s search algorithm. Page Experience is the signal that may affect your ranking on search; Core Web Vitals is just one part of the equation.

Diagram depicting how the Core Web Vitals metrics: LCP, INP, and CLS and other webpage performance signals such as Mobile Friendliness, HTTPS, and Intrusive Interstitials (or lack thereof) contribute to Google's overall Page Experience evaluation for a website.

Understanding Page Experience

As I previously stated, while significant, Core Web Vitals only represents part of the whole when it comes to Page Experience. Have you ever been about to start reading an article, and all of a sudden you got a full screen pop-up in the way that wouldn’t even close when you clicked the X? In that moment, few things could be more frustrating!

Slightly less dreadful is when you’re on a page that has ads stuck to both the top and bottom of the screen, and all that you’re left with is like a 2 inch (~5 centimeters) window of readable content as you scroll. While it’s still possible to read the content of the page, most people find this utterly frustrating.

Both of those situations represent very poor experiences, and are good examples of what “Intrusive Interstitials” are. Elements such as programmatic/display ads, popups, and other things like that can both affect your site speed by increasing the number of 3rd party requests and shy away valuable users.

Screenshot of the Page Experience report in Google Search Console

Additionally, the things shown the previous two images are not even all of what Page Experience is, that’s just what Google tells us about. There are likely a wide variety of other signals that Google Uses to measure it.

Understanding Core Web Vitals: Field Data vs Lab Data

There are two main tools that SEOs use to measure page speed: Google Lighthouse and Page Speed Insights. Lighthouse represents what we call Lab Data; it is a simulated measurement of performance. What Google looks at that can affect ranking is Field Data, or the performance benchmarks that real users experience when loading your site. Page Speed Insights will show you both of these if the website has Field Data. Otherwise, it is also conducting a lab test.

The truth is that you don’t have to have a 90/100 or higher lab test score to pass Core Web Vitals and receive a good Page Experience report. Trying to get a score between 90-100 is, coming from someone whom has achieved that countless times, more often than not a waste of money. Sometimes, it’s not even possible. To illustrate this, I will show you a site that I optimized.

Case Study: 73 Performance Lab Test Score with Passing Field Data

I got this application, a video game calculator, to an overall lab test score of 73. You can see red values for Largest Contentful Paint (LCP) and First Contentful Paint (FCP), as well as a yellow Total Blocking Time (TBT) in the screenshot below.

A screen shot of a site with a Lab Data performance score of 73. You can see red values of Largest Contentful Paint (LCP) and First Contentful Paint (FCP), and a yellow Total Blocking Time (TBT).

This might lead someone that doesn’t know better to believe that the site’s performance still isn’t good enough, and needs more work. My client was very adamant that he wanted the site to be as fast as possible, and at first wasn’t satisfied with this result. However, that changed after I explained to him that that field data is really what matters, and that based on my analysis, when it came to what real users experienced the site would pass no problem.

The result turned out exactly like I expected, passing Core Web Vitals with ease. By understanding the users of the site and the realistic conditions under which they would access it, I was able to solve my client’s problem without forcing him to unnecessarily overspend his money.

A screenshot of a passing Core Web Vitals assessment on Page Speed Insights

Software and Tools That I Use

NGINX logo
Apache logo
Litespeed logo
Varnish Cache logo
Redis logo
Memcached logo
Cloudflare logo

Frequently Asked Questions

Why Does Page Speed Insights Lab Data Not Reflect Reality?

If all of your users accessed your site using a Motorola G Power on a slow 4g connection, a Lighthouse report would be realistic. However, the reality in many Western countries is that having a 4g connection is increasingly rare.

Field data is based on the actual devices and connection speeds of your users, which is all that matters. If Google used lab data scores to assess Page Experience, most of the internet would not pass.

How Do You Effectively Optimize Page Speed if a Website Doesn’t Have Field Data Yet?

This is a great question. Many small or new sites don’t have Core Web Vitals field data in Search Console because they don’t have enough traffic for it to be accurately measured yet. Field Data is gathered in 90 day intervals through the Chrome User Experience (CrUX) report whether or not a site has a connected Search Console property.

However, if a site doesn’t have CrUX field data yet there are still ways that we can predict it. From experience, I can usually tell if a site will have passing field data just by running lab tests, throttling my connection at various speeds, and emulating various different devices.

On larger scale enterprise applications where a more sophisticated solution is required, we can use Synthetic User Monitoring. This is the practice of simulating the paths that real users will take and when visiting a website, as well as their likely actions.

We can also get field data on our own, without the CrUX report. Real User Monitoring (RUM) is the practice of recording user interactions on a website. It works by firing JavaScript on each page to capture page speed and other performance data and then reporting it back to the system. If a site is not live and receiving traffic, there are still ways we can accomplish this.

What is the Most Effective Way to Speed Up a WordPress Site?

DOM Prioritization is the practice of rearranging the way that a site loads the resources that it depends on in order to not block the browser’s main thread. If that sounds confusing, imagine it’s like this: the browser is a conveyor belt in the checkout line at the grocery store. DOM prioritization is akin to grouping all of the similar items on the belt so that you don’t end up with 3 cans of soup and a jar of salsa in the same grocery bag as your carton of eggs. It’s strategically placing things on the conveyor belt so that they get bagged in a way that they’ll be the easiest to carry and travel the safest.

If you use WordPress, Asset Cleanup Pro by Gabe Livan is a good plugin for altering how scripts and stylesheets are loaded. However, I usually just add custom code that does the same thing via a site’s functions.php.

My site uses a lot of plugins, is that what is making it so slow?

Probably. Most WordPress sites use Plugins – 3rd party pieces of software for various tasks and functionality. If you use a page builder theme, a 3rd party widget extension for it, a plugin for author bios, a plugin for displaying image galleries, and plugin for animations, all of these plugins are loading their own scripts and styles. This leads to what we call code bloat, which results in extreme cases of render blocking resources and often requires the most heavy handed measures to optimize.

What Types of Websites and CMS do You Work With?

A large majority of my clients use WordPress. Other popular CMS I work on are Ghost, Strapi, Magento, and Statamic. In addition I’ve worked on plenty of static JavaScript sites eg. React.js, Vue.js, Next.js, and others. I can work with virtually any content management system under the sun besides Wix, Squarespace, Webflow. These platforms are closed-system and I have little control or ability to manipulate how they work. Shopify, while somewhat similar, is an exception because A. it can be self hosted and B. it can be very customized. I’ve optimized dozens of Shopify sites.

How Much Does Site Speed Affect Ranking on Google?

In my 7 years of experience as an SEO Consultant, I have only seen a measurable increase in ranking after improving site speed in niche circumstances. For example, when site speed was absolutely horrendous prior to fixing it, or on highly competitive SERPs when the sites competing have similar content. As I said before, you can think of Page Experience and Core Web Vitals like a tie breaker when it comes to ranking on search.

If you’re already passing Core Web Vitals and have a good Page Experience report in Search Console on both Desktop and Mobile, investing in speeding it up further would not be worth it.

What is the Best WordPress Site Speed Plugin?

There is no performance plugin that will fully solve the problem upon activation. There are a handful of options that each excel in different areas, and all of them require some level of configuration, which is different for every site.

I would look for something that is good for browser caching, combining JavaScript / CSS files, compressing and lazy loading images, and allows you do defer, asynchronously load, or totally dequeue resources. However, there are a lot of bad performance plugins out there that can mess your site up quite a bit. Below are some safe-bets that I’ve used on client websites.

WordPress Plugins That I Endorse

WP Rocket Logo
Autoptimize plugin logo
WP Optimize plugin logo
BREEZE by Cloudways logo
Asset Cleanup Pro by Gabe Livan
Perfmatters logo

Page Speed Optimization Service: Details & Pricing

I don’t provide pre-set packages for performance optimization because it’s an inherently bespoke practice. My hourly rate is $135/hour. Depending on how poor your existing page speed is and the nature of how your site was built, 3rd party software and changes to your hosting might be required to achieve the desired result. Of course, I will present you with multiple options to get there at various price points.

If you are interested in hiring me to optimize your site performance, want to ask additional questions, or would like my advice feel free to book a consultation below.