Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Browser Choice Must Matter

A multi-part examination of the ways that browser choice has been undermined on today's mobile OSes.

Progress Delayed Is Progress Denied

Apple's iOS browser (Safari) and engine (WebKit) are uniquely under-powered. Consistent delays in the delivery of important features ensure the web can never be a credible alternative to its proprietary tools and App Store. This is a bold assertion, and proving it requires examining the record from multiple directions.

Hobson's Browser

Mobile OSes and their most successful apps have drained browser choice of meaning for more than a decade. The situation today is a complex web of intent-subverting cul de sacs that lead users to confusion and loss of control over data. Web developers, meanwhile, face higher costs and reduced ability to escape walled gardens. It's time for the charade to end.

iOS Engine Choice In Depth

A deep dive into the arguments offered by Apple and others to defend a lack of browser engine choice on iOS. Instead of raising the security floor, Apple has set a cap whilst breeding a monoculture that ensures all iOS browsers are vulnerable to identical attacks, no matter whose icon is on the home screen.

Effective Standards Work

Many folks imagine that browsers will adopt a feature because it is a standard. This is exactly backwards. This series explores the ways that all parties can continue to make forward progress in a world without immaculate working group conception of new features.

Effective Standards Work, Part 2: Threading the Needle

It's attractive to think that design can (or should) happen within a formal Working Group. A well-functioning WG should include both developers and implementers, after all. Those groups often have face-to-face meetings, and the path toward standardisation is shortest in those venues! But it doesn't work; not often enough to be useful, anyway.

The Performance Inequality Gap

As long as we continue to build only for wealthy users, the dream of a web for everyone will continue to recede before our eyes, leaving a once vibrant ecosystem a ghost-town. Creating a better web starts with respecting the limits of the hardware and networks that most of the world's users carry. This is a deep dive into those constraints, their progression, and what they mean for web developers and the tool vendors that support them.

TL;DR?

What we're doing now isn't working. Not by a long shot.

Can You Afford It?: Real-world Web Performance Budgets

Performance budgets are an essential but under-appreciated part of product success and team health. Most partners we work with are not aware of the real-world operating environment and make inappropriate technology choices as a result. We set a budget in <strong>time</strong> of &lt;= 5 seconds first-load <a href='https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive'>Time-to-Interactive</a> and &lt;= 2s for subsequent loads. We constrain ourselves to a real-world baseline device + network configuration to measure progress. The default global baseline is a ~$200 Android device on a 400Kbps link with a 400ms round-trip-time ('RTT'). This translates into a budget of ~130-170KB of critical-path resources, depending on composition -- the more JS you include, the smaller the bundle must be.

The "Developer Experience" Bait-and-Switch

We cannot continue to use as much JavaScript as is now normal and expect the web to flourish. At the same time, most developers experience no constraint on their use of JS...until it's too late. Lightweight, effective tools are here, but we're stuck in a rhetorical rut. We need to reset our conversation about 'developer experience' to factor in the asymmetric cost of JS.

The Mobile Performance Inequality Gap, 2021

A lot has changed since 2017 we I last estimated a global baseline for total page resource limits of 120-170KiB. Thanks to progress in networks and browsers (but not devices), the new baseline is much more generous: ~100KiB of HTML/CSS/fonts and ~300-350KiB of JS. But the devil's in the footnotes, and modern web development practices push the median page well above these guidelines.