Your site has a purpose: to inform, to inspire, to convert. To do this effectively, it needs:
clear calls to action
But if you manage your organization’s web presence, you can’t stop there.
If your site is slow, no amount of effort put into design or content can save it.
It simply will not do its job the way you want it to. If your site loads slowly, fixing its speed should be your top priority — even above major improvements to the actual user experience.
Google discovered that just a half-second increase in load times decreased recurring traffic by 20%. According to Cloudflare, just one second of additional load time decreases site conversions by 7%. Google’s search algorithm uses load time as a ranking factor, so slow sites are penalized.
The commonly accepted threshold for a fluid navigation experience is three seconds (but two is markedly better than three). Above three seconds, users will likely glance up at the progress bar, or look away from the screen. At the worst, they might start browsing another tab. Keep your load time under three seconds and your visitors will stay on your site for longer and engage more deeply in your message.
Your site is like a restaurant. No matter how exceptional the food, a long wait will kill customer satisfaction (and subsequently, business).
As the person who manages your organization’s website, you may understand the urgency of improving its speed, but if you’re not a developer, you might not know where to start. You may have a good development team, but they can’t replicate the speed issues you’re observing or may think it’s a problem with your hosting. Your hosting company might blame the vendor. Or, you might not have a team at all. Bringing in someone new with the blanket mandate to “make it faster, please” isn’t efficient or cost-effective.
Understanding the basic tenets of web performance will enable you to have more informed and productive conversations with your current or prospective development vendor.
At my web design firm, Cantilever, new customers often tell us they are redesigning partially because their existing site is slow, and they ask us how we plan to approach site speed. We’ve optimized hundreds of websites, both our own and those built by others. Our experience performing this work and educating our non-developer clients about the topic has helped us understand what people need to learn in order to be informed and effective “performance hawks” for their organization’s website.
In this article, we will outline how your site works, how problems can arise, and how to most effectively work with your development team to solve them.
Three Major Bottlenecks
Sites are not merely “slow” or “fast”. There are many processes that take place between a user typing in your URL and your website loading, and there are three specific stages in the process where problems are most likely to appear. If you understand the three major bottlenecks, you will be able to make more educated guesses as to what’s going wrong with a slow site, and what to ask your team to look into.
What Happens When a User Requests Your Website
As I wrote in How Websites Work (the Short Version), your website’s code is stored on a specialized computer called a “server”. When a user types your web address into their browser, a user’s device uses a series of address lookups to find out where your server is located, connect to it appropriately, and to request the page in question. This process can sometimes be a performance bottleneck, but rarely. Here’s where you’re likely to get caught:
Bottleneck One: The Server
After receiving the page request from the user, your server then assembles the page, often by hunting for data within a database — a special kind of file which contains all your site’s content. For instance, to show this article, the Medium server has to find the article’s text within its database so that it can construct the final page code by combining content from your database with template files. It then delivers the final results to the user’s browser. The code which manages this process is known as the “Backend”. The time the server takes to assemble the page (prior to delivering it to the user’s browser) is the first major performance bottleneck.
The page is overly complex. This is common with low-quality WordPress sites which use too many plugins.
Shared hosting. Most low-cost hosting is “shared”, meaning that your server hosts several sites in addition to your own. This means server power can be scarce, especially if another site on the server is complex.
The server has a slow processor or too little memory. Even if you have “dedicated” hosting (not shared with other sites), the server itself might simply be too slow to serve your site quickly.
Bottleneck Two: Initial Page Load
The server cannot handle sending lots of files in parallel. It might be only able to send a few at a time. This only matters if the site is sending lots of files.
The network connection is slow, or a firewall might be slowing down page load time. This has only a minor effect in Bottleneck #1, but in Bottleneck #2 it can be fatal.
Bottleneck Three: Final Page Assembly
While the browser can start rendering once it has the most important parts of your page, it must then continue loading non-essential files like images or video. It may then need to request further data from your server to load specific functionality. Sometimes, functionality on the page has a delay, even after all the files are in place. This is the final major performance bottleneck: The time it takes for the page to become “usable” after the browser has downloaded all the resources.
Images or video are larger than necessary. They might be sent at high resolution even though they are displayed at low resolution.
The site relies on complex animations or interactive elements which can only load after the browser has downloaded all files.
The page might be misconfigured and may be loading key information late in the process rather than early.
The page might rely on fonts which load slowly, so no text appears until the font file loads in.
The page might load visibly, but have slow third-party code trickling in for several seconds after. This doesn‘t affect perceived load time, but may affect SEO because Google monitors this metric.
After the page is rendered, sites can still have performance issues, such as slow and jagged animations. Those are important, but unusual for normal sites.
Becoming a Performance Hawk
Now that you understand the kinds of things that can go wrong, you can try and figure out what exactly ails your slow site. Your website is incredibly complex, but it is not a black box. You can understand where your site is failing to perform, and which of the major bottlenecks is likely an issue.
To work most effectively with your developers, it pays to make specific, actionable observations. If you understand the specific issue at hand and how to diagnose it, you will not only ask the right questions, but you’ll truly know when the problem has been solved successfully.
Cataloging the Problem(s)
To start, test. Use your site in situations your clients usually do — on the train, in the car, at a coffee shop. Try executing the normal user pathways you want your users to navigate (checkout, for instance), and note the specific parts of the process where it hiccups.
If your customers are usually on poor networks, you can simulate those networks using Google Chrome, or simply acquire a like device and try it for yourself.
Assemble a list of the pages and workflows that feel too slow to you, and the real-world scenarios in which they are failing (it’s okay if the answer is “everything”). Also note specific scenarios where the site performs well.
A major confounding factor in measuring web performance is “caching”. This is a technique where computers will store the results of long processes so that the next time they have to do that process, they can quickly use the stored version instead of performing the whole process again. Caching happens at two separate stages of a typical web request.
If configured properly, your server should cache much of the results of a page load, so that the next time someone requests that same page, it can quickly send back the results from last time rather than assembling the page all over again. After new content is published to the site, a cache like this is no longer reliable and must be “cleared”.
The browser will also cache most files it downloads during a web request. So if you load medium.com, and then come back to it next week, your browser is probably using many of the same files that it downloaded last time instead of getting everything all over again.
Because of caching, site performance can sometimes seem to oscillate between terrible and great. If a site is slow, but has well-configured caching settings, it can pass as a fast site as long as the cache is in action.
If your site is depressingly slow every now and then, or whenever you visit a page that isn’t frequently trafficked, you may be dealing with a caching issue. You will want to test the site in all its possible states, including with a totally fresh cache.
To test your site with a clear browser cache, you can hold the shift key and click “reload”, or load the page in a new Incognito/Private window. However, testing your site with a clear server cache is more difficult. If your site has a CMS, try publishing a totally new test page, then loading it. You also might have control of your site cache in your CMS or hosting settings.
Real vs. Perceived Performance
Good restaurants have perfected the art of timing. Just before you begin to wonder where the waiter is, they appear. Right when you start feeling peckish, bread arrives. Web performance is much the same. If your users don’t notice a problem, then there isn’t that much of a problem. Of course it’s wonderful to try and exceed their expectations and deliver a site that is unexpectedly fast, but the most important metric is that your users never notice the website doing its thing: They click a link, they see the content they wanted, they are happy users. Simple as that.
A page might load instantaneously, the user may still not be seeing what they want. The screen may be dominated by a carousel that has to animate in, or an interactive map that takes time to start up. Or a page might need four or five seconds to load fully, but the top loads and renders quite quickly, so the user can start reading and interacting with the content right away.
That is why at Cantilever, we focus on perceived performance: the actual experience of real users in real-life situations. As an informed client, you should too. When you talk to your development team, pose your performance complaints in real terms: “When I load the homepage on my 4g connection, it takes around ten seconds before I actually see the image at the top of the page.”
Bad metrics aren’t the problem, bad user experience is. Use the data to inform your solutions, not as a proxy for actual testing in real-life situations.
With this base of knowledge, you can start to test your sites both qualitatively and quantitatively to help discover the underlying performance issue at hand. Even as a non-developer, there are simple tests you can run on your site to help illuminate what’s going wrong. When you bring specific, informed feedback to your development team, it will make it easier for them to understand and address the problem.
In Part Two of this article, to be released next month, we will dive in on these powerful testing methods. We’ll cover:
Qualitative field testing
We will provide an overview of each technique along with specific insights to draw from your findings. With a deeper understanding of how your site works and what might be going wrong with it, you’ll be ready to drive superior results for your organization by keeping your website quick and efficient.
This is the first half of a two-part series discussing the importance of site speed and how to improve it. To read the next part, click here.
Edited by Rebecca Testrake
Studio Manager & Magical Instigator at Cantilever