Performance Icon


98 Stories
All Topics


Why your website should be under 14kB in size

Having a smaller website makes it load faster — that’s not surprising.

What is surprising is that a 14kB page can load much faster than a 15kB page — maybe 612ms faster — while the difference between a 15kB and a 16kB page is trivial.

The reason for this is because of how TCP works, which is nicely explained in the post. But is 14kB even a feasible reality? The author thinks so:

That 14kB includes compression — so it could actually be more like ~50kB of uncompressed data — which is generous. Consider that the Apollo 11 guidance computers only had 72kB of memory.

Once you lose the autoplaying videos, the popups, the cookies, the cookie consent banners, the social network buttons, the tracking scripts, javascript and css frameworks, and all the other junk nobody likes — you’re probably there.


Partytown runs 3rd-party scripts from a web worker

Partytown is a lazy-loaded library to help relocate resource intensive scripts into a web worker, and off of the main thread. Its goal is to help speed up sites by dedicating the main thread to your code, and offloading third-party scripts to a web worker.

Even with a fast and highly tuned website following all of today’s best practices, it’s all too common for your performance wins to be erased the moment third-party scripts are added. By third-party scripts we mean code that is embedded within your site, but not directly under your control. A few examples include: analytics, metrics, ads, A/B testing, trackers, etc.

I learned of this library during our fascinating discussion with Miško Hevery on (next week’s) JS Party.

Philip Walton

Performant A/B testing with Cloudflare workers

Philip Walton:

While most teams I talk to would love to be able to run A/B tests to accurately assess the performance impact of certain changes, the problem is pretty much every popular A/B testing tool on the market has such a negative impact on load performance that they’re essentially unusable for this purpose.

If you’re just trying to determine which of two marketing headlines converts better, then perhaps this performance difference isn’t so bad. But if you’re wanting to run an A/B test to determine whether inlining your CSS in the <head> of your pages will improve your FCP, well, those popular A/B testing tools are just not going to cut it.

He goes on to describe his process for running performant A/B tests on his static site using Cloudflare workers to swap in/out his experiments.


Python 3.11 is up to 10-60% faster than Python 3.10

One beautiful thing about open source software: how hundreds of thousands (millions?) of people’s Python apps got faster while they were sound asleep. From 3.11’s release notes:

CPython 3.11 is on average 25% faster than CPython 3.10 when measured with the pyperformance benchmark suite, and compiled with GCC on Ubuntu Linux. Depending on your workload, the speedup could be up to 10-60% faster.


SQLite or PostgreSQL? It's complicated!

Miguel Grinberg built a SQLite-backed web app for the blogging team at Twilio to track their effectiveness that started to respond slugishly when it grew much bigger than he expected (6.5 million individual daily traffic records, and with a user base that grew to over 200 employees).

He thought this might be a good time to switch to Postgres, but he wasn’t sure if the wins he expected would be realized:

Having publicly professed my dislike of performance benchmarks, I resisted the urge to look up any comparisons online, and instead embarked on a series of experiments to accurately measure the performance of these two databases for the specific use cases of this application.

In this in-depth article on Twilio’s blog (no doubt being tracked by Miguel’s web app as we speak) he goes into the details of his efforts with lots of interesting findings along the way (even a plot twist!). I’ll leave you with this statement from the end:

If you are going to take one thing away from this article, I hope it is that the only benchmarks that are valuable are those that run on your own platform, with your own stack, with your own data, and with your own software. And even then, you may need to add custom optimizations to get the best performance.

Raspberry Pi

How a single Raspberry Pi made my home network faster

Spoiler alert: it’s a Pi-hole

How does the Pi Hole work though? The Pi Hole answers your computer’s DNS queries and if it is a domain on the blacklist, it sends the request to the Pi Web server. This Web server just serves up a blank page. So instead of loading the ad from the real domain, the blank page from the Pi is downloaded, thus “blocking” the ad or metric.

How effective is the setup, in practice?

Statistically speaking our household is averaging 15% of queries blocked and a spike over a bad weather weekend of 30% blocked. It is scary and incredible to think the number of ads and metrics forced upon us, and this number continues to increase. I am delighted with the Pi Hole project and am recommending it to all.

JS Party JS Party #216

Enabling performance-centric engineering orgs

This week Amal and Nick are joined by Dan Shappir, a Performance Tech Lead at Next Insurance, to learn about enabling a performance-first mindset within your engineering org.

