Building Speed: A Founder’s Guide to High-Performance Web Apps

Why Slow Web Apps Suck

Slow web apps suck. They suck so much that they made me quit my job so I can build my own super-fast app. But how do you make your web app fast?

The Front-End: Small, Shallow, and Optimistic

On the front end, you can make your file size small. The smaller the size, the quicker it can download, and the quicker it can launch and open. Once the app downloads, it’s going to be cached, but that doesn’t really matter because that very first experience when people try your app is very important in them deciding whether they want to stick around using your app or not.

Avoid vector illustrations for your icons. Even though they can look sharp, they can be really big and generally slow down your app, so try to convert these to PNGs if you can.

When it comes to the library, whichever one you choose, whether it’s React, Vue.js, Angular, or any other, try to remove all the packages that come with the library that you’re not going to be using. That’s going to reduce the file size, the DOM nodes, and everything else. When it comes to the DOM nodes, try to make them as shallow as you can. If you have a lot of DOM nodes nested on many levels, the GPU and CPU generally find it very hard to render.

Use local state with optimistic updates. Basically, what you do is you write it inside your memory store, like Vuex or Redux. Write it there, show it on your interface, and do the update for the server behind the scenes, optimistically assuming that the record is going to be updated. If it’s not, revert the changes quickly.

Use WebSockets where you can. If I am working with somebody on the same interface, it’s really nice to see information elements update in front of you in real time. Keep stuff in memory for quick access. Your browser has storage, so even when you go offline, you can load some of these elements at least for reading.

The Back-End: Close to the Silicon

On the back end, try to use a programming language that’s close to the metal. If you look at languages like Python or Java, they use virtual machines where your code gets compiled down to bytecode and then interpreted. If you can use a language where you can compile your app down to machine code, close to the silicon, that’s normally going to be faster.

Use database caching. Rather than having to request a record from the database, use strategies like write-through caching or hydration caching, so your record will be ready for you in memory without hitting the database.

Use a NoSQL database if you can. Even if you’re using a SQL database, use it in a NoSQL way. You end up having to do things like pre-prepare the data into a single record. It’s harder in a way, but then you end up with a result where you’re just directly accessing a piece of data rather than having to do joins in the background, which take up time.

The last thing is to ensure that the server is near the user. If you are calling a server from England that’s in America, there’s a 50-millisecond round trip. But if you’re calling a server in England from England, the round-trip may be only a few milliseconds.

The Results are Worth It

Building fast web apps is really hard. You have to use things like NoSQL and local state, and optimize your networking correctly. But the results are really worth it. When people use a fast app, they sense that the people who built it have put care and attention into it. You’ll have a higher chance of retaining people with your fast app rather than an app which has been done carelessly.

Experience a workspace built for speed.

Stop fighting slow tools. Join the teams who prioritize performance and ship faster with Superthread. Sign up for Superthread for free

Further Reading & Resources

• The Anti-Bloat Philosophy: Why we built a faster alternative to Jira.