It’s completely understandable that when implementing third party software on your hotel website, you’d want to investigate whether or not it will impact its performance - such as the speed it loads at.
Website performance analysis is a pretty complex process though, so we’ve put together a short guide to help you understand what kind of impact Triptease might have.
Performance analysis tools and metrics
There are six key metrics, which all carry a different weight in terms of how important they are to your overall website performance score. You can see the weightings in brackets next to each metric below.
- First Contentful Paint (3X)
This measures the time at which the first content is painted on the screen, even if it’s simply changing the colour of the background.
- First Meaningful Paint (1X)
This measures when the primary content of a page is visible. Primary content would include elements like titles or hero images - items of interest to the user which appear above the fold. Note that this doesn’t require anything below the fold to be rendered. This is often heavily impacted by the loading of Web Fonts, which can block the rendering of text until the font is downloaded.
- Speed Index (4X)
This shows how quickly all above-the-fold content is painted on screen. The earlier the pixels are painted, the better you score on metric. Users want an experience where most of the content is shown on the screen during the first few moments of initiating the page load. Loading more content earlier makes your customer feel like the website is loading quickly, which contributes to a positive user experience. Therefore, the lower your Speed Index, the better.
- First CPU Idle (2X)
This marks the first point at which the page could respond quickly to input, e.g. clicking, scrolling, swiping. This metric is still in beta, so may change over time.
- Time to Interactive (5X)
This marks the time at which everything is loaded such that the page will quickly respond to any user input throughout the page. That means that everything has finished loading and things like clickable buttons, etc can be interacted with by the customer. This metric is still in beta, so may change over time.
- Estimated Input Latency (0X)
This is an estimate of how long your app takes to respond to user input, in milliseconds, during the busiest five second window of page load. If your latency is higher than 50 milliseconds, users may perceive your app as laggy. This is the newest of the metrics and therefore carries no weighting currently.
All of these metrics are measured in time, and a quicker time is considered to be better.
Time to Interactive is the most impactful of the six metrics, and also the most complicated. It centers around two key concepts: Long tasks, and Network quietness:
A ‘task’ is any piece of work carried out by the browser on the main thread. The time it takes for the browser to carry out these tasks is mostly dependent on the CPU power of your device. Something which takes one second on a MacBook Pro could take up to ten seconds on a mediocre phone.
A ‘Long task’ is any which takes longer than 50 milliseconds. It is advised to break down any background processes into tasks which can be executed in chunks taking less than 50 milliseconds. That way you have a minimum of 50 milliseconds to run any code which reacts to user input. This should maintain a lag-free experience.
The loading of a page can almost always be split into three chronological sections:
- The initial HTML request. Only one request is in flight, very little else is happening on the main thread.
- The quiet period after everything has initially been loaded. The network is now quieter - just a handful of background requests.
This diagram shows the impact of these two concepts on Time to Interactive. It is measured until there are no further long tasks and the period of network quietness had begun.
Speed Index is the second most impactful metric and is essentially a measure of how quickly the above-the-fold content renders on the page. Again, it’s probably best explained using a visual example.
Here are two histograms which show how visually complete a web page is over time. Even though both examples get to 100% completion at the same time, the one on the left gets a better score because it gets to 90% completion much faster, whereas the right one takes a long time to render most of its content.
The key to a good Speed Index is making sure all of the resources which are required to render the initial above-the-fold content are prioritized, and ideally as small as possible.
Interested in learning more about performance metrics for your website? Read more about performance metrics.
How and why Triptease might impact your performance metrics
When measuring your website performance it’s important to remember that a lower performance score doesn’t necessarily mean that your customers are having a worse experience on your website. What gets recorded as a low scoring performance in your metrics may not actually have any perceivable difference for your customers. This is the difference between your ‘performance’ and the ‘perceived performance’.
For example, almost all of our products here at Triptease don’t load on your web page immediately. That’s entirely deliberate because we’ve tested exactly what time delay is most effective for showing our onsite conversion tools to your customers. However as a result of that your Speed Index could therefore be impacted - because it looks like it’s taking longer for all of the page content to appear.
It’s possible that Triptease products may also impact a website’s Time to Interactive score. This is because all of our products have to be loaded onto the page separately, which can result in multiple scripts being loaded if a page requires multiple products. We are continuously looking into ways to decrease our impact and improve performance for our hotels. If you have specific questions about your Time to Interactive performance we are happy to arrange a call to answer your questions.
What to do if you are concerned about your website performance
It’s important to remember that performance score can vary considerably from test to test - even on the same browser with no additional scripts running. It’s worth performing multiple tests and alternating between testing your performance score without Triptease and then with Triptease - ideally around 20 times. Doing this will help you to build up a table of data that should give you a clearer indication of whether it’s Triptease scripts that always seem to be causing a lower performance score.
At Triptease we have a dedicated engineering team whose focus is on speedy integrations with our products and improving their performance on hotel websites. If you’ve run sufficient tests and are still concerned that your integration with Triptease is causing performance issues for your website, please get in touch with our Customer Success Team who will be happy to help.