Tags: performance



Useful accessibility resources

A whoooole bunch of links about inclusive design, gathered together from a presentation.

It’s Dangerous to Go Stallone. Take Glyphhanger | Filament Group, Inc., Boston, MA

You’ll need to be comfortable with using the command line, but this is a very useful font subsetting tool from those clever folks at Filament Group.

Campaign. — Ethan Marcotte

Ethan is understandably dubious about Google’s recent announcement regarding the relaxation of the AMP’s iron fist.

Because it’s great to hear the AMP team make some overtures toward a more open web—and personally, I’d like to thank them sincerely for doing so. But if we’re swapping one set of Google-owned criteria for another set of slightly more permissive Google-owned criteria, I’m not sure how much will have changed.

Standardizing lessons learned from AMP – Accelerated Mobile Pages Project

This is very good news indeed—Google are going to allow non-AMP pages to get the same prioritised treatment as AMP pages …if they comply with the kind of performance criteria that Tim outlined.

It’ll take time to get there, but I’m so, so glad to see that Google aren’t going to try to force everyone to use their own proprietary format.

We are taking what we learned from AMP, and are working on web standards that will allow instant loading for non-AMP web content. We hope this work will also unlock AMP-like embeddability that powers Google Search features like the Top Stories carousel.

I just hope that this alternate route to the carousel won’t get lumped under the banner of “AMP”—that term has been pretty much poisoned at this point.

Winning on Mobile

This looks like a handy tool for doing some quick’n’dirty competitor analysis when it comes to performance: create a scoreboard of sites to rank by speed (and calculate the potential revenue impact).

Many factors contribute to an engaging mobile experience. And speed is chief among them. Most people will abandon a mobile site visit if the page takes more than a few seconds to load. Use our Speed Scorecard to see how your site stacks up to the competition.

AMP: the missing controversy – Ferdy Christant

AMP pages aren’t fast because of the AMP format. AMP pages are fast when you visit one via Google search …because of Google’s monopoly on preloading:

Technically, a clever trick. It’s hard to argue with that. Yet I consider it cheating and anti competitive behavior.

Preloading is exclusive to AMP. Google does not preload non-AMP pages. If Google would have a genuine interest in speeding up the whole web on mobile, it could simply preload resources of non-AMP pages as well. Not doing this is a strong hint that another agenda is at work, to say the least.

The Two Faces of AMP - TimKadlec.com

So, to recap, the web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.

This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.”

Spot on, Tim. Spot on.

If AMP is truly for the open web, de-couple it from Google search entirely. It has no business there.

Look, AMP, you’re either a tool for the open web, or you’re a tool for Google search. I don’t mind if you’re the latter, but please stop pretending you’re something else.

Seva Zaikov - Single Page Application Is Not a Silver Bullet

Harsh (but fair) assessment of the performance costs of doing everything on the client side.

Welcoming Progressive Web Apps to Microsoft Edge and Windows 10 - Microsoft Edge Dev BlogMicrosoft Edge Dev Blog

It’s really great to hear about how Microsoft will be promoting progressive web apps as first-class citizens …but it’s really unhelpful that they’re using this fudgy definition:

Progressive Web Apps are just great web sites that can behave like native apps—or, perhaps, Progressive Web Apps are just great apps, powered by Web technologies and delivered with Web infrastructure.

Although they also give a more technical definition:

Technologically speaking, PWAs are web apps, progressively enhanced with modern web technologies (Service Worker, Fetch networking, Cache API, Push notifications, Web App Manifest) to provide a more app-like experience.

Nice try, slipping notifications in there like that, but no. No, no, no. Let’s not fool ourselves into thinking that one of the most annoying “features” of native apps is even desirable on the web.

If you want to use notifications, fine. But they are absolutely not a requirement for a progressive web app.

(A responsive design, on the other hand, totally is.)

Workers at Your Service | WebKit

Here’s an interesting insight on how WebKit is going to handle the cleanup of unused service workers and caches:

Service worker and Cache API stored information will grow as a user is browsing content. To keep only the stored information that is useful to the user, WebKit will remove unused service worker registrations after a period of a few weeks. Caches that do not get opened after a few weeks will also be removed.

Bad Month for the Main Thread - daverupert.com

JavaScript is CPU intensive and the CPU is the bottleneck for performance.

I’m on Team Dave.

But darn it all, I just want to build modular websites using HTML and a little bit of JavaScript.

Finding Dead CSS – CSS Wizardry

Here’s a clever idea from Harry if you’re willing to play the long game in tracking down redundant CSS—add a transparent background image to the rule block and then sit back and watch your server logs for any sign of that sleeper agent ever getting activated.

If you do find entries for that particular image, you know that, somehow, the legacy feature is potentially still accessible—the number of entries should give you a clue as to how severe the problem might be.

Third-Party Scripts | CSS-Tricks

Hell is other people’s JavaScript.

Third-party scripts are probably the #1 cause of poor performance and bad UX on the web.

A Browser You’ve Never Heard of Is Dethroning Google in Asia - WSJ

I’m always happy to see a thriving market of competition amongst browsers—we had a browser monopoly once before and it was a bad situation.

(That said, UC Browser has its own issues.)

Why Web Developers Need to Care about Interactivity — Philip Walton

Just to be clear, this isn’t about interaction design, it’s about how browsers and become unresponsive to interaction when they’re trying to parse the truckloads of Javascript web developers throw at them.

Top tip: lay off the JavaScript. HTML is interactive instantly.

News | Voyager 1 Fires Up Thrusters After 37 Years

I want to build websites that perform this well.

On Tuesday, Nov. 28, 2017, Voyager engineers fired up the four TCM thrusters for the first time in 37 years and tested their ability to orient the spacecraft using 10-millisecond pulses. The team waited eagerly as the test results traveled through space, taking 19 hours and 35 minutes to reach an antenna in Goldstone, California, that is part of NASA’s Deep Space Network.

Lo and behold, on Wednesday, Nov. 29, they learned the TCM thrusters worked perfectly — and just as well as the attitude control thrusters.

edent/SuperTinyIcons: Under 1KB each! Super Tiny Icons are miniscule SVG versions of your favourite website and app logos

These are lovely little SVGs of website logos that are yours for the taking. And if you want to contribute an icon to the collection, go for it …as long as it’s less than 1024 bytes (most of these are waaay less).

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.