Tags: performance

326

sparkline

Inlining or Caching? Both Please! | Filament Group, Inc., Boston, MA

This just blew my mind! A fiendishly clever pattern that allows you to inline resources (like critical CSS) and cache that same content for later retrieval by a service worker.

Crazy clever!

Squoosh

A handy in-browser image compression tool. Drag, drop, tweak, and export.

Home  |  web.dev

I guess this domain name is why our local developmemnt environments stopped working.

Anyway, it’s a web interface onto Lighthouse (note that it has the same bugs as the version of Lighthouse in Chrome). Kind of like webhint.io.

CSS and Network Performance – CSS Wizardry

Harry takes a look at the performance implications of loading CSS. To be clear, this is not about the performance of CSS selectors or ordering (which really doesn’t make any difference at this point), but rather it’s about the different ways of getting rid of as much render-blocking CSS as possible.

…a good rule of thumb to remember is that your page will only render as quickly as your slowest stylesheet.

Designing, laws, and attitudes. — Ethan Marcotte

Ethan ponders what the web might be like if the kind of legal sticks that exist for accessibility in some countries also existed for performance.

The Three Types of Performance Testing – CSS Wizardry

Harry divides his web performance work into three categories:

  1. Proactive
  2. Reactive
  3. Passive

I feel like a lot of businesses are still unsure where to even start when it comes to performance monitoring, and as such, they never do. By demystifying it and breaking it down into three clear categories, each with their own distinct time, place, and purpose, it immediately takes a lot of the effort away from them: rather than worrying what their strategy should be, they now simply need to ask ‘Do we have one?’

AddyOsmani.com - Start Performance Budgeting

Great ideas from Addy on where to start with creating a performance budget that can act as a red line you don’t want to cross.

If it’s worth getting fast, it’s worth staying fast.

The Hurricane Web | Max Böck - Frontend Web Developer

When a storm comes, some of the big news sites like CNN and NPR strip down to a zippy performant text-only version that delivers the content without the bells and whistles.

I’d argue though that in some aspects, they are actually better than the original.

The numbers:

The “full” NPR site in comparison takes ~114 requests and weighs close to 3MB on average. Time to first paint is around 20 seconds on slow connections. It includes ads, analytics, tracking scripts and social media widgets.

Meanwhile, the actual news content is roughly the same.

I quite like the idea of storm-driven development.

…websites built for a storm do not rely on Javascript. The benefit simply does not outweigh the cost. They rely on resilient HTML, because that’s all that is really necessary here.

DasSur.ma – The 9am rush hour

Why JavaScript is a real performance bottleneck:

Rush hour. The worst time of day to travel. For many it’s not possible to travel at any other time of day because they need to get to work by 9am.

This is exactly what a lot of web code looks like today: everything runs on a single thread, the main thread, and the traffic is bad. In fact, it’s even more extreme than that: there’s one lane all from the city center to the outskirts, and quite literally everyone is on the road, even if they don’t need to be at the office by 9am.

Thoughts on Offline-first | Trys Mudford

Service Workers have such huge potential power, and I feel like we (developers on the web) have barely scratched the surface with what’s possible.

Needless to say, I couldn’t agree more!

Trys is thinking through some of the implicatons of service workers, like how we refresh stale content, and how we deal with slow networks—something that’s actually more of a challenge than dealing with no network connection at all.

There’s some good food for thought here.

I’m so excited to see how we can use Service Workers to improve the web.

How to Build a Low-tech Website?

This is fascinating! A website that’s fast and nimble, not for performance reasons, but to reduce energy consumption. It’s using static files, system fonts and dithered images. And no third-party scripts.

Thanks to a low-tech web design, we managed to decrease the average page size of the blog by a factor of five compared to the old design – all while making the website visually more attractive (and mobile-friendly). Secondly, our new website runs 100% on solar power, not just in words, but in reality: it has its own energy storage and will go off-line during longer periods of cloudy weather.

Ping! That’s the sound of my brain going “service worker!”

I’ve sent them an email offering my help.

The costs and benefits of tracking scripts – business vs. user // Sebastian Greger

I am having a hard time seeing the business benefits weighing in more than the user cost (at least for those many organisations out there who rarely ever put that data to proper use). After all, keeping the costs low for the user should be in the core interest of the business as well.

Winston Hearn | What’s best for users

The incentives that Google technology created were very important in the evolution of this current stage of the web. I think we should be skeptical of AMP because once again a single company’s technology – the same single company – is creating the incentives for where we go next.

A thorough examination of the incentives that led to AMP, and the dangers of what could happen next:

I’m not sure I am yet willing to cede the web to a single monopolized company.

Breaking the Deadlock Between User Experience and Developer Experience · An A List Apart Article

Yes! Yes! Yes!

Our efforts to measure and improve UX are packed with tragically ironic attempts to love our users: we try to find ways to improve our app experiences by bloating them with analytics, split testing, behavioral analysis, and Net Promoter Score popovers. We stack plugins on top of third-party libraries on top of frameworks in the name of making websites “better”—whether it’s something misguided, like adding a carousel to appease some executive’s burning desire to get everything “above the fold,” or something truly intended to help people, like a support chat overlay. Often the net result is a slower page load, a frustrating experience, and/or (usually “and”) a ton of extra code and assets transferred to the browser.

Even tools that are supposed to help measure performance in order to make improvements—like, say, Real User Monitoring—require you to add a script to your web pages …thereby increasing the file size and degrading performance! It’s ironic, in that Alanis Morissette sense of not understanding what irony is.

Stacking tools upon tools may solve our problems, but it’s creating a Jenga tower of problems for our users.

This is a great article about evaluating technology.

On using tracking scripts | justmarkup

Weighing up the pros and cons of adding tracking scripts to a website, from a business perspective and from a user perspective.

When looking at the costs versus the benefits it is hard to believe that almost every website is using tracking scripts.

The next time, you implement a tracking script it would be great if you could rethink it and ask yourself if it is really worth it.

Private by Default

Feedbin has removed third-party iframes and JavaScript (oEmbed provides a nice alternative), as well as stripping out Google Analytics, and even web fonts that aren’t self-hosted. This is excellent!

The “Developer Experience” Bait-and-Switch | Infrequently Noted

JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control.

Damn, that’s a fine opening! And the rest of this post by Alex is pretty darn great too. He’s absolutely right in calling out the fetishisation of developer experience at the expense of user needs:

The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

I have a feeling that this will be a very bitter pill for many developers to swallow:

If one views the web as a way to address a fixed market of existing, wealthy web users, then it’s reasonable to bias towards richness and lower production costs. If, on the other hand, our primary challenge is in growing the web along with the growth of computing overall, the ability to reasonably access content bumps up in priority. If you believe the web’s future to be at risk due to the unusability of most web experiences for most users, then discussion of developer comfort that isn’t tied to demonstrable gains for marginalized users is at best misguided.

Oh,captain, my captain!

Tools that cost the poorest users to pay wealthy developers are bunk.

Chrome’s NOSCRIPT Intervention - TimKadlec.com

Testing time with Tim.

Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.

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).

Offline Content with Service Worker — Chris Ruppel

A step-by-step walkthrough of a really useful service worker pattern: allowing users to save articles for offline reading at the click of a button (kind of like adding the functionality of Instapaper or Pocket to your own site).