Event Listing takes a long time to load

Hi Janna!

We use the TNEW Event Listing format at UMS. Looks like you have 100 or so events on the page, and they are pulling 40+ jpg images (since you reuse some of them). Those images total over 2.2MB alone, so that could be slowing down the page a bit (I ran a quick speed test on the page at tools.pingdom.com).

Individually, the images don't seem huge, but you could probably size them down or compress a bit more. Ours are 200x200 (though they render at 50x50) and are sized around 20kb. See http://tickets.ums.org/single/EventListing.aspx. Of course we only have 14 events listed right now, so we're not seeing any issues at the moment - but I seem to remember large images plaguing us at one time or another early in our TNEW days...

This may or not be your issue - but maybe it can help!

Beth

It took me about 10 seconds, which is still definitely too slow for ideal web browsing.  I don't know how the page is coded, of course, but I have a few tips:

1) How long is it taking to pull the information through the Web API?  If that is taking a long time then there is some issue with your back end or the scope of what you are trying to pull into one page.

2) An issue we've had is that we use keywords for a lot of performance information, but there is no good way to pull keywords through the Web API: it only allows you to search for them.  Originally our coders had solved this by looping on every performance, running a search on the season based on each potentially relevant keyword, and then looping through each result set to see of the performance currently being examined was in that result set, thereby determining that the performance had that keyword attached.  There can be many such workarounds for the often idiosyncratic data structures returned by the Web API, but often they come a steep performance price.  In this case I had to build a view to pull through GetLocalData that would give me the information with only one additional API call per performance.

3) With a long list of performances returned, you might want to think about paginating the results.  That said, while your page is longer than most search results pages these days, it doesn't strike me as particularly extreme.

Hi Janna,

We're another TNEW client, recently implemented at Bard College. We've been experiencing a similar issue I believe, with the initial load of a TNEW page (after coming from our own site) taking between 5 and 10 seconds or longer to fully load. Our network infrastructure tech did some diagnostics and believes that the cause for the slowdown is primarily in API calls traveling from Dallas, TX (where TNEW's datacenter is) up to our servers in Annandale-on-Hudson.

With a normal website, the web server processes everything it needs to in a split-second, and then returns the results over the internet, which is only as slow as your connection vs. how big of a resource you are downloading. Typically, any API calls that need to happen are completed in this split second, because they are all happening to servers in the immediate vicinity of the web server. In our case, and I presume yours, since we are not RAMP customers, all of the API calls must travel cross-country to your tessitura server before the page can even begin to load to wherever it is going.

You can get a literal feel for how your pages are being loaded by using a telnet client--I just did this with your site and noticed that the page started loading about 7 seconds after the request was sent (api calls), but the load did not complete for another 7-8 seconds--this second part could in fact be due to the sheer number of events you are listing on the page. The images should not have any affect on load time from TNEW since they are not being hosted by TNEW's servers, and should continue to load after the page is displayed.

For a fun exercise, pop open a terminal window (on Mac or Linux, if you're using Windows I can't help you!), and do:

$ telnet music-tickets.yale.edu 80

After you connect (you should see just a blinking blank line), type:

GET /single/EventListing.aspx HTTP/1.1

host: music-tickets.yale.edu

... then hit enter TWICE. If you were fast enough not to cause a timeout, you should see how long it takes the server to respond, and then how long it takes to load all of the source code that makes up your page. There are, of course, many diagnostic tools that can give you hard detailed data about a page load (like Safari's Web Inspector), but you never know when telnet will come in handy.

As far as improving on speed, really the only thing you can do is make your event listing more compact. At Bard, we use a Production Season grouping so each type of event in the season doesn't get its own section -- and we still have 70-100 events on sale. We also don't put events like student recitals that aren't ticketed up on our TNEW site, or in Tessitura at all -- that's done on a calendar page that is part of our CMS, so we limit the work Tessi/TNEW needs to do to ticketed events.

The first seven seconds of silence that we both experience with our sites, however, can only be improved by better network connections between here and Dallas, presuming that our analysis is correct. We observed that packets are traveling on the Level3 backbone from Dallas through Chicago and Boston before they double back to the Hudson valley to reach our API servers. Perhaps the datacenter that TNEW is using does not have sufficient backbone connections to serve our area without excessive API call latency. Perhaps TNEWs API calls are not optimized enough, and the excessive latency is happening just because there are too many of them required to load the page. Or, perhaps neither of those things are true, and this is just what the technical limit looks like for cross-country API calls on a commerce site right now.

Hi all,

I just wanted to add in a few more suggestions from the TNEW perspective. Beth has a great point, that image size can have a significant impact on page load speed, so you'll definitely want to look at reducing the file size as much as possible.

TNEW has two display options for the event listing page. You can either display all the individual performances under each production season or you can display the listing by Production Seasons only. This is set in site controls using the "Display Listing as Prods" row. Now for the Yale School of Music site, this might appear to only collapse a little bit of information, but it actually streamlines the API calls being made on that page and prevents the site from having to retrieve the data related to each individual performance, which should noticeably improve your page load speed.

Some organizations that want to display individual performance purchase links on the event listing page, but have a lot of events on sale, have taken an alternative approach. One example of this is the Gallo Center for the Arts. They've built a static event listing page on their www site http://www.galloarts.org/Events/EventCategories.aspx that links to the TNEW event listing page filtered by keyword http://tickets.galloarts.org/single/EventListing.aspx?k=109. This breaks the event listing page down into more manageable groupings. 

There is another setting in TNEW site controls called "Use Seat Count" that can impact site performance. This setting determines whether the application looks at availability for each performance when presenting listing or purchase information. When set to true and inventory is low for a given event, your site will display a specific limited availability message. But enabling this setting will layer in additional calls to the API, so it should be used with caution when you have a lot of events on sale.

Just to shed some color on this conversation, page load speed is one metric that has numerous variables. For example, each individual's computer hardware, local bandwidth, network bandwidth (particularly for non-RAMP networks) and database environment all impact page load speed. For example, I just loaded up the Yale School of Music event listing page in my browser and it clocked in under 7 seconds. It's probably important to also mention that once this page is loaded, a lot of the data (graphics, etc.) is cached in the browser, so it will be even speedier the next time you navigate to it.

But rest assured, as a constantly evolving application, we are always looking for ways to optimize TNEW's performance and page load speed is one area we continue to fine tune. Both v4 and v5 have improved application architecture that help in this area and I'm confident future versions will continue to do the same.

If you need further assistance, please don't hesitate to open a TASK ticket in the Web Products Workspace and someone from the support team can tailor our guidance for your unique environment.

Best,
Karyn