Dan recently left his 7+ year tenure leading performance at Wix where he and his team improved, and monitored the speed of millions of websites around the world.

Join us to learn how he lead a cultural transformation that propelled Wix sites to be faster than most other React apps in the wild - including ones built with frameworks like Next.js.

Martin Heinz

Profiling and analyzing performance of Python programs

Martin Heinz on the tools/techniques for finding bottlenecks in your Python code. And fixing them, fast.

The first rule of optimization is to not do it. If you really have to though, then optimize where appropriate. Use the above profiling tools to find bottlenecks, so you don’t waste time optimizing some inconsequential piece of code. It’s also useful to create a reproducible benchmark for the piece of code you’re trying to optimize, so that you can measure the actual improvement.

JS Party JS Party #204

JavaScript will kill you in the Apocalypse

Salma Alam-Naylor joins us this week to share her thesis that JavaScript is best in moderation, and is a liability when creating performant, resilient, and accessible web applications. Salma says we’re drunk on JavaScript, and it’s time we learn how to leverage this powerful web primitive to enhance our web experiences, alongside HTML and CSS, instead of purely relying on JavaScript to completely run the show.


ClickHouse vs TimescaleDB

Two up-and-coming database options compared:

Recently, TimescaleDB published a blog comparing ClickHouse & TimescaleDB using timescale/tsbs, a timeseries benchmarking framework. I have some experience with PostgreSQL and ClickHouse but never got the chance to play with TimescaleDB. Some of the claims about TimescaleDB made in their post are very bold, that made me even more curious. I thought it’d be a great opportunity to try it out and see if those claims are really true.

Jordan Eldredge

Speeding up Webamp's music visualizer with WebAssembly

Jordan Eldredge:’s visualizer, Butterchurn, now uses WebAssembly (Wasm) to achieve better performance and improved security. Whereas most projects use Wasm by compiling pre-existing native code to Wasm, Butterchurn uses an in-browser compiler to compile untrusted user-supplied code to fast and secure Wasm at runtime.

Speeding up Webamp's music visualizer with WebAssembly


Parcel 2 is getting a 10x compiler speedup (thanks, Rust!)

The Parcel team is excited to release Parcel 2 beta 3! This release includes a ground up rewrite of our JavaScript compiler in Rust, which improves overall build performance by up to 10x. In addition, this post will cover some other improvements we’ve made to Parcel since our last update, along with our roadmap to a stable Parcel 2 release.

A growing trend in the JS tooling world is to replace bits and pieces with Rust || Go where it makes sense and reap the performance benefits. Congrats to the Parcel team on epic results from this rewriting effort.

Parcel 2 is getting a 10x compiler speedup (thanks, Rust!)


Speed is the killer feature

Brad Dickason:

… teams consistently overlook speed. Instead, they add more features (which ironically make things slower). Products bloat over time and performance goes downhill.

New features might help your users accomplish something extra in your product. Latency stops your users from doing the job they already hire your product for.

Slow ui acts like tiny papercuts. Every time we have to wait, we get impatient, frustrated, and lose our flow.


How the V8 team made JS calls faster with this clever trick

Victor Gomes details the elegant hack (in the best sense of the word) he and the V8 team came up with to significantly increase V8’s JavaScript function call performance (by up to 40% in some cases).

Until recently, V8 had a special machinery to deal with arguments size mismatch: the arguments adaptor frame. Unfortunately, argument adaption comes at a performance cost, but is commonly needed in modern front-end and middleware frameworks. It turns out that, with a clever trick, we can remove this extra frame, simplify the V8 codebase and get rid of almost the entire overhead.

A fascinating read and fantastic performance improvements for all to enjoy.


Why wasn't Ruby 3 faster?

Noah Gibbs tries to reason through why some folks are disappointed in Ruby 3’s lack of speed improvements:

I think some of the problem was misplaced expectations. People didn’t understand what “three times faster” was supposed to mean. I don’t think people thought it through, but I also don’t think it was communicated very clearly.

So: some people understood what was promised, and some people didn’t.

What was promised?

I think Noah hits on a lot of solid points here.

 Itamar Turner-Trauring

CI for performance: Reliable benchmarking in noisy environments

Benchmarking is often not done in CI because it’s so hard to get consistent results; there’s a lot of noise in cloud VMs, so you ideally want dedicated hardware. But, it turns out you can use a tool called Cachegrind to get consistent benchmarks results across different computers, allowing you to run benchmarks in GitHub Actions, GitLab CI, etc. and still get consistent results.

0:00 / 0:00