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:
- The smallest widget footprint possible
- API response time < 300ms
- 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.
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.
The complete Photoslurp carousel with lightbox and all styles: < 60kb (3 times smaller than that of our next closest competitor)
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.
Average default size thumbnail served by Photoslurp’s widget: < 12kb
Average full size image served by Photoslurp’s widget: < 45kb
Lazy loading support
Insanely fast API response times
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*