Speed vs Uptime | Where to Focus This Holiday Season

Revenue and consumer confidence are at stake this holiday season for brands worldwide. Shoppers are on the prowl for deals, and their predator instincts hunt for bargains in milliseconds.

Google cites convenience, price, and availability as the top three reasons why consumers choose to shop online.

Today’s online shopping has built an expectation for ease of use, and consumers have evolved into apex shoppers. Price and convenience are linked – because good deals never last – making it more important than ever to serve your product pages rapidly with lots of visual in-stock notifications for users to grab what they want.

Unsurprisingly, speed and uptime are also linked. We find that higher server response rates lead to timeouts, and contribute to bounce rate. First, we’ll look at how speed and uptime individually affect the user experience and then we’ll focus on how to solve this complicated problem.

Some Facts About Speed

It takes 50 milliseconds for visitors to decide whether to bounce from your website. According to Wikipedia, that’s “the time interval between gear changes on a Lamborghini Aventador; with a 7-speed single-clutch automated manual transmission”.

The first 5 seconds have the biggest impact on conversion rates. Think about how annoyed you would be if you tried to place an item in a shopping cart, and it took more than 5 seconds to load.

More page elements do not always equal a better experience — some users report they would accept fewer images and assets for a smoother experience. An estimated 25% of sites could improve site speed with asset compression.

Some Facts About Uptime

Your SLA determines the amount of acceptable downtime for given time periods. Violations can carry big costs, from lost customers to legal repercussions. SLAs for uptime can sometimes be referred to in terms of 9’s. We dive into detail about those 9s, and how to set realistic goals for achieving them, here.

Downtime can affect employee productivity, customer retention, and distract from tasks at hand. There are costs associated with response, including additional infrastructure, human hours, and customer trust. Users can forgive small incidents, or even major outages outside your control while repetitive instances will “teach” them to look elsewhere. And when major sales roll around they won’t be coming back.

Businesses not prepared to face downtime will suffer from extended periods of it. Fewer outages doesn’t mean less downtime. Escalations are a good example. Let’s say that a check is in maintenance, but it fails at the end of the maintenance window. You might not know the check is down until someone manually confirms it. If that thought makes you cringe, then escalations are needed to ensure alerts are delivered continuously to your team throughout the outage.

So Where Will You Focus?

Combining check types allows you to gain specific insights on page load time, which pages suffer from slow speed, and whether those pages are reachable.


What it is: Real User Monitoring, or RUM, provides real-time data on performance based on real user sessions. These sessions are anonymized, and traffic is broken down by device, location, browser, and page URL. But RUM does carry certain requirements:

  • Requires HTML snippet
  • Requires traffic to a URL to create reports
  • Optional domain or URL grouping for specific insight into problem URLs

Meaningful Metrics

Want to know the difference between server load time, the second a user sees something, and the moment your site becomes interactive? RUM can tell you.

RUM’s bread and butter is the Average Load Time breakdown. This intricate graph presents your data in terms of how and when the user or browser can interact with your site. From server response to the time it takes for the user to see and interact with your site, it’s easy to differentiate between each stage of user interaction.

For example, DOM size can affect the computational power needed to render a web page. These small delays can cause a big gap between server response and first render — a gap that RUM will catch.

Ever wanted to know a breakdown of page load time by browser? RUM reports will tell you both by page load and first render time. You can also report on key metrics like average load time (across all URLs) at a glance.


What it is: HTTP(S) is a “basic” check type that monitors a URL for 200 OK, and returns an alert if this code is not found or if the URL does not return any expected strings. With monitoring intervals as low as 1-minute, it is our fastest method of alerting you when a site isn’t working as expected.

The HTTP(S) check is equivalent to a GET or POST request, depending on whether you wish to send data and expect a string. Due to these features, it’s possible to use it for single API endpoints to test POST and receive a response. You can also choose to monitor TLS/SSL errors, in addition to URL uptime.

Why HTTP(S)?

The HTTP(S) check is all about server response and uptime. It doesn’t need or factor in the load time of assets or the load event itself. Useful for basic up/down website monitoring, the HTTP(S) check is easy to set up and deploy with rapid monitoring for first-alert/first-response capabilities during an outage.

Server response time can tell you how your infrastructure is performing. HTTP(S) checks report on server response time, and are a good indicator as to whether your site is up and accessible.

Consider a custom threshold, which is measured in seconds, to control when and how this check is alerting you. For example, a 10 second threshold would alert you if the server load time exceeds 10 seconds for a sustained period of time.


What it is: Transaction checks are advanced checks that synthetically monitor critical customer pathways, such as logging into a website or purchasing an item. A transaction check does take into account assets loading, in fact some steps require the load event to fire.


With a minimum interval of 5 minutes, Transaction checks are robust and capable of testing just about any element you throw at them. They will tell you when something goes missing, something doesn’t work, or when performance grinds to a halt.

Why Transaction?

The Uptime.com Transaction check is most useful for testing critical transaction pathways like login forms or checkout processes. The kind where downtime translates directly into losses in revenue or service. If your customers need to access something, the Transaction check is there to make sure they can and inform you the moment they cannot.

Transaction checks have an accompanying recorder, which is a Chrome-based application that can help to expedite setup. Simply install, create a new Transaction check, and select Edit in Recorder to get started.

Don’t Compromise on Speed or Uptime

Milliseconds matter in the holiday sales rush, so you shouldn’t skimp out on monitoring for speed or uptime. A lot of trust and revenue is at stake with everything from transaction pathways, to SLA accountability.

A failed URL is bad, but quickly fixable. An entire shopping cart system failing is much much worse, and much harder to fix. Monitoring will help isolate where the pain point is.

This holiday season, there’s no reason to choose between performance or uptime when Uptime.com offers web monitoring for both. Real user experience coupled with as-it-happens alerting give you the reassurances you need that it’s up and it’s accessible.

Minute-by-minute Uptime checks.
Start your 14-day free trial with no credit card required at Uptime.com.

Get Started

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