Tags: ban

The Font Loading Checklist—zachleat.com

This checklist came in very handy during a performance-related workshop I was running today (I may have said the sentence “Always ask yourself What Would Zach Do?”).

1. Start Important Font Downloads Earlier (Start a Web Font load)
2. Prioritize Readable Text (Behavior while a Web Font is loading)
3. Make Fonts Smaller (Reduce Web Font load time)
4. Reduce Movement during Page Load (Behavior after a Web Font has loaded)

The first two are really straightforward to implement (with rel="preload" and font-display). The second two take more work (with subsetting and the font loading API).

Disable scripts for Data Saver users on slow connections - Chrome Platform Status

An excellent idea for people in low-bandwidth situations: automatically disable JavaScript. As long as the site is built with progressive enhancement, there’s no problem (and if not, the user is presented with the choice to enable scripts).

Power to the people!

On HTTPS and Hard Questions - TimKadlec.com

A great post by Tim following on from the post by Eric I linked to last week.

Is a secure site you can’t access better than an insecure one you can?

He rightly points out that security without performance is exlusionary.

…we’ve made a move to increase the security of the web by doing everything we can to get everything running over HTTPS. It’s undeniably a vital move to make. However this combination—poor performance but good security—now ends up making the web inaccessible to many.

Security. Performance. Accessibility. All three matter.

Stop building for San Francisco

Overwhelmingly, our software is built by well-paid teams with huge monitors and incredibly fast computers running on a high-bandwidth internet connection. We run MacBook Pros, we have cinema displays, we carry iPhones.

That’s not what the rest of the world looks like.

Securing Web Sites Made Them Less Accessible – Eric’s Archived Thoughts

This is a heartbreaking observation by Eric. He’s not anti-HTTPS by any stretch, but he is pointing out that caching servers become a thing of the past on a more secure web.

Can we do anything? For users of up-to-date browsers, yes: service workers create a “good” man in the middle that sidesteps the HTTPS problem, so far as I understand. So if you’re serving content over HTTPS, creating a service worker should be one of your top priorities right now, even if it’s just to do straightforward local caching and nothing fancier.

Dynamic resources using the Network Information API and service workers

Smart thinking—similar to this post from last year—about using the navigator.connection API from a service worker to serve up bandwidth-appropriate images.

This is giving me some ideas for my own site.

The Bullshit Web — Pixel Envy

There is a cumulative effect of bullshit; its depth and breadth is especially profound. In isolation, the few seconds that it takes to load some extra piece of surveillance JavaScript isn’t much. Neither is the time it takes for a user to hide an email subscription box, or pause an autoplaying video. But these actions compound on a single webpage, and then again across multiple websites, and those seemingly-small time increments become a swirling miasma of frustration and pain.

I agree completely. And AMP is not the answer:

Given the assumption that any additional bandwidth offered to web developers will immediately be consumed, there seems to be just one possible solution, which is to reduce the amount of bytes that are transmitted. For some bizarre reason, this hasn’t happened on the main web, because it somehow makes more sense to create an exact copy of every page on their site that is expressly designed for speed. Welcome back, WAP — except, for some reason, this mobile-centric copy is entirely dependent on yet more bytes. This is the dumbfoundingly dumb premise of AMP.

“What does that funny squiggle mean?” Playlist - BBC Ideas

¶, &, @, ‽, ☺, #, and ☛.

What History’s Female Internet Pioneers can Teach us about Tomorrow on Vimeo

The terrific talk from Beyond Tellerrand by Claire L. Evans, author of Broad Band.

As we face issues of privacy, identity, and society in a networked world, we have much to learn from these women, who anticipated the Internet’s greatest problems, faced them, and discovered solutions we can still use today.

The Untold Story of Jaime Levy, Punk-Rock Cyber-Publishing Pioneer

This excerpt from Claire L. Evans’s new book Broad Band sounds like Halt and Catch Fire, but for real.

Many people saw the web for the first time in Jaime’s loft, on a Mac II her hacker friend Phiber Optik set up with a 28.8K internet connection. As avant-garde guitarist Elliott Sharp performed live, and another friend, DJ Spooky, played house tracks, Jaime’s guests gathered around the Mac’s small screen. At the top of 1994, there were fewer than 1,000 websites in the world, mostly personal home pages. These converts would call themselves the “early true believers,” counting the year of their arrival online as a mark of status, the way the first punks claimed 1977.

The Hipster Index: Brighton Pips Portland to Global Top Spot

Take that, Portland!

In what is quite likely the greatest, most poetic showdown since the Thrilla in Manila, Brighton and Hove of the United Kingdom beat Portland of the USA by one-thousandth of a point. Portland scored 8.1631, Brighton scored 8.1632. No really. Brighton is scientifically the most hipster city in the world. Just.

Metropolis Now - The Atlantic

A collection of essays on cities and technology. Contributors include Bruce Sterling, James Bridle, and Adam Greenfield.

Book - Broad Band — Claire L. Evans

Coming to a bookshelf near you in March 2018: the untold story of the women who made the internet.

The Go-Betweens: Right Here

This looks like a rather good documentary about the best band in the world.

Google Maps’s Moat

A fascinating bit of cartographic reverse engineering, looking at how Google has an incredible level of satellite-delivered building detail that then goes into solving the design problem of marking “commercial corridors” (or Areas Of Interest) on their maps.

Infinitown | A WebGL Experiment by Little Workshop

I reckon this could be the canonical WebGL demo.

And if I’m reading dev tools right, this is all done in 86K.

Network based image loading using the Network Information API in Service Worker | justmarkup

This is clever—you can use the navigator.connection API from a service worker (because it’s asynchronous) which means you can have a service worker script that serves differently sized images based on bandwidth.

The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts

Harry cautions against making assumptions about the network when it comes to front-end development:

Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.

Planning for the worst-case scenario is never a wasted effort:

If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.

Network Information API

It looks like this is landing in Chrome. The navigator.connection.type property will allow us to progressively enhance based on connection type:

A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when navigator.connection.type is 'ethernet' or 'wifi'.

There are potential security issues around fingerprinting that are addressed in this document.