How Fast is Your Website? Here’s How to Figure it Out
How fast is your website, and how does application performance affect the user experience even when small changes are applied? If careful attention is not paid to content delivery and hosting, speed and performance at scale become a full-time task.
API latency, performance issues during traffic surges, and third-party services all play a role in general performance.
To understand performance, you’ll need to understand what affects it and how the user’s browser and connection play a role. There are factors you can control, and ones you can’t. The key is optimizing as you go and building with speed at the forefront of your operations.
How big of a deal is website speed?
If you’re a SaaS company, speed can mean the difference when customers rely on your reporting. It can make eCommerce experiences unbearable and frustrating.
Today, we’ll look at how to accurately measure the speed of a website. We’ll examine what impacts speed as applications grow, and what factors are outside your control. By the end of this post, you’ll be equipped for a proper speed test.
Table of Contents
What Influences How Fast Your Website Can Be
Let’s begin with the end user. Our happy little end user sits at her desk browsing your website housed on a server 10,000 miles away from her location. When her browser fetches your site, it needs to make a few separate requests that span that vast physical difference.
Your browser takes a these steps to fully render a web page:
- First, the real address for the server is fetched from DNS
- A request is then sent to the server, using TCP/IP, which the data for your website
- Each approved request in this chain receives a 200 OK response
- The assembled data displays your site to the end user
Steps two and three are linked. Each request is sent over TCP/IP, and has to be approved before it can send its data. Data is sent over Document Object Model (DOM) nodes, which are assembled into what is called the content tree. This tree is similar in nature, and structure, to the HTML markup that is used to render your site.
Uptime.com users running a RUM check will see this data visualized as Average First Render Time, just before the render tree does its work in step four.
Ready to use RUM checks for your website? Check out Uptime.com for 21 days free, no credit card required.
We can initially reduce the time it takes for the user to complete these four steps if we shorten the physical distance between us and her. That’s what caching, or using a CDN, does for you (among other uses like DDoS protection). Caching your site at a locale closer to the end user means the travel time for request(s) is shorter.
Web Hosting Does Matter
Prioritize uptime and speed in your hosting choices. The challenge is parsing the marketing material from reality, and there is no easy answer without thorough testing and reading up on the subject. Hosting reviews are helpful, but you can run a test on your own provider with an HTTPS check on your homepage. If our monitor shows anything less than 99% uptime, you may want to consult with your provider and figure out next steps. Either make a change or diagnose the issue.
Remember, not every outage is the fault of your provider. It’s possible something on your end triggered the alert, so review the technical details and use Real-Time Analysis for a timeline of recent outages.
Development is central to the speed of a site or application. Hacks and workarounds keep the system functioning, but at a cost to the user experience. As often as possible, prioritize thorough testing and remain responsive to feedback. Troubleshooting is a complex art.
The best recommendations we can make involve monitoring crucial infrastructure for detection of early problems. If you know where the issue may have originated, you can work on fixing it from within.
You should also audit for redirects, and requests you no longer need or that can be revised or improved. The tighter your code, and the fewer requests, the less the end user has to work to get that content. CDNs can help, but they can’t compensate for poor practice.
What and How to Measure for Website Speed
Testing is about ironing out all the variables you can until you’re left with a few (ideally, a binary choice) manageable properties that you can test for and against. In this line of work, sometimes we’re lucky to narrow down our troubleshooting to one of a few possibilities. This section is about testing for something specific, and includes ideas relevant to speed and performance monitoring.
Time to First Byte/Render
We have control over a few elements to a request that is made, but we can’t control the user’s location or proximity. We already know CDNs can shorten the distance between us, so our next step is to lighten the volume of data we need to carry.
Optimizing images and minifying code are some of the initial improvements that help. As you scale, auditing for resource intensive requests will improve performance. Start with your most utilized services and work backward.
Logging how content is delivered, and eliminating requests that are excessively large are critical to success. Shorten your code and do the best you can to reduce the number of requests made as well. One tactic I’ve observed is a separate CDN for images, which can help optimize in some cases.
The digital experience of your site or application is a holistic pursuit, but it’s good to think of these two concepts as linked. If you’re testing site speed, you should also test for digital experience.
Effective DEM monitoring relies on acquiring as much data as you can on the end user experience. Where they come from, how your channels perform, how your extraneous services perform, and how responsive your organization is to challenges all play a role.
We recommend that users configure RUM checks, and take the time to configure content funnels for those checks. The added data that comes from tracking a user’s path along specific goal funnels, or while browsing specific sections of your site, can fill your team in on performance bottlenecks. Synthetic monitoring can also assist when your goal is identifying where performance is most affected. A timeout at a specific point in the chain can point directly to the point of failure.
Speed Test Setup
A proper speed test relies on good preparation. A few things to keep in mind before you run your speed test:
Enable Caching or CDN as Appropriate
Be sure that all of your CDN related infrastructure is up and running prior to running your speed test.
Pro tip: test both before and after CDN is enabled for a detailed comparison of the improvements in using your CDN
Here’s an example of a speed test showing Medium.com’s CDN at work:
Choose the proper location based on what you know about your customers. Where does the bulk of your traffic originate from? What are the important outliers that still drive conversion?
Bear in mind that properly speed testing your domain means frequently testing. You should keep an eye on performance throughout various times of day, and at major events such as sales. Frequent testing gives you thorough visibility on performance, and it’s easy to compare previous speed tests.
Acting on Results
The most important aspect of measuring the speed of your site is acting on the data you acquire. You should work with your teams in-house to make sure that development is prioritizing speed, and try to adopt agile principles where it fits for your team. Fewer mistakes and faster turnaround are possible with proper testing.
Minute-by-minute Uptime checks.
Start your 21-day free trial with no credit card required at Uptime.com.