When evaluating a booking engine and reservation management provider it’s important to consider many different metrics of evaluation. Today I wanted to talk about performance and why it matters to your customers. We’re going to be evaluating two key performance metrics: time to first byte (TTFB) and content download, and why these metrics are important to look at. We’re going to compare ourselves with three competitiors: FareHarbor, XOLA, and PeekPro. In this example we are specifically looking at activities that meet the following qualifications: a full month of data and multiple time slots and prices.
Users want and need fast interactions. Users want such a fast experience that we now have to measure performance not in seconds but in milliseconds. The slower a site the more likely a customer will leave and find a different site. When you’re talking ecommerce sites that means a customer could become frustrated with the slow performance of your booking engine and leave to book with a competitor instead.
Time to First Byte (TTFB)
One of the most significant performance metrics to evaluate is the time to first byte (TTFB). In time to first byte we are measuring the time it takes between when the browser sends a request to the web server (i.e. we’ve selected an activity we want to see availability for) and when the web server sends back the first byte of the response (i.e. the availability data for the calendar.) This essentially gives us the overall performance of the web application that is powering the booking engine as well as how optimized the code is for performance.
According to Google time to first byte should be less than 200ms. While this is a server performance metric it’s a very obvious one to customers when it’s too slow. When they click on a button they expect immediate results and not a loading screen for several seconds. Below is a chart comparing the time to first byte (TTFB) for the availability calendars on TRYTN and three competitors for similar activities.
Remember you want this metric to be as small as possible and Google recommends less than 200ms. We can see that TRYTN is the leader in this space with 153ms time to first byte.
XOLA has a respectable response time. It’s within the recommendations laid out by Google for time to first byte, but it’s still 5.26% slower than TRYTN. That’s a pretty substantial amount when you’re considering a new booking and reservation system.
FareHarbor and PeekPro are both well outside the recommended time to first byte standards. FareHarbor takes 175% longer to load than the Google recommendation and 260% slower than TRYTN. Likewise, PeekPro takes 237% longer to load than the Google recommendations and 341% slower than TRYTN. Just imagine being a customer and something taking 341% longer to do than on the TRYTN booking engine?
Once the server has started to return the availability calendar data the Content Download metric measures how long it takes to download the entirety of the availability calendar data. While time to first byte (TTFB) measures the optimization of the application code, the content download metric measures the overall optimization of the data payload. Meaning, is the data being returned a small enough package to load fast on all devices and networks.
There isn’t really any defined goal to be under a certain amount in this case. This all is dependent upon the amount of data being returned. You just want the data payload to be small so it’s fast. At TRYTN we constantly come up with better data optimizations in order to make the system perform as fast as possible and the availability calendar is one of the most heavily-focused in this effort. Below is a chart comparing the content download timings for the availability calendars on TRYTN and three competitors for similar activities.
TRYTN again comes out on top with 0.50ms download time for a month of availability data. In this test all activities chosen include a month of data with multiple time slots and prices to be comparable data. While XOLA was within 5% of the time to first byte the overall calendar data is much larger and therefore takes 90% longer to actually download a month of availability data.
FareHarbor edged out over 1ms in download time for the month of availability data. All told the FareHarbor calendar data took 168% longer than TRYTN to pull a similar set of data. In this test, however, the real stand out was PeekPro that took over 3ms to download the content for a month of availability data. This works out to be 512% longer than TRYTN to download equivalent data.
With this metric we’re talking milliseconds so you might ask yourself: does this even matter? Well, to your customers the answer is yes. A study from Google shows that as mobile page load time increases from 1 second to 3 seconds the probability of a user bouncing increases by 32%. Not having a booking engine that is as fast as possible is literally costing you revenue.