This is the second half of a two-part series discussing the importance of site speed and how to improve it. To read the first part, click here.
If your organization relies on its website, it also relies on that website being fast. No matter how well-designed your site or compelling your content, it will fail if it is slow.
At my web design and development firm, Cantilever, we’ve launched hundreds of websites and helped many organizations understand and improve the performance of their own. Our experience has yielded a few key techniques we rely on to analyze how a site is functioning. Those techniques aren’t just for developers: You can use them too.
Learning how your website works, and how to test it accurately, is a key step in becoming a “Performance Hawk” — someone who can take an active role in ensuring that their organization’s website is working optimally. If you’re already working with a development team, your knowledge will help you ask the right questions. If you need to hire a team to help, understanding the problem can help you ensure that you have the right fit, and that costs match your expectations of what’s really happening.
In Part One of this article, we outlined how sites work and what may impede their performance. Here we will dive deep on methods that anyone can use to evaluate the performance of their website: Quantitative Testing, Request Profiling, and Performance Monitoring.
Would you like to download both parts of this article in a unified white paper? Sign up to receive article updates from Cantilever and we’ll send you all of this information in a printable PDF.
If you develop a trained eye, you can start to diagnose performance problems without any technical tools.
During testing, take note of every detail you see while a slow page is loading. These seem like minor distinctions, but your understanding of the specific issue will help both you and your development team figure out what’s going on. I have only listed test results that are useful in helping you diagnose potential issues. If you come up with a “No” on a test below which only has a “Yes” point listed, that means that the results of the test don’t tell you all that much, and you should try more tests to see if they result in more informative answers.
Useful tests and what they indicate
Load a page that is usually slow.
- Does the browser’s “Loading” indicator spin and spin for a long time?
- Yes. This means your problem is most likely in Bottlenecks #1 or #2 (To understand these bottlenecks, see Part One of this article).
Ask your developers to review the server configuration and the core site resources
— No. The problem is probably in Bottleneck Three.
Ask your developers to review the site’s frontend code for functionality that might be slow.
- If you load the same page twice in a row on one device, does it speed up?
— Yes. This means the problem is solved when the browser or server cache is populated.
Make sure your development team is testing with the caches off.
- If you load a slow page on one device and then load it on a second device or incognito window, is it any faster the second time around?
— Yes. This means that the problem is most likely in Bottleneck #1, and that it is solved by “server-side caching”.
Make sure your development team is testing with the “server-side caches” off.
— No. This means that the server might not be caching your pages properly, or that Bottlenecks #2 or #3 are to blame.
Ask your development team if server-side caching is in place.
- When you load a slow page, is there any part of it that does appear quickly? Text, logos, etc?
— Yes. This means the problem is most likely in Bottlenecks #2 or #3.
Ask your development team to review visible site functionality for performance issues. Ask if a CDN is in place. For more information on CDNs, see the Solutions section at the end of this article.
— No. This means it’s more likely that the problem is in Bottleneck #1.
Ask your development team to check the server and the site backend for performance problems.
- When you load a slow page and then click through to another page on the same site that is usually slow, does the second page load more quickly than normal?
— Yes. This means the problem is most likely in Bottleneck #2. Your browser is caching the files it received from the first page and doesn’t need to download them again, so the second page load on the same site is fast.
Ask your team to review frontend resource requests for any that might be slowing things down. Ask if a CDN is in place.
— No. This means that even when your static resources are cached, the site isn’t faster. This indicates a problem in Bottleneck #1.
Ask your development team to check the server and the site backend for performance problems.
- Does the site perform noticeably better on different wireless networks? How about on a cell phone connection with tethering?
— Yes. This may indicate a problem with your normal wireless network when it comes to your website.
Check if there a corporate firewall in place that might interfere with your site.
- Is there a time of day when the problem is better or worse?
— Yes. This indicates that your server might have a slow processor or not enough memory, which can cause problems during any Bottleneck.
Ask your team to test the server and make sure it is sufficient for your site’s needs. Ask if a CDN is in place to alleviate the load on the server.
- If you load a static text file from your server (most Wordpress sites have a file called readme.html which you can access at https://yoursite.com/readme.html) is it fast?
— Yes. This indicates that the server is fast, but your site’s backend code is slow.
Ask your team to review the backend code of the website.
- If your site has a Content Management System (CMS), how does the CMS perform? Is it just as slow as the website?
— Yes. This indicates a problem with the server during Bottleneck #1 — not with your website code.
Ask your team to test the server and make sure it is sufficient for your site’s needs.
— No. This indicates that your server is probably sufficient to run your site.
- On your network, do major sites like google.com also load slowly?
— Yes. You might simply be on a bad network.
You should still attempt to optimize your site as much as possible, but your site might not actually have a major issue.
Of course, technical measurement of these factors provides a different level of detail which can be more helpful. But merely understanding ballpark factors can help you make better decisions about what to ask your development team to do.
The most immediate window you have into your site’s performance is via request profiling, a technique through which you can observe all the individual files that a browser must download in order to render your site.
Profiling tools are intimidating — even for developers. It would take a lot of learning to understand everything that you see in one.
But you don’t need to understand every detail to get a lot of value out of the technique. The screenshot above is from WebPageTest, a dead-simple profiling tool. There is also a wonderful Network Profiler available in Google Chrome, and similar ones in other browsers.
In brief, a request profiler shows you a list of all the files that the browser has to download when this page is loaded. The grid on the right shows each file’s loading process in the context of the overall timeline, represented as a colorful bar. The length of the bar and the number next to it (“123 ms”) illustrate the time it took for the browser to load that particular file.
The graph below, from a recent Cantilever project, shows how what a Request Profiler’s results look like, and how to interpret them:
- Bottleneck #1: The time it taks for the server to generate the HTML code for the page and send it to the user's browser. This should be short. Under 1 second is good.
- Bottleneck #2: The time it takes for the user's browser to load all the files in needs to actually show the page.
- Bottleneck #3: The remaining resources that must load for your site to show up completely.
What you’re looking for here is a nice smooth cascade. There should be no large gaps between subsequent bars, or bars that are significantly longer than the others.
The example above shows a fast page load so there are no delays shown, but if the site had a problem at one of the bottlenecks it would show a long bar in one of these regions.
Useful tests and what they indicate
The very first line represents the initial server response: The time it takes for the server to create the page.
- Is it over one second long?
— Yes. You likely have an issue in Bottleneck #1.
Ask your team to review the server and site backend.
— No. Your issue is probably occurring in Bottleneck #2 or #3.
Ask your team to review the site’s frontend functionality for problems.
The “Start Render” line is the point at which the page can begin showing for the user.
- Is it closer to the left side of the chart on the page, or the right?
— Left. If the page feels slow but it renders fairly quickly, you likely have an issue with Bottleneck #3.
Ask your team if there is any hidden functionality on the page that could be blocking the page from loading.
Check the bar lengths.
- Are they fairly consistent with one another?
— Yes. The problem is likely general, such as a slow network connection to your server.
Check other sites to see if they have the same problem on your network. If not, ask your team to figure out why your network connection to your website server is slow.
— No. The problem is likely to do with the bars that are much longer than the rest.
Ask your team to review the specific requests that are long.
- Are there more than 100 bars? (That’s a lot of files.)
— Yes. The problem might be in Bottleneck #2. The browser has a lot of files to load.
Ask your team if they can trim any files from the page request without affecting the page’s functionality.
- Do they vertically stack on top of each other (indicating that two things are loading at once)?
— No. The problem is likely that your server is not configured to send resources in parallel.
Ask your team if the server is configured to for HTTP/2, which allows it to send files in parallel more easily. Or, ask if they can implement a CDN.
Look at the order of the files in the left column.
- Are “third party” resources (from Google, Facebook, etc) shown first?
— Yes. This means your site is loading third-party code before your own code. This will be a problem during Bottleneck #2.
Ask your team if they can reconfigure the page’s code so that third-party requests happen after core site code requests.
Several performance review tools are available online. These allow you to plug in your site URL and run a series of pre-configured performance tests against the page. Our favorite is Google PageSpeed Insights.
While these are great, these tools are critically flawed in that they cannot track perceived performance: the actual experience of a human being within the site. It’s possible for a site to have a great PageSpeed score and still feel slow for users, or vice versa. Also, the heuristics they test are not necessarily pertinent to all situations. For instance, Google recommends that you install your Google Analytics tracking code at the top of your page for maximum reliability. But if your developers did it this way, Google PageSpeed Insights will dock your performance score since it has a rule that all scripts should be at the end of the page.
So, a bad score from a performance monitoring tool is not necessarily a bad sign. However, since Google uses their own toolkit to measure your page performance for SEO consideration, it makes total sense to genuflect towards its particular recommendations and improve your score, even if they cause little to no true performance benefit for users.
If tests like this show any suggestions with a high “Estimated Savings” (above 1 second), these are good to flag to ask your development team about. Just realize and acknowledge that they might be completely irrelevant to the real-world performance of the website.
Useful Google PageSpeed Insights tests and what they indicate
Look at the “First Meaningful Paint” metric. This shows when the page has loaded sufficiently for the user to realistically use it.
- Is it more than 2 seconds?
— Yes. Your problem is probably in Bottleneck #1 and perhaps in Bottleneck #2.
Ask your team to review the site’s main functionality for problems.
— No. If a site is slow but the First Meaningful Paint is fast, that means the problem is in Bottleneck #3.
Using your own device, try to figure out what is loading after the page originally appears.
- Are the main suggestions to do with images?
— Yes. Your problem is likely in Bottleneck #3.
Bring the suggestions to your development team.
No matter the performance problem your site is facing, it can be solved. We mentioned a few potential solutions along with the tests above. Some primary options to discuss with your team are:
Using a Content Delivery Network (CDN)
Modern sites involve dozens of individual files which each must be sent to every new visitor. This is challenging for the server, especially if the user is far away geographically. To optimize speed, your site should use a Content Delivery Network to distribute its static resources.
A CDN is a group of specialized servers which are distributed close to major population centers throughout the world. Your server is located in a single physical location, and devotes resources to processes other than just serving pages to visitors. A CDN acts as a middle layer between your server and the user, serving pages faster and saving time by sending it to them from a location closer to where they are in the world.
When the user requests a file for the first time, the CDN gets it from your server and passes it along to them from the CDN server closest to their location. But the second time a user requests that file, the CDN can send the copy it already received instead of asking your server for it again.
Many hosting companies provide a built-in CDN which is generally a good idea. Our favorite standalone CDN to suggest to your dev team is Amazon Cloudfront. We also love Cloudflare, which provides a CDN and more, but has a more complicated setup.
Reducing Third-Party Code
Especially with WordPress sites, performance problems can often boil down to how much disparate code is running when someone loads your site. If you have a site with lots of complex plugins and integrations (social media widgets, gallery plugins, page builder plugins, etc.) the main way to make things better might be to simplify.
This might mean consolidating similar functionality to use a single solution, or it might mean asking your development team to custom-build functionality for which you currently rely on third-party code.
Improving Your Hosting
For most websites, cheap shared hosting should be perfectly sufficient to hit performance goals, so we are hesitant to recommend spending more money on better hosting. But some hosting is so poor that it will make even a well-built site seem slow. If your site has a CMS like WordPress, and the Wordpress admin panel itself is slow, that’s a problem.
Some sites do hit the threshold where using more expensive and powerful hosting makes sense. If your site has times of the day during which performance suffers, your host’s server might not be powerful enough to handle your normal traffic patterns meaning that it may be time to upgrade.
As a rule of thumb, unless you are serving more than 25,000 unique visitors per month, you should probably not be spending more than $50/month on hosting.
Do’s and Don’ts
Being a Performance Hawk involves staying mindful of your site’s performance with every related decision you make. With that in mind:
- Emphasize performance when deciding how to change your site. (Don’t push your web design team to create intricate, over-the-top solutions if something simpler will do.)
- Learn as much about website performance as you can within the limits of your time and technical knowledge.
- Ask your development team about how different approaches to new features can affect performance.
- Test your site on your own regularly, especially when new features are launched.
- Assume that expensive servers will solve your performance issue.
- Make blanket assumptions about the site performance, good or bad. These will lead you to direct your team improperly. The nuances are the most important information. What is specifically wrong?
- Assume that your site performance is fine because it’s fine on your computer. Use the site in the full range of scenarios you expect people to use it in the real world.
We hope this primer has been helpful in your quest to become a more effective manager of your organization’s web presence. Despite the amount of information you’ve graciously absorbed here, this is just the beginning. Web performance is as much of an art as it is a science, but with an educated client and a dedicated development team any organization can meet their goals better when their site is snappy. And if you need any help, Cantilever is only a (fast) click away.