Performance Enhancement

Just as we were going to kick back into the swing of coding things, I came across a great series of posts by Alex Russell (@slightlyoff@toot.cafe) that I think will serve folks better in terms of what one might want to dedicate precious “spare” time this weekend.

The Performance Inequality Gap

Before digging in, please take a gander at Alex’s bona fides. He knows what he’s talking about.

At the heart of Russell’s analysis is the stark performance disparity between high-end devices and “budget-friendly” options. This gap is not just a matter of faster load times or smoother animations; it fundamentally impacts how folks interact with everything we build/create. High-end device users (raises hand) generally enjoy a seamless, responsive web experience, often taking for granted the true luxury of speedy access to information and services. In contrast, those with budget devices face a frustrating, sluggish web that can deter them from accessing those things we (and, others) create, widening the digital divide.

The seven-part series highlights important areas where this inequality manifests. For instance, the multicore performance gap between premium Android devices and budget models has widened, with a significant delta in metrics that underscores this growing divide. This gap is not just about hardware; it extends to the web development practices that prioritize high-end devices. The posts also argue that the current trajectory of web development, characterized by heavy JavaScript frameworks and bloated web pages, exacerbates this inequality.

The management of web performance is not solely a technical challenge but also a matter of things we builders prioritize, and whether we even think about those downstream impacts. Alex calls for a shift towards what he dubs as “performance budgets” and encourages folks to take a more inclusive approach to web development and content creation that considers the hardware and network limitations of the majority of users. This perspective is crucial in a world where digital access is increasingly synonymous with opportunity (perhaps, even survival).

The implications of the performance inequality gap extend beyond mere frustration. They touch on broader issues of access to information, educational resources, and economic opportunities. As the web becomes the primary medium for these essential services, ensuring equitable access is not just a technical challenge but a moral imperative.

Some Cold, Hard Facts

Alex presents two sets of baseline numbers for first-load under five seconds on 75th (P75) percentile devices and networks, with separate recommendations for JavaScript-heavy content and markup-centric stacks. It’s definitely something even folks who think they’ve built a “single page” or “static site”, since I’ve done that with R Markdown/Quarto and you may be surprised at how huge those “lightweight” pages can get.

JavaScript-heavy content is more expensive to run on the client, with HTML, CSS, images, and fonts being less expensive. That first-load under five seconds budget for such content is ~1.3MB, with 650KB of HTML, CSS, images, and fonts and 650KB of JavaScript.

If you’ve been working on being “lean”, and have mostly markup-heavy content, the first-load under five seconds budget for that is 2.5MB, with 2.4MB of HTML, CSS, images, and fonts and 100KB of JavaScript.

For even us foofy iPhone owners, the delta between the fastest iPhones and moderately priced new devices rising from 1,522 points last year to 1,774 points in 2023. So, heavy content is a potential burden even with these overpriced media darlings.

Your/Our Mission

After reading through the series, there are at least three things we can do to assess where we are and make better decisions moving forward. The first two can be done from within almost any browser’s Developer Tools (more on that in a bit).

First, it’s important to take a step back and analyze the size and composition of what we’ve built. This includes HTML, CSS, images, fonts, and JavaScript (even on those “super lightweight” compiled-from-markdown documents). This will help us understand the performance impact of the content and identify areas for improvement.

Next, we need to consider the devices and network conditions apps or sites will be used on. The global device and network situation is constantly evolving, and understanding these factors will help you optimize your app or site for better performance.

Finally, we should establish formal performance budgets for any apps or sites we make, taking these two conditions into account.

Browser Developer Tools offer a detailed view of the resources loaded by a web page, including their sizes. The “Size” column in the Network tab shows the number of bytes sent over the network, while “Content” refers to the actual size of the resource uncompressed. This distinction is important for understanding the impact of compression and the actual data the browser needs to process.

Some browser Developer Tools also let us simulate various mobile devices and network conditions:

• Device Mode: This feature lets us simulate different screen sizes and resolutions, touchscreens, and other characteristics of mobile devices. It’s usually possible to be able to select from a range of preset devices or define custom device settings.
• Network Throttling: Many browser Developer Tools environments let us emulate different network speeds, including 3G, 4G, and even offline conditions, to see how content performs under various types of connections. This is also usually done through the Network tab, where there are also usually some presets.
• CPU Throttling: To get a sense of how our content might perform on slower processors, it’s also generally possible to throttle the CPU speed in the same Developer Tools area.

For a more comprehensive analysis, it’s also possible to use the Performance panel (I haven’t checked to see whether this is in Safari or Firefox) to analyze runtime performance, including frames per second and other metrics that can help you understand the responsiveness and visual stability of your site.

FIN

There’s much more information and solid steps you can take to help assess and address any performance gaps.

OK, now that we’ll be building with the best interest of the humans who will experience our creations in mind, we can finally start coding again (next week)!

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️