In the past decade we’ve experienced a steady increase in the average page’s total resource size. It should come as no surprise to us that the resources that have grown the most belong in the media category; specifically images. While other resources have experienced a similar shift, images remain to be the bottleneck on an initial page load – and in a world that is constantly transitioning to mobile, with providers offering limited mobile bandwidth and data improvements, it is crucial that we prioritize its importance. In this post I will detail how we can minimize the resource payload on the initial load and detail considerations that should be made to accommodate low bandwidth visitors.

The image above (borrowed from the HTTP Archive) – demonstrates the shift in page size from November 2010.

Okay; we get it, we need to work on limiting the number of resources we use – simple right? As we all know, sometimes in the real-world we are not afforded the opportunity to make these decisions and must implement a media heavy website for clients. So what can we do? First off – I’d like to acknowledge that the web community has made great strides for increasing resource performance; specifically high-performance content delivery networks (CDN), caching and adaptive images which have all worked to increase performance. However, they are not a silver bullet for the resource load – and does not shelter us from the responsibility of delivering optimized page sizes.

Recently we had a requirement from a client to implement tabbed content with each tab containing multiple images and a possible thumbnail; something similar to the image attached below, but with multiple images per tab. The component presentation was being pulled from the Broker in a standard java tag with an accompanying tag handler to perform our content-delivery logic.

So what’s the problem? The approach described above will work just fine and the tabs can all be generated server-side and returned to the user – no issues there. However, can we do it better? After the first tab, the successive tabbed content will not be displayed until the user clicks on each respective tab, if they click on one of the tabs – something that data suggests does not happen as often as we may think. That means we will be potentially be loading a large set of images that are only ever seen by a small subset of visitors! There’s an opportunity here for a great initial load performance boost and is something we should definitely take advantage of.

The Technical design

Each one of our tabs had multiple component presentations rendered inside – so in order to classify each component to belong to a tab we represented the tabs in a Tridion Category and tagged each component in metadata with these new keywords. We wrote a standard java tag which was responsible for:

• Building the containers markup encompassing the tabbed component presentations.
• Accepting the parameters passed from Tridion (via tag parameters) and passing the to the tag handler.
• The tag handler performs the content delivery logic and returns the list of component presentations to be rendered in the first tab only.
• We render the component presentations for the first tab, however for the subsequent tabs we only render the tab that the user clicks with an appended data attribute with the Tridion keyword identifier – none of its component presentations.

At this point, all of the tabs will be displayed but only the first tabs component presentations (and media) will be loaded in the page. Next we must write an ajax request so that we can send several variables to the server such as the tab clicked (which we access via the data attribute we’ve added to the tab as described above), and finally, the java controller itself to handle the ajax request (our application is built on Spring so we used a simple Spring Controller – the request handling configuration will vary depending on the client) which will accept the parameters sent, query the broker and render the component presentations via ComponentPresentationAssembler (to execute REL etc). The servlet will then return the newly compiled markup to the client and it will be appended using some javascript logic to the appropriate tab.

Conclusion

As a takeaway, try to always consider whether or not whether a resource is mandatory upon load or is only visible conditionally – and if so consider whether or not we can load it at its request time (when a user clicks the tab). This is only one example of how we can increase performance on page load; I’d love to hear how others are working to mitigate the issues that media heavy websites introduce.

Notes:

• This design assumes that the component presentations are available in the broker (the templates are dynamic and the components published).
• We also had a bit of a unique design as the component presentations under the tabs were sorted based on publish date; but a similar approach could be followed with one component representing a tab.
• When using this approach the content delivery code should be analyzed to be as modular as possible so that the tag handler class and the servlet handling the ajax requests do not duplicate code (similar logic follows in both java files so there is an opportunity for reuse).
• If anyone would like more details on the technical design let me know and I can go into further detail.