how fast is your website title graphic

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
  1. What Influences How Fast Your Website Can Be
  2. What and How to Measure for Website Speed
  3. Speed Test Setup
  4. Acting on Results

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:

  1. First, the real address for the server is fetched from DNS
  2. A request is then sent to the server, using TCP/IP, which the data for your website
  3. Each approved request in this chain receives a 200 OK response
  4. The assembled data displays your site to the end user

how fast is your website DOM rendering tree

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.

content tree waterfall

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.

Caching Considerations

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

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.

Digital Experience

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:

CDN for how fast is your website

Location Testing

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?

Multiple Tests

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.

Get Started

Don't forget to share this post!

Avatar

Richard Bashara is Uptime.com's lead content marketer, working on technical documentation, blog management, content editing and writing. His focus is on building engagement and community among Uptime.com users. Richard brings almost a decade of experience in technology, blogging, and project management to help Uptime.com remain the industry leading monitoring solution for both SMBs and enterprise brands. He resides in California, enjoys collecting and restoring arcade machines, and photography.

Catch up on the rest of your uptime monitoring news