Improvements to Dashboard Performance

The dashboard is what every user lands on when they log into the account application. It’s the place where multiple data sources are consolidated together and shown in a useful way. But what good is it if your dashboard takes many seconds to load?

This is a common issue we hear from those who switch to us from competitors.  When the reservations management system is slow it naturally slows everyone down. The dashboard is often a point of concern for users.


We recently noticed that the way we were supporting dashboards was also starting to show performance issues. We’re pulling large amounts of data and pulling them multiple times on the same page. This causes significant performance issues. So we changed that in a few different ways.


Caching isn’t a new concept for us, nor is it a new concept in general. Caching means once you pull the data we store a copy of it for a set amount of time. If you request the same data again during that time we return the saved, or cached, version instead of fresh data. This alone caused the performance cost to drop for the dashboard in about half.

Asynchronous Rendering of Widgets

Prior to this release we relied on the server to get nearly all of the dashboard data prior to rendering the page. This meant that as the dashboard slowed down the user would wait at a white screen before returning all of the dashboard all at once. But some widgets have larger data payloads than other. Because of this some data points could be ready but we have to wait until all are done before the page renders.

Going forward we now request the data for each widget independently. So, the default dashboard has five widgets currently. The widget that takes the longest is the calendar of reservations so prior to this update the entire page waited for all five widgets to come back with data before rendering.  Flash-forward to today and we are rendering out the dashboard with no data, then asking the server for five different sets of data. Whenever one of the widget data sets returns, it renders on the page. Those that are fast render before those that are slower. This means we’re using the concept of asynchronous programming, meaning request and receive on-demand. 

The Results

We looked at three test businesses that do high volume. We registered an average of 51% reduction in load time for DOM ready. DOM ready means that all of the HTML is been parsed by the browser but not all resources are loaded (think images and such.) We also looked at DOM load, which is when all resources are fully loaded on the page. We saw an average reduction of 50% for DOM load. We also noticed that the overall reduction improved the bigger the dataset. Put in another way: the more data a business has (i.e. the bigger the scale) the better the performance gains.

These numbers represent the first time a user visits the dashboard. But we also implement caching so subsequent views of the dashboard within the caching window will be even faster. On the first request the dashboard data, meaning the data that tells the site what a dashboard should look like and the widgets it contains, takes on average of 2.33 milliseconds. Ignoring that this is already a massive improvement from the previous experience, a cached dashboard will take less than 1 millisecond to process. On average that’s a reduction of 57% for dashboard processing time. 

Additionally the default dashboard contains five widgets. The average processing time for a widget for the first view of the dashboard is 263 milliseconds. If the same user comes back within the cache window these same widgets will process within 2 milliseconds! Even better, the widgets, once cached, will render in 99% less time than the initial load. 

We will continue to be tuning the performance of dashboards to make them even faster to help operators, users, and owners work faster and smarter. 

Miami Seaplane Lands with TRYTN

TRYTN expands its presence in Florida with Miami Seaplane, a tour and activity operator focusing on private charter and sightseeing flights in the Miami area and beyond. Miami Seaplane utilizes the online booking, reservations management system, and optional website services provided by TRYTN.

CHICAGO – TRYTN is proud to announce a new partnership with another Florida tour and activity operator. This is the first partnership with a Miami tour and activity operator. Within weeks of contacting TRYTN, Miami Seaplane is now fully live on TRYTN — booking engine, reservations management system, and website services. 

Miami Seaplane contacted TRYTN after utilizing a different provider and noticed their reservations dropped dramatically.  Within weeks of initial contact with TRYTN Miami Seaplane is now well on their way to an upcoming successful season with TRYTN, one of many to come. The fully-optimized booking engine makes it quick and easy for Miami Seaplane customers to book online while the reservations management system enables Miami Seaplane staff to intuitively manage reservations and capacity. Miami Seaplane also saw the opportunity to utilize TRYTN’s optional website services and their new website is now fast, simple, and SEO-friendly.

About Miami Seaplane

Miami Seaplane Tours had its genesis in 1995 as Fun Flight Miami, with a very humble beginning that consisted of a very passionate seaplane pilot, one Ultralight, and the desire to fly over the South Florida waters. Settling on an easily accessible area at Key Biscayne, the business was born and, after a few years, became Ultralight Adventures, with the mission of training a growing number of Ultralight enthusiasts as pilots.


TRYTN is an online booking and centralized reservation management system for tour and activity businesses. The simple, intuitive interface means setup can be completed in minutes. Businesses increase their direct sales while reducing costs by gaining access to TRYTN’s subsidized web development and marketing services.  A streamlined web presence combined with reliable software gives TRYTN partners the tools they need to succeed in the increasingly competitive activities industry. For more information visit

Transaction Search Performance Gains

Today I wanted to talk about some ways that we’re improving the performance of transactional data found in places like the transaction search page, custom report generator, transaction details page, etc. Prior to this update we were taking the entire payment record even if we didn’t need it. So, a business that does 1,000 bookings a month we’re pulling all the data for 1,000 bookings for that month even if your custom report only uses three fields from that record.

person on blocks getting ready to race

To demonstrate why this can be a significant cost for performance assume that each transaction record has 100 fields of data. Let’s also assume (for round numbers) that each of these fields is 10 bytes of data. That would make each booking record 1,000 bytes (or close to 1Kb of data which is what we will round this example to for round numbers.)  Given our example of 1,000 bookings per month that would be 1,000 Kb of data per month (or, round numbers, 1Mb of data) per month. 

