Neil Mukerji
Technical post alert!
Continuing on from our popular post about PHP 7, here’s another technical topic for those interested in what goes on under the hood at Kobas. This post describes the techniques we use to make sure that Kobas Cloud is always nice and quick, even when you’re on a mobile device with a weak connection.
Our web assets
Kobas helps you to manage your assets, which are probably fairly tangible things like food and drink. Our assets are less easy to physically grasp, and today I’m going to discuss the way we control and distribute the web files that make the Kobas Cloud platform tick. Specifically I’m going to talk about web asset management; that’s all the images, fonts, JavaScript and CSS files used by your web browser every time you use Kobas Cloud.
What are the challenges?
We deploy updates frequently – sometimes more than 100 in a month. Also, as the average web page is now larger than 1994’s Doom game, caching plays a vital role in both keeping browsing swift, and mobile data consumption tolerable.
While (most!) pages within Kobas Cloud weigh much less than the 2.25 MB that brought us Doom, one of our primary goals was to ensure that a web browser would never have to re-download an asset unless it was revised. However it is of course vital that the web browser always receives a new file in the event of us issuing an update to that file.
Versions and cache control
Previously we had addressed cache control by changing our Kobas software version number with every release, and ensuring that web browsers knew to re-request every single asset file as a result. Our fast-paced development environment meant that that web browsers were being required to re-download megabytes of library files many times a day, leading to a poor user experience, especially on mobile devices. Clearly we needed a better way.
We use the popular Jenkins application to manage our frequent updates for Cloud, EPoS and Loyalty. We wrote a Jenkins plugin which analyses all web assets, automatically managing versions in the event that asset had changed as a result of each release.
It doesn’t just manage our own assets either. We use many third party web libraries such as AngularJS and JQuery, so we made sure that our Jenkins plugin could monitor these too. This ensures that every single web asset needed for any of our platforms has its version monitored, so your device will only ever need to request web asset files if something has actually changed.
Minimising page weight
The next step was to ensure that all CSS and JavaScript files were minified and compressed. This means that when a cached copy of a file becomes invalid, the replacement uses as little bandwidth as possible. We employed Gulp to minify and compress changed files, before issuing them with a unique file name to eliminate any chances of a cached copy being used.
Distribution
Finally all web assets are uploaded to the AWS Cloudfront service with a far future expiry header. This means that our web files are hosted at a number of high capacity data centres all around the globe, ensuring rapid delivery to the web browser no matter where that might be. By setting a far future expiry header we instruct the web browser that it won’t need a new copy of that file for a long time, meaning it should always keep a local copy. When we update that file, our deployment system will save it with a new name so that new file will be requested instead.
Results
We ran some tests on three pages in Kobas Cloud. The Landing page (complete with a bunch of modules), the New Stock Order page, and the Venue Management page. We noted the total page weight without caching, reloaded with natural browser caching, and then again once we had all of the above measures in place.
| Page | Original Weight | Standard Cache Weight | Kobas Kache Weight |
|---|---|---|---|
| Landing page | 688 kB | 421 kB | 22 kB |
| New Stock Order page | 495 kB | 204 kB | 66 kB |
| Venue Management page | 462 kB | 193 kB | 51 kB |
The Landing page differs from the other two test pages because it runs on an older framework. It does however seem to be more amenable to caching, as it has fewer interactive widgets which we don’t cache. So it’s a special case, but it does weigh just 5% of the previous cached version.
The other two pages are both less than a third of the weight of the previous cached version. And any time we change something, you’ll only need to re-download those files that have changed.
Benefits
All this adds up to ensure that interactions with Kobas are as snappy as possible. We hope that, even on a slow computer or a weak internet connection, you’ll find Kobas applications easy to use and quick to respond.
That’s our primary motivation, but a neat side-effect is that all this is now entirely automatic. We click a button in Jenkins and (so long as the automated tests pass) the web assets are analysed, and any changed or new files are minimised, compressed, renamed, pushed to Cloudfront, and all references in the main source code are updated before that is then deployed. Great stuff!
