How To Build a Ridiculously Fast Website — Part 6: Final Results
The quest for the fastest memecoin website on the planet is complete. The result? Even on a budget phone with janky Internet, it’s fast. On desktop, it literally loads in the blink of an eye.
The Quest for the Fastest Memecoin Website is Complete
Welcome to the 6th and final part in our series about how to build a ridiculously fast website.
In this article we’ll cover four main takeaways from our work, and show you all the performance numbers.
Here are all the articles in the series, for your convenience:
- Part 0: Introduction
- Part 1: Big Picture
- Part 2: Optimize Fonts
- Part 3: Optimize Images
- Part 4: Optimize HTML and JavaScript
- Part 5: Optimize CSS
- Part 6: Final Results (this article)
With that said, let’s dive in!
How Fast Is the New Website?
It’s fast. Really fast.
To get a rough idea of the speed across different devies, we ran some tests in Chrome, using different CPU and bandwidth throttles. This isn’t perfect, but it gives a decent picture. It also lets us compare our new site to the old one.
Let’s focus first on the Largest Contentful Paint (LCP). This is measured in seconds, and roughly tells how long it takes for the main content of the page to show up.
| LCP | Old front page | New front page | Improvement |
|---|---|---|---|
| Desktop | 0.59 s | 0.18 s | 3.3x (0.41 s) |
| Mobile (mid-tier) | 2.25 s | 0.30 s | 7.5x (1.95 s) |
| Slow mobile | 12.77 s | 1.05 s | 12.2x (11.72 s) |
Here’s what these numbers say:
- On a slow phone, the page is fast, even when applying desktop criteria.
- On desktop, the page loads in less than 200 milliseconds — literally in the blink of an eye (which for a human is 100-400 ms).
We’ve got a ton of gory details about this. But before get into those, let’s first take a step back and reflect on some big takeaways from the work.
Takeaways From the Work
Looking back at the process, here are a few things that stand out to us.
Takeaway 1: Think Holistically
Optimizing web speed requires systems-level thinking.
You start out with the objective of maximum speed. To solve this problem you have to look at the entire picture. Every part of the stack must be individually optimized, but also considered in relation to all other parts.
A couple of examples: 1) Instead of trying to express your JavaScript in a few lines less, consider ways to completely remove the need for JavaScript by using native HTML. 2) Use fingerprinting and HTTP caching to completely avoid fetching data. 3) Replace an animated GIF with still images and some JavaScript glue. And so on.
Remember the core objective, and always consider the whole picture.
Takeaway 2: Focus on The Network
Put the network front and center, right from the start.
The network is the bottleneck. So focus on making everything as lean as possible. The fewer kilobytes, the better. Of course, some other things matter too, like setting image widths and heights, and animating the right CSS properties. But these other things are generally easy. The major work is going to be reducing the page weight in kilobytes, and packaging everything tight tight tight.
In practice, this means one-shotting lean HTML, CSS, and fonts in a single bundle, to start rendering with zero delay.
Takeaway 3: Learn the Basics
For maximum speed, you have to build from scratch.
Don’t immediately reach for a framework or library. Learn HTML. Learn CSS. Learn JavaScript. Frameworks come and go, but a solid understanding of the foundations will last you a long time. To squeeze out top-tier performance, you need this kind of deep knowledge. It’s this mindset and these skills that will let you cut through the bloat, and only leave what is absolutely necessary.
It will take more effort, yes, but it’s worth it.
Takeaway 4: Some Optimizations Are Universal, Some Are Very Specific
Optimizations come in two kinds:
- Universal optimizations that can be applied in every case.
- Individual optimizations that are unique to your specific case.
Throughout the series, we have covered both categories.
In the universal category, we have things like using a CDN, subsetting fonts, using the right image compression, and minifying sources. These will be applicable to every website you build.
In the individual category, we have things like using HTML dialogs, popovers, and scroll snapping to build specific interface elements. Exactly which ones of these techniques to apply and how to apply them will depend on your unique situation.
For perfect result, you have to do both kinds.
Okay, Now Show Me the Data!
You want numbers you say? Alright. Alright. Numbers it is.
We’ll do this in two parts. First we’ll analyze the size of the page, and translate that to theoretical download times. Then we’ll benchmark the page in Chrome.
Quick links:
Page Size and Download Time
We’ll split this in two parts:
- Everything the browser needs to start rendering the page.
- Images and animations.
Let’s see how each stack up.
Loading HTML, CSS, JavaScript, and Fonts
First let’s consider everything the browser must download before it can even start rendering the page.
This will include all HTML, CSS, JavaScript, and font files. You can debate whether to include fonts here or not. Our old page had font-display set to block, so we’ll include it. In any event, having fonts come in late makes for a bad user experience.
As you will see from the numbers below, on slow connections the new page will feel much faster. On fast connections, there is little or no difference.
Download Sizes
Our new front page weighs in at an extremely lean 31.6 kB. Most of the savings came from cutting down on JavaScript, and from optimizing fonts. (All the numbers are after gzip compression.)
| Old | New | Improvement | |
|---|---|---|---|
| HTML + inline JS | 19.3 kB | 8.5 kB | |
| External JS (sync) | 95.6 kB | 0 | |
| Inline CSS | 5.6 kB | 5.1 kB | |
| External CSS | 30.4 kB | 0 | |
| Fonts | 81.2 kB | 18.0 kB | |
| Total | 232.1 kB | 31.6 kB | 7.3x (200.5 kB) |
Theoretical Download Times
In the wild, download time is going to depend on a whole lot of things. But to get a rough idea, let’s use the PageSpeed throttles for mobile and desktop, and add a faster 100 Mbps connection on top of that.
Unsurprisingly, the biggest improvement here is for the slow mobile connection. It’s almost a full second faster, for a total download time of less than 400 ms. This means the new page will definitely feel faster on slow connections.
Meanwhile, on a medium 10 Mbps connection, the difference between old and new is only around 150 ms. Not a lot, but still noticeable.
On a fast 100 Mbps connection, the difference is less than 10 ms. Nobody is going to notice such a small change.
| 1.6384 Mbps (slow) | Old | New | Improvement |
|---|---|---|---|
| Initial roundtrip | 150 ms | 150 ms | |
| Data download | 1,133 ms | 154 ms | |
| Total | 1,283 ms | 354 ms | 3.6x (929 ms) |
| 10.24 Mbps (medium) | Old | New | Improvement |
|---|---|---|---|
| Initial roundtrip | 40 ms | 40 ms | |
| Data download | 181 ms | 25 ms | |
| Total | 221 ms | 65 ms | 3.4x (156 ms) |
| 100 Mbps (fast) | Old | New | Improvement |
|---|---|---|---|
| Initial roundtrip | 10 ms | 10 ms | |
| Data download | 19 ms | 2.5 ms | |
| Total | 21.5 ms | 12.5 ms | 1.7x (9 ms) |
Loading Media (Images and Animations)
With that covered, let’s turn to images and animations.
It’s difficult to make a good comparison here.
The new page uses lazy loading. The old one didn’t. The new page optimizes loading order. The old one didn’t. This means that even if the download sizes are the same, the new page will still feel much faster.
But let’s have a look at the images and animations that need to be downloaded to display the visible part of the page on the first visit. Since the desktop and the mobile versions download different images, we’ll have to consider them separately.
This simple metric heavily favors the old page, but at least it gives a rough idea.
Download Sizes
Here are the download sizes for mobile and desktop. On desktop, we’re assuming a resolution of 1280x1280 pixels, with a pixel density of 2. On mobile, 412x900 pixels, also with a pixel density of 2.
| Download size | Old | New | Improvement |
|---|---|---|---|
| Mobile | 216.6 kB | 37.8 kB | 5.7x (178.8 kB) |
| Desktop | 631.8 kB | 349.5 kB | 1.8x (282.3 kB) |
Theoretical Download Times
Let’s use the same connections speeds again, and translate these download sizes into time.
The results here are the same as for downloading HTML, CSS, JavaScript, and fonts: On a slow mobile connection, there is a clear speedup. On a medium connection, the change is small but noticeable. On a fast, there is no perceived difference.
Note that these times stack on top of the ones from the previous section: on a slow mobile connection, the new page downloads around 1.8 seconds faster in total.
| Mobile | Old | New | Improvement |
|---|---|---|---|
| 1.6384 Mbps (slow) | 1,208 ms | 335 ms | 3.6x (873 ms) |
| 10.24 Mbps (medium) | 209 ms | 70 ms | 3.0x (139 ms) |
| 100 Mbps (fast) | 27 ms | 13 ms | 2.1x (14 ms) |
| Desktop | Old | New | Improvement |
|---|---|---|---|
| 10.24 Mbps (medium) | 534 ms | 313 ms | 1.7x (221 ms) |
| 100 Mbps (fast) | 61 ms | 38 ms | 1.6x (23 ms) |
Rendering Benchmarks
Moving from the realm of theoretical performance into actual performance, let’s benchmark.
We tested rendering times in Chrome, using the performance measurement tool. By setting various CPU and bandwidth throttles, we simulated different devices on different connection speeds:
Desktop (1280 px wide):
- 100 Mbps, 10 ms Round-Trip Time (RTT), no CPU throttle.
- 10.24 Mbps, 40 ms RTT, no CPU throttle.
Mobile (412 px wide):
- 1.6384 Mbps, 150 ms RTT, slow CPU (11.8x slowdown).
- 12.24 Mbps, 40 ms RTT, medium CPU (3.1x slowdown).
- 100 Mbps, 10 ms RTT, medium CPU (3.1x slowdown).
(The tests were done on an Apple Mac Mini, with an 8-core M2 CPU.)
We ran each test 7 times, discarded the fastest and slowest samples, and averaged the 5 remaining.
We measured two things: LCP and rendering speed.
The Largest Contentful Paint (LCP) is measured in seconds, and tells how long it takes until the largest element of content is rendered to the screen. This roughly approximates when the main content of the page is visible to the user. This depends on both the download speed and the CPU speed.
The rendering speed is also measured in seconds, and tells how much processing time the computer used to display the page. This depends on CPU speed, but not on download speed.
For LCP, here is the scoring system used by Lighthouse (and PageSpeed):
| Lighthouse score | LCP (mobile) | LCP (desktop) |
|---|---|---|
| Green (fast) | 0-2.5 s | 0-1.2 s |
| Orange (medium) | 2.5-3 s | 1.2-2.4 s |
| Red (slow) | >4 s | >2.4 s |
Rendering: Results on Desktop
Even though the rendering time on desktops (with fast CPUs) doesn’t improve at all, the LCP is much lower (faster) on the new page.
It’s considerably lower even on the fast connection. This is contrary to what was suggested by the theoretical download times we calculated above. This is because the new page optimizes loading order, so that what gets displayed on the top of the page, also gets downloaded first.
This means that even on a good connection, the new site will clearly feel faster.
| LCP (Desktop) | Old | New | Improvement |
|---|---|---|---|
| 10.25 Mbps (medium) | 2,210 ms | 470 ms | 12.3x (2,000 ms) |
| 100 Mbps (fast) | 590 ms | 180 ms | 3.3x (410 ms) |
| Rendering time (Desktop) | Old | New | Improvement |
|---|---|---|---|
| 10.25 Mbps (medium) | 443 ms | 421 ms | 1.1x (22 ms) |
| 100 Mbps (fast) | 391 ms | 432 ms | 0.9x (-41 ms) |
Rendering: Results on Mobile
Mobile is where the speedup really shows.
With a small download size and optimized loading order, we brought the LCP from 12.8 seconds all the way down to 1.1 seconds. This means the page will now feel fast, even on the slowest phones.
In fact, looking at the Lighthouse criteria above, with the slowest phone on the slowest connection, the page still scores fast, even by desktop standards.
Slower devices is also where lean and simple HTML, CSS, and JavaScript makes a difference. With CPU speed throttled, our minimalist approach shows up as much faster rendering times.
The new page truly feels fast, across the board.
| LCP (Mobile) | Old | New | Improvement |
|---|---|---|---|
| 1.6384 Mbps, slow CPU | 12,770 ms | 1,050 ms | 12.2x (11,720 ms) |
| 10.24 Mbps, medium CPU | 2,250 ms | 300 ms | 7.5x (1,950 ms) |
| 100 Mbps, medium CPU | 580 ms | 190 ms | 3.1x (390 ms) |
| Rendering time (mobile) | Old | New | Improvement |
|---|---|---|---|
| 1.6384 Mbps, slow CPU | 7,911 ms | 1,727 ms | 4.6x (6,184 ms) |
| 10.24 Mbps, medium CPU | 1,335 ms | 383 ms | 3.5x (952 ms) |
| 100 Mbps, medium CPU | 1,108 ms | 385 ms | 2.9x (723 ms) |
Thanks For Reading
And that concludes this final part of the series.
You now know exactly how we made hegecoin.com so fast. And hopefully you’ve also picked up some tricks and techniques that you can apply in your own work.
If you’re still with us, having read all the way to the end, thank you so much for reading. You have what it takes to go far in life.
Hope to see you again soon!
For convenience, here are all the parts in the series again:
- Part 0: Introduction
- Part 1: Big Picture
- Part 2: Optimize Fonts
- Part 3: Optimize Images
- Part 4: Optimize HTML and JavaScript
- Part 5: Optimize CSS
- Part 6: Final Results (this article)
Want to connect with us? Drop by our Telegram Hegequarters and say hi, or check out our account on X. Good vibes guaranteed!
Also see our GitHub for the full source code of this website.
Until next time,
— Team Hege ✌️
PS. Check out the piece “HEGE: WAVECALLER” below. This LEGENDARY collectible is up for sale on HEGE DRiP!
