We’re about to release the next build of Squirrel (1.18). As part of our release process, we write the release notes, a blog and host a webinar to talk about all the new things we’ve added and fixed. Whilst collating this “what’s new” information, it got me thinking about a feature which hasn’t quite made it into 1.18.
As part of the webinar we will be announcing a soft release of Designer in the Browser or DIB, as we call it internally. DIB is a browser-based experience for the Squirrel design tool. We have put a lot of effort into DIB and we were aiming to fully release it as part of 1.18. However, whilst testing we noticed that for browsers with slow internet connections, the loading experience wasn’t great. We needed to fix that experience, but did not have time to fully test the changes without impacting the 1.18 release schedule. Instead, we’re going ahead with a soft launch in 1.18 (with the known performance behaviour) and will address load times as part of the next release due out in Q1/Q2 of 2025.
Loading Performance
So, what was the issue with loading performance? Squirrel at its core is a web application. It is made up of HTML, JavaScript and CSS.
- HTML – tells the browser what elements to display on the screen
- CSS – tells the browser how to style the HTML elements
- JavaScript – adds all the interactivity to the HTML elements, and is the brains of the application.
When you launch the Squirrel Designer in the browser, the HTML loads first. This then tells the browser what and where to download the CSS and JavaScript resource files the application needs.
Squirrel is an Angular application. That means we create lots of HTML, CSS and JavaScript code. When we produce a production build, the Angular compiler concatenates and compresses all that code into a small number of JavaScript files. One of those files (our main JavaScript file) had grown to over 10Mb.
Up until now, because Squirrel has been a desktop installation, we’ve not really considered the size of these resource files. However, when moving the design experience to the web these file sizes can make a big impact. When opening DIB the browser has to download that 10Mb JavaScript file before it could render the application for the user. This isn’t a problem for high-speed internet connections. But for low bandwidth scenarios (like when I was in a hotel in Arizona) you can really feel that loading delay.
Getting Lazy
This is where lazy loading comes into play. In its current form, Squirrel loads all the JavaScript files as soon as the HTML page is opened. When there are large files, this causes the UI to lock up until all of the file has been downloaded. Once all the files have been downloaded in the browser the application becomes usable. Lazy loading is a paradigm shift, so that the application only loads the JavaScript it needs, when it needs it. Splitting that 10Mb file into multiple smaller files that are loaded on demand. Our 10Mb JavaScript file is now a collection of smaller files. On average these files are around 150Kb in size, so much quicker to download even on slow internet speeds.
On the surface it sounds like this has solved all the performance problems, but it’s more complicated than that. Lazy loading has increased the number of files that the browser needs to download. Browsers have a restriction that throttles downloads to a maximum of 6 concurrent files. This means that the 7th file requested must wait until one of the preceding 6 has completed before it starts the download. So, we may have solved performance issues with downloading large files and replaced it with new performance bottleneck as the browser queues up downloading multiple smaller files.
Testing Testing Testing
The only way to know for sure whether lazy loading solves the performance issues is to test. Refining our lazy loading implementation as we go, to find the right balance between file size and file quantity. This all takes time and effort, which is why we couldn’t delay the 1.18 release to include this solution.
Our testing needs to not only account for different download speeds but geographic location, hardware specifications etc. as well. We are leveraging tools like LambdaTest to allow us to test our updates from different geographical locations and on different configurations of hardware.
Switching to support a browser-based design experience has been a real shift to our development approach. We now must consider things like file size, bandwidth, browser restrictions when building and testing. However, this focus has resulted in improving the experience and performance of both the desktop and DIB design application. We will be taking the lessons we’ve learned to see what we can apply to the runtime experience.