Given our example we’re only generating a report for three fields so really we’re overfetching our data by 97 fields (or 970 bytes of data). Put another way, to get a report that uses these three fields we are pulling an extra 97% of data! For businesses that are high volume this causes a problem because as a business scales larger more and more data is being fetched that isn’t used. The additional data takes longer to retrieve, longer to process, and longer to render.

Dynamic Queries to the Rescue

Enter dynamic queries. With dynamic queries we are able to request which fields are returned to us from a request and only those fields. So in our above example if we’re generating a report of three transaction fields, instead of bringing back 100 fields per booking we’re bringing back three fields per booking. Substantial savings in both size of payload as well as processing time. 

We ran tests on some of our highest-volume businesses before and after this change. We pulled a month of data before this dynamic queries change was released and got a baseline of 5,678 milliseconds or 5,678  seconds to process. After this was released we ran the same report and it returned in 341 milliseconds. That’s a reduction of 94% in processing time. After the release we also used the same business and report but pulled a year of data which was returned in 3,045 milliseconds or 3.045 seconds. Pulling an additional 11 months of data took 46% less time than pulling a month of data the previous way!

Performance is one of our primary focuses because we know tour and activity operators consider time to be money. If you’re sitting around waiting for reports to generate that’s time you could be spending another way. Stay tuned for additional performance improvements as we release them.

Are Your Affiliates Working for You?

Affiliate marketing and affiliate sales channels are great ways to add supplemental revenue to your business. Typically, though, you pay a cost in the form of a commission for each affiliate to bring business to you. So how can you tell if your affiliates are bringing in enough business? How can you tell if the added commission is resulting in additional sales? How can you tell if your affiliates are continuing to perform at a high level or have bookings for a specific affiliate dropped off?

man standing at kiosk booth for tickets

Today we are announcing a new Affiliates Report to answer the above questions. The affiliates report gives you an easy-to-use report to see what bookings they’ve made, lifetime value and cost, and breakdown of affiliate bookings by month.

Lifetime Value and Cost

On the report we break down the total revenue, bookings, and average order value that each specific affiliate has brought to your business. Likewise, since most affiliates work off commission, we also provide the lifetime commissions that the system has calculated. The commission is calculated based on the commission rules that you are able to define when you set up an affiliate. 

Bookings and Breakdown

We also provide a way to see every booking details for all bookings made by your affiliates. Likewise we also provide a chart to lay out when the affiliate bookings are coming in (per month) in both number of bookings as well as the commission the affiliate earned. With this information you will start to see if an affiliate is consistent in their revenue or if they have waves of bookings.

What about OTAs?

We understand that many operators utilize OTAs such as Viator to drive more revenue. These sites are also affiliates and if you enable access to these OTAs you will also be able to break down the bookings and success of these OTAs in this report. No commission is calculated for these bookings as the commission rates are highly variable between operators. 

Package Spotlight: ESLint

Most companies have code quality and code writing standards. But similar to the CSS code standards mentioned in a different post, what good are code standards if they aren’t automatically enforced?

A peer review may catch some but not all. This is where ESLint comes in to help automatically find and suggest fixes for all of the rules we have enabled for this package.

eslint logo

We sat down and defined a specific set of code standards we were going to enforce and enabled them on ESLint. ESLint can scan on demand during development to catch issues as well as automatically on build. Some rules are just suggestions for improving code, others are considered errors and code cannot be released to production without corrections. 

Since we write our JavaScript using es6 (ECMAScript 6) we also want to enforce future code standards as a best practice today so that we can easily grow. So things like using const means this is a constant value. ESLint is smart enough to determine if you’re trying to modify a constant value. It’s also smart enough to notice you declared a variable as let but never changed it so you should use const instead.

There are performance and other optimizations that go along with ESLint. As an example if you declare a bunch of variables but never use them that just adds unnecessary memory utilization to your application and reduces readability to a developer. ESLint is a strategic package we use to help release quality code every release.

Package Name: ESLint

October 2019 Release Notes

October was a really big month in terms of new features and functionality to help tour and activity owners and operators work smarter. Big call-outs include staff management, personalized and custom dashboards, and many performance gains. 

You’ll notice we didn’t release much for the booking and embedding experiences. This month we focused mostly on account updates but not to worry, we have some big plans for booking and embedding in the coming months!

someone ideating on a white board with comps

Account Updates

  • Ability to create roles and assign staff to activity instances
  • Users can now create personalized, custom dashboards
  • Performance gains in dashboard, transactions search, and transaction details pages
  • Introduction of tours to help navigate users with new and complex features
  • Added concept of account status/health to correct issues with account set up
  • Enhanced customers report with more insights and metrics about your customers
  • Fixed an issue where some users were unable to create new pages
  • Corrected time length display of scheduled activities on reservation calendars
  • General performance, resiliency, and security enhancements

Booking and Embedding Updates

  • Additional improvements to availability calendar performance
  • Corrected an issue with date questions not allowing date selection when activity or participant was removed
  • Fixed an issue where date questions were stating they were blank when they had just been answered
  • General performance and security enhancements

General Platform Updates

  • Resiliency and security enhancements