It’s simple really, the faster the UI, the faster users (such as network admins and support staff) can diagnose faults and resolve problems. This ability to quickly diagnose and resolve problems is super critical, as for many organisations, network problems cost money and the longer the problem goes on for, the more it costs.
Web-based UIs are often much maligned, primarily due to their perceived slowness. There are many reasons why web-based UI’s are slow, and unless speed is a design consideration from day one and built into every part of the product, it’s very time consuming and costly to retrofit.
UI speed has been a fundamental goal right from the start at Sinefa. The way the product is architectured, the tools we use and the design decisions we make are all determined based on guiding principles, and UI performance is right at the top of this list.
So how did we design and build a fast UI? Well, it’s not easy and there is certainly no silver bullet. For us it’s a combination of how the product is architectured at a high level and a whole bunch of techniques to achieve incremental performance increases. I’ll talk a little about these techniques later, but let me start with the high level architecture.
We decided very early on that we wanted as much of the application to be executed on the client side as possible. This includes things like switching pages, sorting tables, displaying charts, building reports, and much more. In fact, we decided that we only want to go back to the server to fetch data for reports and to get and set configuration. That’s already a huge saving as the fastest round trip to make is the one you don't need to take.
Why Dojo? Well, it provided all the necessary features to quickly build a web-based application (such as containers and widgets) as well as been able to fulfil our need for speed. All our pages are preloaded onto a Dojo StackContainer. This allows multiple pages to be rendered, but only shows one at a time. So when a user clicks a menu item or a link that navigates to another page, instead of going back to the server and fetching the page content, we’ve already downloaded it in anticipation of the user wanting to access it - so its loaded locally.
One of the slowest parts of any UI is dealing with large amounts of data. We are not immune from this problem, several of our reports can easily return thousands of records of information. To deal with this, we use the dgrid package. This is a table widget that can dynamically handle millions of records. The table can be filtered, sorted and resized almost instantly without needed to reload any data from the server.
Some of the other techniques we use are listed below.
- Rolled-up and compressed CSS and JS files. Our application makes use of well over 50 CSS and JS files, and if the browser has to load these individually it would take some time. The production version of our application rolls up multiple CSS and JS files into a single CSS and JS file, and compresses them so the browser downloads only 1 CSS and 1 JS file in compressed format.
- CSS Sprites. Images such as icons are rolled up into a single image file, rather than individual files. This means only 1 file is downloaded that contain all our images and CSS positioning is used to display the area of the image we are interested in.
- Asynchronous Server Requests. All requests to the server are performed asynchronously. That is, a request is made and the application can go away and do other things instead of waiting for a response. This also means the application can make multiple requests to the server in parallel.
- Memcached Backend. Data in the backend is stored in memcached, so multiple requests for the same information can be served very quickly.
- CDN for static content. All our static content is hosted on a CDN that allows it to be fetched from a server close by. This helps in speeding up initial application load time.
- Geographically disperse, load balanced servers in the cloud. Our application is hosted on different cloud servers all over the world, meaning customers can be connected to the application server closest to them. Each application server is actually made up of several applications servers, all sitting behind a load balancer that performs SSL termination, further reducing load on each application server.
This is just a brief overview of UI performance at Sinefa and how we’ve gone about providing a great user experience.