How Bio Link achieves its Insane Speed (<100ms)
As we set out to build Bio Link, we had two primary goals.
- It should look great.
- It should load fast. Insanely fast.
We are a design-first company so the former was covered even before we wrote our first line of code.
Speed was tricky. Bio Link might look like a simple web app, but we had a pretty long list of impressive features, like full-fledged analytics, embeds, and mobile apps. We knew it wasn’t going to be easy. Three months of iterations later, here’s how we did it.
No UI Framework For User Pages
Yes, you read that right. We decided not to use any Javascript front-end framework to render user pages (dashboard and landing pages use Nuxt.JS). We use plain HTML5, with only the required CSS and the JS that needs to run.
This was a tough decision to make; the alternative was to use a framework with SSR (server-side rendering ) to keep our front-end stack unified across dashboard and user pages. However, every framework added a considerable amount of unnecessary footprint, which increased the page size and delayed the initial load.
We used plain old HTML combined with CSS and Javascript, which will work on almost all browsers without fail.
Optimizing The Content
Serve only what’s necessary
We made sure to serve just the necessary things. We went to lengths to make sure that we only serve CSS that is being used and JavaScript that is being executed. This saves bandwidth and browser execution time.
Make sure to gzip
Every content that is served is gzipped, making sure the delivered content is compressed well enough.
Inline CSS/JS
To avoid multiple requests and chaining of requests, we are inlining all the necessary CSS and JS so that two extra requests can be saved, thus saving a chained request for the fonts. This worked well for us because CSS/JS that we use is very minimal, and I wouldn’t recommend this for a different scenario.
Blur-hashed Images
Speed is more of how you feel it than the actual theoretical speed of loading. When the page is loaded, and the images are still being fetched, you feel slow. We wanted to solve this, and thanks to BlurHash, there was a way.
From the very start, we designed our DB so that every image in the system will also have a blurhash value stored (which is a token of 15–20 characters), the blurhash can re-generate a blurred version of the image, which you can show while the image is still being loaded.
When the page is rendered from the server, we translate these blurhash tokens to images with correct src data. So that the page will already have a blurred version of images embedded just after the first request. This happens on the server, so no additional client JavaScript processing is required.
Listen To LightHouse
We were always striving to get a page-speed score of 95+, and at every stage of development, we made sure that all the lighthouse recommendations were followed so that the score stays high. Recommendations ranged from adding correct cache-control headers, loading correct weights of fonts to properly sizing images.
Lastly, Make it Fastly
No matter what you do, you need to serve your content fast across the globe at the end of the day. If our server is in North America and you are a user from the other side of the globe, it will take nearly 1 second for the request to complete. We knew we had to go with an Edge Content Delivery network, and we decided to go with Fastly. The integration was smooth. Their response time is unbelievable, and we ended up using Fastly to serve our dashboard and landing pages as well.
Thank you for reading. We hope you enjoyed the article and the app. Grab your name if you haven’t already: bio.link ⚡️
