1
2
3
4
FASTER PAGE LOADING
Teaching a New Dog Old Tricks. 1996 Techniques still work
03
Jul 2018
Supercharge Page Loading Time
John Ince
What's Slowing Down Page Loading?
Maybe we should rephrase that question. "How do we speed up page loading?". But first maybe we should start with what's page loading and exactly what are we talking about? We want the best experience for our client's customers so the quicker our WebApps load and the quicker that we move between pages the better the experience. We're all about removing visible server round trips and all about smooth inter-page movements so anything that we can do to speed up page transitions is better. So what's the biggest objects on our web pages? Images? By far. What could we do to reduce these image sizes? Our clients upload many of these images using our live CMS system so maybe we can optimise our dynamic upload sizing algorithm. Back in 2011 we didn't think we'd have to resort to web techniques of yesteryear for optimisations, but here we are. More on that later. So here's what we did to cut down our page loading times. Images, it's all about image size.
Sucking up Data through a Straw
When we started down our pathway way back in 2011 we watched a podcast from Larry Page, a founder at Google, talking about the dire speed of data passing through the physical Internet. His quotation (sucking data up a straw) still rings very true in 2018, despite all the fibre optic hype, there's bottlenecks everywhere completely out of our control. It's still slow and unpredictable in speed. Back in 2011 we kind of presumed that things would simply get better and we could forget all ye olde techniques from the mid 1990's that we used to speed up shockingly slow network connections. We got it wrong to presume things would be faster in 7 years time. Maybe we just took our own advice of don't optimise, well not just yet, to get our huge mountain of code written. However this is the time now to optimise. Not all of our clients are on the relatively fast data connections of the Europe and the USA. Also it's about the speed of the device too. Why should we expect our customers to have the very latest hardware kit? Maybe with a little page optimisation we could get older smartphones and laptops to work really well? So, if the straw isn't that big then we just reduce the data that we suck up. Win, win.
A Golden Old Thumbnail
Well, as they say, the old ones are the best. Why not use thumbnails for list images that are relatively small? Previously we had just used the same image which were relatively large. It's an old technique but might work really well for our retail/eCommerce WebApps. So each product has both a full size quality image and also an associated thumbnail image that's relatively tiny. So when we bring back lists of products we simply use the thumbnail. It's a very, very simple enhancement that we can automate in our product image uploader BUT what about our existing clients who have thousands of products already? Simple, remember we're programmers here, we simply write some code that iterates through the full size images and creates an associated thumb. The advantages of teaming up with real software engineers. This one simple change yielded tremendous performance gains. It's obvious thumbnails would be a win. But there's much more we can do with images.
Supercharge Page Loading Time
The dreaded loading background image. Who wants to look at this. You'll practically never see this again, even on slow devices and connections.
Maybe we could reduce the Quality Image size
So the idea of a thumbnail, hardly a novelty, is a winner. Maybe our quality images for products don't have to be quite that large. Maybe we could shrink them quite a lot and nobody will notice. So that's what we did. We reduced the quality just a tad and saved a lot. Of course like everything else it's all subjective to page position/size and tailored to location. We can change per project with simple template or configuration settings. So, what about the other images on various pages varying in size and quality requirements? We can do great things with these.
Optimising our Client's Image Uploading
Our live CMS (Content Management System) allows our client to upload images easily. From products to newsfeed items to blogs, images are everywhere. We've always had an image optimisation technique to stop our users from uploading huge images but it was pretty basic. It typically tried to achieve images less then 200kb. What we thought was a healthy blend of quality and download performance. But some of our pages have many of these 200kb images and it showed on mobile and roaming data connections. So we've refactored our image up-loader and made it sensitive to the physical location of the image, and it's relative size. So put another way we simply decide on the physical image size on the page and shrink the image to what we believe is an acceptable resolution for the location. So it's no longer the catchall 200kb but tailored tiny images for specific locations. Perfect. The power of our custom content system wins again. A fairly simple change with massive improvements in image loading performance down to the reduced size.
Supercharge Page Loading Time
Take a look at the home page above. It's all custom content generated from our live CMS. Some images are tiny, some large and some medium which ALL have differing image size requirements. We now tailor image size to content, so small images are small and large are a bit bigger. Our users simply upload an image without caring about size, we do the crunching automatically. Live CMS rocks!
A Performance Bug in the Back Button
How a small, fairly trivial, bug can sometimes open up interesting possibilities and side effects. "Hey, I can't quite put my finger on it but sometimes the back button doesn't seem to work and then it happens a while later. Or maybe it's just me." A slow Internet connection or an old device is very useful at turning up these kind of performance issues that manifest themselves into a bug report. We look into ALL our automated bug reports and of course if one of our clients has asked a question. We felt it was a good time to bubble up this back button question into the current sprint since it is part of page loading even if it's backwards. So is it true, is the back button slow? The answer, yes and no, it depends on your Internet connection speed, the speed of the device and the browser that you are using. But yes there is a problem and yes we fixed it.

The Problem:
We manage our own back processing that uses the browser history API with JavaScript. We overload the standard back button action since we aren't a regular web page with standard round trip page movements. We've a single page concept for smoother page navigation and quicker response. We noticed on an old Samsung Galaxy S3 mobile phone that we could reproduce the back pause. Quite simple really, open an incognito browser window, open our eCommerce WebApp, navigate to a creator's page with products and hit the back. There's a definite lag before the action. The great art of bug fixing, if you can reproduce it then you can fix it.

The Fix:
So what's happening? Image loading, most apparent first time (until the browser caches them) and incognito browser windows. Well loading many images that are potentially quite large, particularly on slow devices and connections. Basically the back action didn't happen until all the images associated with a page load finished. We lazy load our pages so it concealed our issue, by this we mean that we load a few and then more when the user scrolls to the bottom of the page. So during the image load then the back action didn't happen. Fast devices and fast Internet connections hid this beautifully. So we know what's happening but why? It was quite a simple fix in the end. Browsers have a limit on concurrent HTTP requests, normally about 4 images at a time, and we might send 16 at the start of a lazy page load. These HTTP requests are processed by the browser using a complex algorithm for priority that we don't control. However for our single page navigation we poke in another movement URL via a HTTP request. Hence the delay. The images finish loading and the page backwards. The fix is simple. If a user clicks the back before the images have loaded then we simply cancel the pending HTTP requests by maintaining a list of current pending actions which allows the back action to happen immediately. A great optimisation for slower connections and devices.
Now Available on Samsung Galaxy S3
Now there's something that you don't here everyday. You don't need the latest phone to use our state of the art, cloud hosted WebApps. We constantly improve and refactor to bring them to users in the real world. If it works well on a phone from 2012 how will it work with a Samsung Galaxy S9? Remember great software doesn't need more and more power so we can be lazy programmers. We optimise, reduce the load which yields performance gains across ALL devices. Another winning refactor!
Comments
PROJECT PEACH
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.
READING
Blogs
Newfeed
PORTFOLIO
DBD International
The Hawthorn Gallery
ScriptTrack
Knot 2b Missed
Overview
Monero Mine
COMPANY
Home
About Us
Contact Us
Pricing
Pay Us
Copyright 2018 Project Peach