HomeBlogPhotoslurp’s Obsession With Widget Performance

Photoslurp’s Obsession With Widget Performance

We’ve been seeing an increase in questions related to our product’s performance from brands in the very first stages of their contact with us to ones that have been working with us for a number of years. The well known effect that page load times have on both conversion rates and SEO is a correlation that has consistently been increasing in importance for eCommerce managers globally. It’s also the reason why we constantly receive questions like “Will your widgets affect my sites loading speed ?” and “Do you offer performance features such as lazy loading ?” For this reason, I wanted to go into some technical detail in this blog post today to get you under the hood of our widgets and explain the design choices that have resulted in the fastest loading User Generated Content widgets in our industry. 

Designing frontend components that are to be embedded into a huge number of unknown environments and varying eCommerce platforms, as well as being expected to play nice with infinite third party components is no easy task. eCommerce sites especially tend to dedicate a significant amount of resources on ensuring low page load times to optimize their conversion rates, and, if we are to be a part of that environment, we need to ensure that what we are injecting into this environment is as optimized as possible.

Right from the drawing board, we set the following goals for ourselves: 

  1. The smallest widget footprint possible
  2. API response time < 300ms
  3. Optimized and compressed images served at as close to the size that they will be displayed.

We have been developing our widgets for over 5 years now, and we are proud to say that we’ve been able to consistently stick to our initial goals. 

Listed below are some of the design choices we’ve made that have brought us this far:

Direct page injection vs iFrame 

Staying away from embedding our widgets using iframes and, instead, directly injecting into the brand’s page was critical for us right from the beginning even though it is more difficult to get right. While an iFrame provides a sandboxed environment by default that prevents styles from the content being embedded to interfere with styles on the host page, or vice versa, the drawbacks in terms of performance are significant (a very chatty setup that requires communication between host and iframe ranging from initial load to page resize to adding in new content and everything in between, that has become even more complex since the introduction of CORS). There’s a number of other architectural reasons (some explained in this post on why the BBC moved away from iFrame’s completely), but, sticking with our primary goal of speed and responsiveness, we decided on a no iframe approach.

Asynchronous loading

Under no circumstances should our code, or our API, be able to delay the loading of any components on the host page by blocking ‘window.onload.’ Besides our embed code using the async parameter to load our widget, we ensured that we were not blocking content display under any circumstances and kept the number of HTTP requests made to a minimum.

No reliance on third party libraries

While an infinite amount of third party libraries exist for almost everything we needed to do and using them would have significantly sped up our time to launch, this was not a valid approach considering our first goal of keeping the footprint as small as possible. Using third party libraries would undoubtedly include functionality not relevant to us and add unnecessary bloat to our widget. We ended up building almost the entire widget ourselves from scratch, optimizing for speed and ensuring a modular approach to load only those components necessary for the function to be performed.

One specific reason why we chose to build our widget entirely from scratch was an issue that we initially came across with the jQuery library. Initial versions of our widget were served with a bundled jQuery library, as the jQuery that was being used on our customers’ sites were usually compressed and packaged together with other Javascript code, resulting in it not being available in the global scope and therefore not accessible to our widget. This resulted in multiple jQuery instances with different namespaces and an overall unnecessarily bloated widget and was the push we needed to remove our dependency on this library and write everything ourselves.

The result:

The complete Photoslurp carousel with lightbox and all styles: < 60kb (3 times smaller than that of our next closest competitor)

 

If you'd like to see how well these widgets would work in your website, we'd love to show you.

Request a demo of the Photoslurp platform

Compressed and optimized media

The majority of the traffic we handle comes from serving media to our customers’ website visitors; we need to ensure the media we serve is optimized for dimension and file size. Using best of breed compression algorithms and ensuring that we are serving media in the dimensions requested by the visitor we are able to keep file sizes very low.

The result:

Average default size thumbnail served by Photoslurp’s widget: < 12kb
Average full size image served by Photoslurp’s widget: < 45kb

Lazy loading support

The announcements from Google over the past years on their increasing use of page loading times as a ranking factor has had us implementing a lazy loading mechanism apart from the asynchronous loading of our Javascript components that we were already doing. With the flick of a switch in our Widget Editor, our customers can now ensure that our entire widget and its thumbnails are only loaded when the visitor scrolls to the part of the page where it lives decreasing the time even further to First Meaningful Paint

Insanely fast API response times

An extremely light and quick on its feet Javascript widget is nothing if it needs to sit there and wait for the API to deliver the goods. Optimizing database queries that do the hard work behind our API – to ensure we are returning results to the widgets as fast as possible – is a crucial part of our development process, which can be seen in performance tests against our API from locations across the globe.

The result:

Average Photoslurp API response time tested from Amsterdam

Besides all of the above, we of course also rely heavily on both client side and server side caching for further performance gains and distribute both our widget and all media we serve through a leading global CDN to cater to our customers’ visitors from all over the world.

We’re proud that the effort we’ve put into our solution has paid off, ensuring our customers all over the world get a solution that they know will not affect the performance of their page in any other way than to increase their engagement and conversion.

*Below is a comparison table from January 2020 comparing Photoslurp’s solution with the leading providers in the visual marketing space*