How Stanza works with customers to improve performance.

Stanza
Stanza
Published in
4 min readMar 5, 2020

Stanza’s products are embedded on 30 publisher sites that reach 30M+ monthly uniques.

A constant challenge as we’ve scaled, is improving speed, performance and reducing overall clutter. We’ve pushed a number of features over the past year to drive user engagement, but along the way have hit a tradeoff with latency.

One of our customers, RealGM, was experiencing slow load times due to page latency from our code. Below is a report that our excellent Senior Full Stack Engineer Frankie Flores put together to help solve this issue while maintaining user engagement metrics.

StanzaCal on a RealGM page.

REALGM SPEED IMPROVEMENT REPORT

In an effort to improve page performance with RealGM, we found the biggest bottleneck was image fetching. Since a single StanzaCal can display anywhere from 5 to 100 high resolution images at a time, we decided to implement the following changes:

  1. Image Compression
  2. Image Size

We believe that the asset’s file size average is way too big given the display size of the images, averaging 600KB for 50x50 pixel images. With the help of many lossless compression algorithms, we believe that we can dramatically reduce file size, without losing quality.

Image Compression

Our high resolution images and logos averaged around 800KB — 2MB per asset. After finding the correct lossless compression algorithm, we ran all associated assets through this compression and found that we were able to reduce image size by an additional ~60%, bringing our average assets size down to approximately 200KB.

Image Size

We have many different StanzaCal styles, including our timeline view (on Stanza.co), horizontal, grid, and finally vertical. All of these were sharing the same resources for images, with our grid view requiring the largest sizes of these assets. Since we were sharing these assets, they were way too big and were scaled down to fit in our horizontal view (images were over 150px in width when the largest we displayed was 50px). This wasted bandwidth. We updated each image so that the image does not need to be resized on the frontend, and we are always requesting the optimal image size.

Uninterrupted Page Load

An additional change we can make is to add the defer flag to our script tag. Since we are a widget, we want to make sure we don’t have a direct impact on the parent pages behavior. Adding this flag will move our script execution to the bottom of the call stack, making sure all RealGM code has been fired before loading StanzaCal.

Image Loading

In conjunction with the new defer flag, we will see our images load much later and this can definitely look sloppy. To clean this up, we introduced progressive JPEGs which make loading images seem much cleaner. Below is an example of what a normal image loading on the DOM will appear as:

This looks sloppy and is a poor user experience. With the introduction of progressive JPEGs, where we will see the whole image on load, but adding progressively rather than a normal baseline load:

Network Speed Tests

We saw significant improvements once both of these changes were in place. We can see from the HAR file below that images are now loading close to constant time:

With this in mind, we are able to say that images were successfully eliminated as a bottleneck, leaving us with our request to get our build file, along with our api requests:

This generated HAR file, taken directly from here proves the speed test result, further enforces our speed test result of a 285ms average load time for Stanzacal.

domComplete Event Speed Tests (Tested Using React Perf)

Standard Implementation (with ads, with uncompressed images):

Calendar Used: realgm-nfl-chiefs

Page Load Speed (seconds)

Average Load Time: 2.8932 Seconds

Compressed Implementation (with ads, with compressed images):

Calendar Used: realgm-nfl-chiefs

Page Load Speed (seconds)

Average Load Time: 1.895 Seconds

For more in our world, check out our Medium homepage.

--

--