Client Login

Under the hood: our web application performance

Neil Mukerji
16 Jun 2016 3min read

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.


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.


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.


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!

More Posts

31 May 2022 11min read

Finding The Best EPoS System For Your Hospitality Business

Finding the best system for your business can be challenging due to [...]

24 May 2024 7min read

Managing Irregular Hours: What Your Business Needs To Know

Legal changes from 1 January 2024 in the UK specifically address how [...]

02 May 2024 2min read

Stepping Up for Burnt Chefs: Our Virtual Walk Across England

We are partnering with The Burnt Chef Project to raise funds for [...]

Stay updated with the latest news and updates from Kobas.