At TRYTN we take performance seriously. If the system isn’t fast it takes both you and your customers longer to complete tasks. It that tasks includes a purchase it literally means the time is money. The faster the system the quicker you can make money. That’s why we’re constantly looking for additional optimizations for the platform so everything runs fast and stable.
We recently compared the availability calendar between TRYTN, FareHarbor, XOLA, and Peek Pro. You can read the entire post following the link below but to summarize TRYTN came out on top in both time to first byte (TTFB) as well as content download time.
Today we want to announce an additional improvement to our availability calendar that dramatically decreases both the size of the calendar data to download as well as the total download time. This does improve our overall numbers from the previous post as well. The time to first byte (TTFB) of the availability calendar decreased an additional 21% from the already very fast speed the calendar was responding with.
But today we wanted to focus on some other numbers that represent some dramatic optimizations we’ve made to the availability calendar: overall calendar data size as well as overall calendar data download time.
Calendar Data Payload Size
No matter how optimized an application is for performance the overall size of what’s being requested dictates a significant part of both actual performance and perceived performance. Actual performance is the actual amount of time to complete a task (i.e. create the availability calendar data.) With perceived performance it’s the time the user thinks, or perceives, it takes to complete a task (i.e. get availability calendar data and render on the screen to the user.)
In the above chart we looked at five random products. Some products were simple recurrence patterns of once a day with a single time slot and single price. Others were repeated multiple times a day with multiple prices. What we see in the blue bar (before optimization) is even the fastest, most optimal products were larger in size than the red bars (after optimization.)
The businesses that do offer multiple time slots per day as well as multiple pricing options per time slot benefit the most from this optimization. All told. our tests show a dramatic 81% average reduction in overall availability calendar data size.
This is important because the size of this directly impacts your customers. The application may send the data extremely fast but if the customer is on a slow connection (think mobile devices) a large amount of data takes longer than a small amount of data. With this optimization users will be waiting less time because they are downloading around one-fifth of the data as before.
Calendar Data Download Timing
Next we looked at how long it takes to download the availability calendar data after it comes back from the server. This metric will vary depending on the internet connection speed each user happens to have. But in this test we looked at the same five products again before and after this new optimization.
With the above chart we again see that the overall time it took to download each month of calendar data decreased. This is expected since the amount of data (as seen in the previous example) also decreased. Overall we saw an average 29% reduction in download time for the availability calendar data.
Summary
After we released this most recent set of optimizations for the availability calendar we saw performance improvements across the board. The time to first byte (TTFB) decreased an additional 21%, the availability calendar data size decreased on average 81%, and the time it takes to download the availability calendar payload dropped 29% on average.
When was the last time you compared the performance of your current booking solution?
