Tags: performance

190

sparkline

Intervening against document.write() | Web Updates - Google Developers

Chrome is going to refuse to parse document.write for users on a slow connection. On the one hand, I feel that Google intervening in this way is a bit icky, but I on the other hand, I totally support this move.

This keeps happening. Google announce a change (usually related to search) where I think “Ooh, that could be interpreted as an abuse of a monopoly position …but it’s for ver good reason so I’ll keep quiet.”

Anyway, this should serve as a good kick in the pants for bad actors (that’s you, advertisers) to update their scripts to be asynchronous.

Progressive Web Apps Simply Make Sense - Cloud Four

Progressive Web Apps versus native is the wrong question because every step on the path to a Progressive Web App makes sense on its own, irrespective of what a company does with their native apps.

Not all of your customers are going to have your app installed. For those who visit via the web, providing them with a better experience will make them happier and generate more revenue for your business.

It’s really that simple.

SpeedCurve | PWA Performance

Steve describes a script you can use on WebPageTest to simulate going offline so you can test how your progressive web app performs.

The scorpion express | Butterick’s Practical Typography

This is easily the most wrong-headed piece of writing I’ve read in a long time.

“But cus­tomers ben­e­fit from smaller file sizes too, be­cause that makes web pages faster.” Cer­tainly, that was true in 1996. And some web de­vel­op­ers per­sist with po­lit­i­cal ob­jec­tions. But with to­day’s faster con­nec­tions—even on mo­bile—op­ti­miz­ing for file size is less use­ful than ever.

I’ll leave it to you to see the logical flaws in every one of the arguments presented here by Matthew Buterick. Meanwhile I’m going to get off his lawn.

What, Exactly, Makes Something A Progressive Web App? | Infrequently Noted

Alex runs through the features that a progressive web app must have, should have, and would be nice to have.

In general, installability criteria are tightening. Today’s Good-To-Haves may become part of tomorrow’s baseline. The opposite is unlikely because at least one major browser has made a strong commitment to tightening up the rules for installability.

Right now, this is in the nice-to-have category:

Mobile-friendly, not mobile-only.

Personally, I’d put that in the must-have category, and not just for progressive web apps.

Anyway, read on for some advice on testing and tooling when it comes to evaluating progressive web apps.

How Google And Others Are Plotting The Revenge Of The Web App | Fast Company | Business + Innovation

It’s always, um …”interesting” when a mainstream publication covers a topic from the web’s bikeshed. In this case, it’s progressive web apps, and—apart from the sensationalist headline—it’s actually not that bad at all.

Webfonts on the Prairie · An A List Apart Article

A good ol’ polemic in favour of using web fonts. It’s a good read although I strongly disagree with this line of reasoning:

The average internet speed in the United States today is three times as fast as it was in 2011.

But that americentric view is redeemed later on:

The World Wide Web may be a creation of the West, but now, at long last, it needs to get ready for the rest.

I may not agree with all the points in this article, but I think we can all agree that if we’re going to use web fonts, we must use them responsibly …otherwise users are going to treat them as damage and route around them.

The Building Blocks Of Progressive Web Apps – Smashing Magazine

This is a really good overview of progressive web apps:

An ideal web app is a web page that has the best aspects of both the web and native apps. It should be fast and quick to interact with, fit the device’s viewport, remain usable offline and be able to have an icon on the home screen.

At the same time, it must not sacrifice the things that make the web great, such as the ability to link deep into the app and to use URLs to enable sharing of content. Like the web, it should work well across platforms and not focus solely on mobile. It should behave just as well on a desktop computer as in other form factors, lest we risk having another era of unresponsive m.example.com websites.

Writing Less Damn Code | HeydonWorks

I’m in complete agreement with Heydon here:

But it turns out the only surefire way to make performant Web Stuff is also to just write less. Minify? Okay. Compress? Well, yeah. Cache? Sounds technical. Flat out refuse to code something or include someone else’s code in the first place? Now you’re talking.

Just like the “mobile first” mindset, if you demand that everything must justify its existence, you end up with a better experience for everyone:

My favorite thing about aiming to have less stuff is this: you finish up with only the stuff you really need — only the stuff your user actually wants. Massive hero image of some dude drinking a latte? Lose it. Social media buttons which pull in a bunch of third-party code while simultaneously wrecking your page design? Give them the boot. That JavaScript thingy that hijacks the user’s right mouse button to reveal a custom modal? Ice moon prison.

10K Apart

The 10K competition—spiritual successor to Stewart Butterfield’s 5K.org—is back. This time there’s no escape clause with web fonts or jQuery. You can lazy-load in more content after the initial 10K payload …but whatever you’re building needs to be usable in that first 10K.

Give it a go. There’s nothing like having a constraint to really get the creative juices flowing.

gmetais/sw-delta: An incremental cache for the web

Here’s an interesting use of service workers: figure out the difference (the delta) between the currently-cached version of a file, and the version on the network, and then grab only the bits that have changed. It requires some configuration on the server side (to send back the diff) but it’s an interesting approach that could be worth keeping an eye on.

Official Google Webmaster Central Blog: AMP your content - A Preview of AMP’ed results in Search

Google’s search results now include AMP pages in the regular list of results (not just in a carousel). They’re marked with a little grey lightning bolt next to the word AMP.

The experience of opening of those results is certainly fast, but feels a little weird—like you haven’t really gone to the website yet, but instead that you’re still tethered to the search results page.

Clicking on a link within an AMP spawns a new window, which reinforces the idea of the web as something separate to AMP (much as they still like to claim that AMP is “a subset of HTML”—at this point, it really, really isn’t).

Hidden Expectations - daverupert.com

Over the years I’ve come to realize that most difficult part of making websites isn’t the code, it’s the “hidden expectations”, the unseen aspects I didn’t know were my responsibility when I started: Accessibility, Security, Performance, and Empathy.

A Comprehensive Guide to Font Loading Strategies—zachleat.com

A terrific rundown of all your options when it comes to web font loading.

EmberCamp London Keynote 2016 // Speaker Deck

I really, really like what Ember is aiming for here:

First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.

That’s how you get the holy grail of resilience and performance:

Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.

I sincerely hope other frameworks are paying attention to this layered approach.

Oh, and I also like this observation:

There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.

CSS Containment Module Level 3

A way of declaring the scope of an element’s layout and paint styles, which browsers can then use as a hint to optimise performance. It’s already shipping in Chrome and Opera.

Building Web Applications that Work Everywhere

The second book in Adam Scott’s series on ethical web development is a nice quick read, covering URL design, Service Workers, and performance.

Things to Know (and Potential Dangers) with Third-Party Scripts | CSS-Tricks

Third-party scripts can provide powerful functionality, but they also bring risks to privacy, security, performance, and page behavior.

Making bad ads sad. Rad! - O’Reilly Media

A great talk from Bruce on the digital self-defence that ad-blockers provide. I think it’s great that Opera are building ad-blocking straight into the browser.

Progressively less progressive | Andrew Betts

I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.

More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.

However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.

turbolinks/turbolinks: Turbolinks makes navigating your web application faster

I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:

Turbolinks intercepts all clicks on a href links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

During rendering, Turbolinks replaces the current body element outright and merges the contents of the head element. The JavaScript window and document objects, and the HTML html element, persist from one rendering to the next.

Here’s the mustard it’s cutting:

It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.

This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.

A faster FT.com – Engine Room

A data-driven look at impact of performance:

The data suggests, both in terms of user experience and financial impact, that there are clear and highly valued benefits in making the site even faster.

A debugging thought process

Remy walks us through his performance debugging routine …and now Una must write him a song.

RAFP: a proposal for performance measurements through requestAnimationFrame - QuirksBlog

Here’s an interesting proposal from ppk: use requestAnimationFrame to gauge how performant a browser in behaving and then enhance accordingly.

Webfonts

I love good typography but I have to agree with the sentiment expressed here.

System fonts can be beautiful. Webfonts are not a requirement for great typography.

Progressive web apps: the long game

Remy sums up the psychological end goal of progressive apps (HTTPS + Service Worker + manifest JSON file) prompting an add to home screen action:

This high bar of entry will create a new mental model for our users.

If I add this app to my home screen, it will work when I open it.

It’s a shame that this charge to turbo-boast the perception of the web on mobile is a bit one-sided: I would love to see Apple follow Google’s lead here. But if Android succeed in their goal, then I think iOS will have to follow suit just to compete.

Managing Mobile Performance Optimization – Smashing Magazine

Some solid sensible advice on optimising performance.

Reasons to Use Ad-Blockers – Coyote Tracks

If you think people using ad blockers are just anti-ad or want to freeload on publishers, you’re completely missing the point. The online advertising industry has been abusing users for 20 years now, and we’re sick of it.

Service Workers: Save your User’s Data using the Save-Data Header | Dean Hume

I hadn’t heard of the save-data header. This article shows how you can use a Service Worker to sniff for it and serve up smaller assets, but I’m guessing you could also sniff for it from the server.

Performance is a feature. Why performance is an opportunity for online businesses.

The problem is that performance is a feature that is not on anyone’s product roadmap.

For whatever reason, the fact that it correlates directly to bounce rate, time on site, pages-per-visit etc. has not struck home with many product owners.

Most websites, certainly in the publishing industry where I have worked for a good part of my career, see those metrics as core KPIs. So you would think that anything that improved them would get prioritised. But no.

Preload: What Is It Good For? – Smashing Magazine

A comprehensive overview of rel="preload" which looks very useful indeed …I just wish it wasn’t (like “nofollow”) a nonsensical value for the rel attribute: a resource can’t have a relationship of “preload” to the linking document.

Performance Budget Builder

A nifty tool from Brad to help calculate and allocate performance budgets. Click around and edit the numbers.

RWD Interview with Jeremy Keith and Trent Walton

Myself and Trent answer some questions on responsive design for Justin’s excellent newsletter.

The Problem with Progressive Enhancement by Alex Lande

I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.

Specifically:

  1. Performance—”Progressively enhanced behaviors like using links that point to real URLs, or server-side form submission handling, allow users to perform important actions before JavaScript loads.”
  2. Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
  3. Business, Business, Business.

The Website Obesity Crisis

As promised, Maciej has posted the transcript of his excellent Web Directions talk on performance.

So, so good.

Building the UX London website by Charlotte Jackson

Charlotte talks through some of the techniques she used when she was building the site for this year’s UX London, with a particular emphasis on improving perceived performance.

More Responsive Tapping on iOS | WebKit

This solution to the mobile tap delay by the WebKit team sounds like what I was hoping for:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

It would be nice to know whether this has been discussed with other browser makers or if it’s another proprietary addition.

Maciej Ceglowski - The Website Obesity Crisis on Vimeo

A superb talk on performance, advertising, and the future of the web. No doubt a transcript will appear in due time on Maciej’s site and when it does, I will enjoy it all over again.

Trust me: you’ll want to watch this.

Smaller, Faster Websites - - Bocoup

The transcript of a great talk by Wilto, focusing on responsive images, inlining critical CSS, and webfont loading.

When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web app. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”

We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job.

CSS Font Rendering Controls Module Level 1

This is already starting to land in browsers, which makes me very happy—the ability to specify how you want fonts to load/swap without needing a clever bit of JavaScript.

briangonzalez/fontprep

The missing font generator for Mac OS X.

Very handy for subsetting fonts for the web. It doesn’t (yet) export WOFF2 unfortunately.

The “Blur Up” Technique for Loading Background Images | CSS-Tricks

Quite a few moving parts in this technique from Emil, but it’s very clever.

Performance Calendar » Reducing Single Point of Failure using Service Workers

This is a nifty use of Service Workers—using a cache to mitigate unresponsive Content Delivery Networks.

The stuff in here about Promise.race is particularly useful for “lie-fi” scenarios: instead of thinking about the network connection in a binary way (either it’s available or it isn’t), considering the scenario of a crappy network connection seems more realistic.

Troubleshooting rendering performance issues - YouTube

Harry packs a lot of great tips and tricks into one short video about performance troubleshooting. It’s also a great lesson in unlocking some handy features in Chrome’s developer tools.

Great stuff!

A look at detecting, pinpointing, measuring, and fixing rendering performance issues.

I Turned Off JavaScript for a Whole Week and It Was Glorious | WIRED

When someone’s web browsing experience can be so drastically improved by simply switching off JavaScript, you know it’s time for an intervention with web developers.

This is our fault. Client-side JavaScript gave us enormous power and we abused that power.

Instant Loading Web Apps With An Application Shell Architecture | Web Updates - Google Developers

Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.

Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…

Yay!

…but this is only one of many options.

Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.

Google+ | Google Web Showcase - Google Developers

Paul gives the lowdown on the Google+ responsive relaunch. They set themselves this performance budget:

  • 60K of HTML,
  • 60K of CSS,
  • 60K of JavaScript,
  • 60 frames per second animations, and
  • 0.6 seconds latency.

And this bit is crucial:

One of our major rules was that all our pages needed to be both server-side and client-side rendered. With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page.

Aerotwist - The Cost of Frameworks

Here’s Paul’s write-up of his excellent talk at FF Conf.

Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).

As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.

You should use [insert library/framework], it’s the bestestest! / Paul Lewis - YouTube

This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.

Best viewed with - Velocity Amsterdam 2015 // Speaker Deck

Are we doomed to see history repeat itself? With the amount of client-side MVC frameworks and the upcoming implementation of the ES6 syntax, will we soon be seeing a repeat of the “browser wars.” Will more websites only work in a select number of browsers with the capabilities to run their code?

The Advertising Bubble (Idle Words)

The prognosis for publishers is grim. Repent! Find a way out of the adtech racket before it collapses around you. Ditch your tracking, show dumb ads that you sell directly (not through a thicket of intermediaries), and beg your readers for mercy. Respect their privacy, bandwidth, and intelligence, flatter their vanity, and maybe they’ll subscribe to something.

Delivering Responsibly

The full transcript of Scott’s excellent presentation on performance and progressive enhancement.

The State of JavaScript on Android in 2015 is… poor - Discourse Meta

There’s something quite Kafkaesque about reading through the comments on Jeff Atwood’s request for an alternative to Ember.js …for rendering some text on a screen.

Every now and then someone pipes up with “server-rendered HTML?”, there’s a pause, and then a response of “naahhhhh.”

Surreal.

Accelerated Mobile Pages - I’ve Got More Questions than Answers by Andy Davies

Andy examines Google’s AMP project from a performance perspective and is left puzzled by its reliance on JavaScript and custom elements for rendering media.

But he shares my hope that AMP could serve as a demo of what the web could be if we developers had the will and political clout to see it through:

I wonder if what AMP really does is remind us how we’ve failed to build a performant web… we know how to, but all too often we just choose not to (or lose the argument) and fill our sites with cruft that kills performance, and with it our visitors’ experience.

Performance Budget Calculator

A handy little for calculating your performance budget based on how long you want your page to take to load on a particular connection.

Static AMP page

Maciej has created a version the AMP Project homepage that’s faster, more performant, and more …um …straight-talkin’.

Responsive News — AMP and Responsive Web Design

Tom’s thoughts on what AMP means for developers and publishers. He was initially sceptical but now he’s cautiously optimistic. Like me, he’s hoping that AMP can force the hand of those third-party advertisers to get their act together.

Publisher’s development teams are very capable of creating fast experiences for mobile users, but they don’t have the clout to coordinate all the additional cruft that is added to the page. However, if all the different publishers dev team’s got together and put their weight behind a single implementation, then we can force third parties to change their habits.

Responsive Field Day

All the videos from the excellent Responsive Field Day are now available. Even better, the audio is also available for your huffduffing pleasure!

All the presentations and panels were great. Sophie Shepherd’s terrific talk has really stuck with me.

Rise of the meta-platforms and the new ‘web browser’ - Tales of a Developer Advocate

Paul compares publishing on the web to publish on proprietary platforms, and concludes that things aren’t looking great right now.

Performance is the number one selling point for each of these new content platforms.

Miranj: Collateral Damage

Websites should not come with minimum software requirements.

Performance update #2: Electric Boogaloo | Vox Product Blog

It’s really great to see the performance improvements being made by the Vox team. This is the one that I think will make the most difference:

Our Revenue Team is increasing focus on the impact our advertising has on user experience and overall performance. One of their biggest initiatives has been to change the way ads load from synchronous to asynchronous, which has been underway for several months and is nearing deployment.

The ethics of modern web ad-blocking – Marco.org

Yes! Yes! YES!

Marco makes the same comparison I did between the dark days of pop-up windows and the current abysmal state of bloated ads and tracking on today’s web.

This won’t be a clean, easy transition. Blocking pop-ups was much more incisive: it was easy for legitimate publishers to avoid one narrowly-useful Javascript function to open new windows. But it’s completely reasonable for today’s web readers to be so fed up that they disable all ads, or even all Javascript. Web developers and standards bodies couldn’t be more out of touch with this issue, racing ahead to give browsers and Javascript even more capabilities without adequately addressing the fundamental problems that will drive many people to disable huge chunks of their browser’s functionality.

Amen!

I have one more thing to add to this list…

But publishers, advertisers, and browser vendors are all partly responsible for the situation we’re all in.

…developers. Somebody put those harm-causing script elements on those pages. Like I said: “What will you be apologising for in decades to come?”

In a few years, after the dust has settled, we’re all going to look back at today’s web’s excesses and abuses as an almost unbelievable embarrassment.

Designing for Performance by Lara Callender Hogan

Lara’s fantastic book is now available online in HTML for free. Have a read and then order a copy of the print book for your library.

Publishing Versus Performance: Our Struggle for the Soul of the Web by Jeffrey Zeldman

Jeffrey weighs on the post I wrote about The Verge. I still feel like there’s a false dichotomy being presented here though: either performance or advertising. But advertising can be performant too. There’s a competitive advantage to be had there.

Efficient Web Type, c. 1556

A long zoom and then a deep dive into web typography.

Declaring performance bankruptcy | Vox Product Blog

It’s really good to see that Vox are taking measures to fix their atrocious performance problems. The Verge in particular is a case study in how not to serve up text and images on the web. There have been times in the past when I’ve wanted to link to an article there but then thought “I can’t in good conscience put a fellow human through that.”

The W3C Mobile Checker

A new handy little performance testing tool from the W3C along the lines of Page Speed Insights.

How we built the new gocardless.com — GoCardless Blog

A classic example of the holy grail of web performance and robustness—start with regular HTML sent from the server, enhance once it’s in the browser …if the browser is capable of it. In this case, it’s using JavaScript (React) on both the server and the browser.

Supercharging page load (100 Days of Google Dev) - YouTube

A straight-faced Jake talks us through the step-by-step iterations for turning a JavaScript-required web thang into a progressively enhanced zippy experience, supercharged with Service Worker.

A few quick links and thoughts on big web problems – Baldur Bjarnason

The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.

To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.

Changing culture | susan jean robertson

Susan points out some uncomfortable truths. It’s all very well for us to try and create a culture of performance amongst designers and developers, but it will all be nought if we could change the minds of people higher up the chain …who currently just don’t care.

I think she’s spot on when she points to this possible solution:

I think what I’m asking is, who will be the game changer in this conversation? Who will be the large, bulky site that will work towards performance and make it happen and then we will all point to them and say, see they did it. It seems to me that that is what it takes. Much like we pointed to ESPN and being able to use CSS for layout or The Boston Globe and being able to do responsive at a large scale, who will we point to for the performance overhaul?

The web is fast by default, let’s keep it fast | hiddedevries.nl

Apart from the best practices that can often be automated, there are many human decisions that have impact on page speed. A way to make page speed part of the conversation and optimising it part of a website’s requirement, is to set a performance budget.

Making a difference with performance by Jaime Caballero

This is a great blow-by-blow account of making an agency website perform better.

I love the side-by-side comparisons with other agencies, including Clearleft—the gauntlet has been thrown down!

Monica at Mozilla: Tracking Protection for Firefox at Web 2.0 Security and Privacy 2015

I believe that Mozilla can make progress in privacy, but leadership needs to recognize that current advertising practices that enable “free” content are in direct conflict with security, privacy, stability, and performance concerns — and that Firefox is first and foremost a user-agent, not an industry-agent.

Instant Web · An A List Apart Column

More thoughts on the lack of a performance culture, prompted by the existence of Facebook Instant:

In my experience, the biggest barrier to a high-performance web is this: the means of production are far removed from the means of delivery. It’s hard to feel the performance impact of your decisions when you’re sitting on a T3 line in front of a 30 inch monitor. And even if you test on real devices (as you should), you’re probably doing it on a fast wifi network, not a spotty 3G connection. For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast.

15 Years Ago in ALA: Much Ado About 5K · An A List Apart Blog Post

Zeldman looks back at Stewart Butterfield’s brilliant 5K contest. We need more of that kind of thinking today:

As one group of web makers embraces performance budgets and the eternal principles of progressive enhancement, while another (the majority) worships at the altar of bigger, fatter, slower, the 5K contest reminds us that a byte saved is a follower earned.

The Many Faces of The Web

Instead of coming up with all these new tools and JavaScript frameworks, shouldn’t we try to emphasize the importance of learning the underlying fundamentals of the web? Teach those who are just stepping to this medium and starting their careers. By not making our stack more and more complex, but by telling about the best practices that should guide our work and the importance of basic things.

Killer page load performance – Async

This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).

The Path to Performance

A new podcast for your huffduffing pleasure. It’s all about performance and it’s hosted by Katie and Tim.

What Does My Site Cost?

A terrific little tool from Tim that puts performance into perspective by measuring how much money users are spending just to view your website on a mobile device.

The Path to Performance // Speaker Deck

The slides from Katie’s recent talk.

Performance is a rising requirement for building successful websites, but successful performance begins far earlier than development. So how do you get your entire team excited by it, specifically aesthetic-heavy designers?

localFont - A localStorage solution for web font loading

A quick drag’n’drop way to base 64 encode your web fonts so you can stick ‘em in local storage.

Google’s experimental new “slow” label could revolutionize how we tackle web performance - Web Performance Today

It looks like Google is going to start explicitly labelling slow sites as such in their search results (much like they recently started explicitly labelling mobile-friendly sites). So far it’s limited to Google’s own properties but it could be expanded.

Personally, I think this is a fair move. If the speed of a site were used to rank sites differently, I think that might be going too far. But giving the user advanced knowledge and leaving the final decision up to them …that feels good.

You’re Missing the Point of Server-Side Rendered JavaScript Apps : Tom Dale

Tom doesn’t mention the phrase “progressive enhancement” once, but that’s okay—his post is still about progressive enhancement.

FastBoot is coming to Ember. That means server-side rendering. And that means progressive enhancement will become a possibility for Ember apps. Exciting!

Responsible Social Share Links — Jonathan Suh

If you insist on having “social” sharing buttons, here’s a way to avoid bloating your page unnecessarily.

But you might want to reconsider whether you need them at all.

Client-side MVC’s major bug - TimKadlec.com

I’ve said it before: if your client-side MVC framework does not support server-side rendering, that is a bug. It cripples performance.

Flash of Faux Text—still more on Font Loading—zachleat.com

Smart thinking on optimising the perceived performance of loading web fonts: if you prioritise the most widely-used weight and style (usually the regular roman), and load other weights and styles subsequently, then it appears as though the font is ready sooner.

How we use web fonts responsibly, or, avoiding a @font-face-palm by Filament Group

Smart thinking here on the eternal dilemma with loading web fonts. Filament Group have thought about how the initial experience of the first page load could be quite different to subsequent page loads.

HTTP/2.0 - The IETF is Phoning It In - ACM Queue

There are some good points here comparing HTTP2 and SPDY, but I’m mostly linking to this because of the three wonderful opening paragraphs:

A very long time ago —in 1989 —Ronald Reagan was president, albeit only for the final 19½ days of his term. And before 1989 was over Taylor Swift had been born, and Andrei Sakharov and Samuel Beckett had died.

In the long run, the most memorable event of 1989 will probably be that Tim Berners-Lee hacked up the HTTP protocol and named the result the “World Wide Web.” (One remarkable property of this name is that the abbreviation “WWW” has twice as many syllables and takes longer to pronounce.)

Tim’s HTTP protocol ran on 10Mbit/s, Ethernet, and coax cables, and his computer was a NeXT Cube with a 25-MHz clock frequency. Twenty-six years later, my laptop CPU is a hundred times faster and has a thousand times as much RAM as Tim’s machine had, but the HTTP protocol is still the same.

Researching the Performance costs of JavaScript MVC Frameworks

The Filament Group run the numbers on how long it takes browsers to parse the JavaScript of popular MVC frameworks: Backbone, Angular, and Ember. The results—especially on mobile browsers—are not encouraging.

Perf.Rocks

A collection of performance resources: articles, tools, talks, and books.

Performance Budget Metrics - TimKadlec.com

Some good practical advice from Tim on setting a performance budget.

Use rule-based metrics to make sure you haven’t overlooked simple optimizations.

Use quantity-based metrics as guides to help designers and developers make better decisions about what goes onto a page.

RWD BLOAT // Speaker Deck

Dave’s great slides from a presentation on performance and responsive design.

Official Google Webmaster Central Blog: Updating our technical Webmaster Guidelines

Google has updated its advice to people making websites, who might want to have those sites indexed by Google. There are two simple bits of advice: optimise for performance, and use progressive enhancement.

Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.

JS Parse and Execution Time - TimKadlec.com

Tim’s been running the numbers on how long it takes various browsers on various devices to parse JavaScript—in this case, jQuery. The time varies enormously depending on the device hardware.

A device agnostic approach to inlining CSS | Blog | Decade City

I very much agree with Orde’s framing here: I don’t think it makes much sense to talk about “above the fold” CSS …but it makes a lot of sense to talk about critical CSS.

And, yeah, it’s another example of progressive enhancement.

How we make RWD sites load fast as heck

Scott shares the code that Filament Group are using to determine which style declarations are critical (and can be inlined) and which are non-critical (and can be loaded asynchronously). It makes quite a difference in perceived performance.

By the way, I really, really like the terminology of “critical” and “non-critical” CSS, rather than “above the fold” and “below the fold” CSS.

RWD Bloat - daverupert.com

Dave wanted to figure out if having a responsive site necessarily meant taking a performance hit, so he ran the numbers on his own site. It turns out all of performance-related issues are not related to responsive design.

GitHub’s CSS · @mdo

Mark Otto talks through the state of Github’s CSS and the processes behind updating it. There’s a nice mix of pragmatism and best practices, together with a recognition that there’s always room for improvement.

Monday, 7 July 2014 – The Pastry Box Project

Words of wisdom from Scott on the clash of brand guidelines and the flexible nature of the web:

One thing I am pretty sure of though, is that having a fast, accessible, user-friendly site can reflect incredibly well on a company, and I’d love to see more guidelines and expectations that prioritize these aspects of a service as branding requirements in addition to the usual visual details.

Comparing two ways to load non-critical CSS

Scott’s trying to find out the best ways to load critical CSS first and non-critical CSS later. Good discussion ensues.

Section for peer-reviewed Custom Elements · Issue

Some sensible thoughts from Addy on how Web Components might be peer-reviewed.

Aerotwist - Web Components and the Three Unsexy Pillars

A healthy dose of scepticism about Web Components, looking at them through the lenses of accessibility, security, and performance.

I share some of this concern: Web Components might look like handy ready-made out-of-the-box solutions, but the truth is that web developers have to do much more of the hard graft that was traditionally left to the browser.

Spotlight – a pure JavaScript application for GOV.UK Performance | Technology at GDS

A nice tale of progressive enhancement from gov.uk, talking about how they made their analytics dashboards (which are public, by the way) using JavaScript on the server and on the client.

I believe this is what the kids are calling isomorphic JavaScript.

Device-Agnostic by Trent Walton

A terrific post from Trent, touching on all the important facets of building for the web: universality, progressive enhancement, performance …great stuff!

Aerotwist - My Performance Audit Workflow

Excellent tips and tools from Google’s Paul Lewis on performance testing.

Notes on a responsive Guardian redesign – Lozworld™

A great write-up of the design process behind The Guardian’s responsive site. It’s really gratifying to see UX designers talking about performance.

Fast Enough - TimKadlec.com

Some sensible thinking from Tim on measuring performance gains.

“Now with Responsive!,” an article by Dan Mall

Dan gives some insight into what it took to make his personal site responsive. Stay tuned: there’ll be more of this.

Issue 18850005: Disable double tap zoom on mobile sites, to remove 300ms click delay - Code Review

Well, this is interesting: it looks like Chrome might stop waiting 300ms for potential double-tap-to-zoom events if the site is using a meta viewport declaration that sets the width to device-width.

Progressive enhancement is still important by Jake Archibald

Another great post on using progressive enhancement for JavaScript, this time by Jake. He does a great job of explaining the performance bottleneck that is created when you start doing everything on the client side.

Web Fonts and the Critical Path - Ian Feather

The battle between web fonts and performance. Ian Feather outlines some possible solutions, but of course, as always, the answer is “it depends”.

Request Quest

A terrific quiz about browser performance from Jake. I had the pleasure of watching him present this in a bar in Amsterdam—he was like a circus carny hoodwinking the assembled geeks.

I guarantee you won’t get all of this right, and that’s a good thing: you’ll learn something. If you do get them all right, either you are Jake or you are very, very sad.

Deep dive into the murky waters of script loading

Jake casts a scrutinising eye over the way that browsers load and parse scripts …and looks at what we can do about it.

Sensible jumps in responsive image file sizes

Some good thinking from Jason here. In a roundabout way, he’s saying that when it comes to responsive images—as with just about every other aspect of web development—the answer is …it depends.

joshje/svg-for-web · GitHub

If, like me, you’ve been using the “export to SVG” plugin for Fireworks and then opening up the resultant file to trim it down, Josh has got you covered: here’s a version of “export to SVG” that will result in much slimmer files.

I’m done with the web by Randy Luecke

I find it hard to agree with any part of this. To me, it shows a deep misunderstanding of the web—treating the web as just another platform, without understanding what makes it so special.

I think I may have found my polar opposite.

The hilarious obsession with file size is the start of my frustrations with the web community.

How to lose weight (in the browser)

A handy one-stop-shop for tips on improving front-end performance.

A List Apart Issue № 371

This issue of A List Apart is a great double-whammy. Lara Swanson has a ton of practical tips for front-end performance enhancements, and Brian dives deep into making your own icon fonts.

For discussion: viewport and font-size data in client hints

The “client hints” proposal looks really interesting: a way for user-agents to send data to the server without requiring the server to have a library of user-agent strings. But Scott has a few concerns about some of the details.

Anatomy of a responsive page load

The slides from Andy’s excellent pragmatic talk on performance and aggressive enhancement at the Responsive Day Out.

Responsive design – have we come full circle?

Everything old is new again. Ross noticed that many of the themes recurring at the Responsive Day Out hark back to best practices from over a decade ago: progressive enhancement, performance, good ol’ information architecture…

The Vanilla Web Diet by Christian Heilman

I like the sound of the book that Chris is writing for Smashing Magazine. It sounds like a very future-friendly approach to front-end development.

Test your app under slow network speeds

Some handy tips for simulating slow network speeds on your machine.

Setting a performance budget by Tim Kadlec

Tim talks about the very useful technique of setting a page-weight limit; something that Mark wrote about on the Clearleft blog recently.

On layout and web performance by Kelly Norton

This is handy: a look at which DOM properties and methods cause layout thrashing (reflows).

Performance as design by Brad Frost

Amen, Brad, Amen.

It’s time for us to treat performance as an essential design feature, not just as a technical best practice.

Speed up your site using prefetching by Jon Fox

More details on DNS prefetching, page prefetching and, controversial, page pre-rendering.

Front-end performance for web designers and front-end developers by Harry Roberts

A really good introduction to front-end performance techniques. Most of this was already on my radar, but I still picked up a handy tip or two (particularly about DNS prefetching).

At this stage it should go without saying that you should be keeping up with this kind of thing: performance is really, really, really important.

Implementing off-canvas navigation for a responsive website by David Bushell

This off-canvas demo is a great practical example of progressive enhancement from David. It’s also a lesson in why over-reliance on jQuery can sometimes be problematic.

Page Weight Matters | Chris Zacharias

An excellent tale of performance optimisation …complete with a coda on looking behind the numbers when it comes to analytics data.

Deploying New Image Formats on the Web - igvita.com

A well-reasoned argument for tackling image optimisation on the server, using content-type negotiation.

The Vanilla Web Diet | Smashing Coding

I wholeheartedly agree with Christian’s diagnosis of the average web page: it’s overweight to the point of obesity. Fortunately Dr. Heilmann has some remedies.

Trimming the Fat — Paul Robert Lloyd

A great in-depth description by Paul of how he optimised his site. More of this please!

Retina revolution

You’ve probably seen this already, but it’s really worth bearing in mind: when you’re scaling up JPGs for retina display you can safely reduce the image quality by quite a lot—to the point of getting the exact same file size as a higher quality image that’s half the size.

A List Apart: Articles: Mo’ Pixels Mo’ Problems

The kickass articles just keep on comin’. This one from Dave is a great overview of options for dealing with images in responsive designs.

JPEGmini - Your Photos on a Diet!

This looks like a really handy tool for reducing the file size of JPEGs without any perceptible loss of quality (in much the same way that ImageOptim works for PNGs)—available as a Mac app or an installable web service.

Latency: The New Web Performance Bottleneck - igvita.com

This is just wonderful! It combines almost all of my recent obsessions into one unified post: website performance (particularly on mobile) and the locations of undersea cables. The interactive map is the icing on the cake.

bandwidth (tecznotes)

Mike compares the bandwidth usage of the sites he most frequently visits. The results are grim.

The worst sins of the Flash years are coming back with a vengeance, in the form of CSS Frameworks and the magic dollar sign. There has seriously got to be a better way to do this.

filamentgroup/Southstreet

This is excellent! Scott, Wilto, and the gang at Filament Group have released the tools they use to help them craft performant responsive sites. Lots of excellent resources for conditional loading here.

How We Improved Page Speed By Cleaning CSS, HTML and Images | Dyn Blog

Some good practical advice on improving performance. This should all be familiar to you, but it’s always worth repeating.

Twitter Engineering: Improving performance on twitter.com

Well, well, well. It turns out that building your entire application, content’n’all, in JavaScript isn’t so good for performance.

Sweep the Sleaze | Information Architects

Some sensible advice from Oliver Reichenstein. Cluttering your social media icons isn’t helping and may actively be hindering your audience.

» The real conflict behind picture and @srcset (Cloud Four Blog)

Jason outlines the real challenge to every proposed solution for responsive images: they just don’t jibe with the way that browsers (quite rightly) pre-fetch images.

LukeW | Data Monday: E-commerce Performance

Time is money …especially when it comes to performance on the web.

HTTP Compression use by Alexa Top 1000 | Zoompf

An in-depth analysis (graphs! data!) of how popular sites are using—or not using—compression.

Highly optimized images for the web in 3 steps | pasz.nl/blog

Some practical advice for optimising your images on the web.

The state of responsive images | Feature | .net magazine

Wilto gives a thorough explanation of the state of things with responsive images, particularly the work being done at the Responsive Images Community Group at the W3C.

Mobile Battery Performance

This is my short explanation of Remy’s explanation of a BBC news article which is an explanation of an academic paper about battery performance of mobile devices when accessing websites.

Modern Web Development Part 1 – The Webkit Inspector

This is a very in-depth look at how to become a power user of the Web Inspector in Webkit browsers. I’m sitting down with a nice cup of tea to go through all of this.

10 questions about web performance – Jeremy Keith at Clearleft

I had a chat with the guys from Pingdom about performance’n’stuff. If I sound incoherent, that’s because this is a direct transcription of a Skype call, where, like, apparently I don’t, y’know, talk in complete sentences and yeah.

An Ajax-Include Pattern for Modular Content | Filament Group, Inc., Boston, MA

Scott walks through the code and thinking behind the conditional loading pattern on The Boston Globe site. This is such a useful and valuable pattern!

Pingdom Tools

A handy performance testing tool from Pingdom, similar to Google’s offering.

First thing you should do to optimize your desktop site for mobile « Cloud Four

Jason reiterates Bruce’s rallying cry: Performance First!

If you could only do one thing to prepare your desktop site for mobile and had to choose between employing media queries to make it look good on a mobile device or optimizing the site for performance, you would be better served by making the desktop site blazingly fast.

Bruce Lawson’s personal site  : What Users Want from Mobile, and what we can re-learn from them

Bruce hammers home the importance of speed and performance on mobile (and frankly, everywhere).

So perhaps some of the time and effort put into media queries, viewports, avoiding scrolling, line length would actually be better employed reducing HTTP requests and optimising so that websites are perceived to render faster.

ImageAlpha — lossy compression for 24-bit PNG images

From Kornel, the genius who gave us ImageOptim, comes another Mac desktop tool for optimising PNGs, this time converting 24-bit PNG to 8-bit with full alpha channel.

nathanford/pngy - GitHub

A script that attempts to detect connection speed (by requesting a test file three times in a row) in order to determine whether hi-res images should be requested or not.

What We Don’t Know // Speaker Deck

The slides from Chris’s presentation on the known unknowns of the web.

Sirens | Aaron Mentele

Some very interesting results from testing background image downloads contained within media queries or overridden with media queries: it turns out that, in iOS at least, the browser is getting smarter and smarter.

On designing content-out (a response to Zeldman and others) | Stephanie Rieger

Stephanie details all the things we have to know about when designing for today’s broad range of devices: performance, capabilities, form factor, pixel density, and network latency.

These are all good points but I worry that if we just concentrate on the current device landscape, our processes won’t adapt to the future.

REDbot: <>

Oh, this is very handy indeed: a quick lint tool for HTTP so you can see what kind of headers are being sent. There’s a bookmarklet in the footer too.

Polyfilling The HTML5 Gaps With JavaScript

An in-depth look at browser polyfills: what they are, how they work, and how you can make your own.

Post Web site loads too slowly - The Washington Post

Performance matters. Here, the Washington Post compares its own weak performance (hampered by ads and tracking shite) to the optimised experience of porn sites.

Stubbornella » Blog Archive » Don’t Style Headings Using HTML5 Sections

Nicole provides a step-by-step explanation of why it will probably benefit you to add classes to your headings to ensure consistent styling without writing overly-verbose CSS.

Jake Archibald - Font-Face - Good vs Legal on Vimeo

Jake’s talk at DIBI earlier this year was absolutely fantastic. It features a rape reference, a story about pissing, and a Human Centipede metaphor.

It’s also very, very informative. Watch this.

Appcache Facts

A handy one-page cheatsheet for using HTML5’s appcache manifest file for offline storage.

mySociety » Blog Archive » Mobile operators altering (and breaking) web content

In an attempt to “optimise” performance, T-Mobile and Orange are actually breaking jQuery.

Page Speed Service Home

Performance shit just got real.

You can now sign up with Google to have your site pass every request through them and get your documents served up optimised.

Responsive web design from the future — Warpspire

I really like the thinking that’s gone into the design of Github, as shown in this presentation. It’s not really about responsive design as we commonly know it, but boy, is it a great deep dive into the importance of URLs and performance.

Don’t use IDs in CSS selectors? ❧ Oli.jp (@boblet)

I agree with Oli’s conclusion:

Save IDs for fragment identifiers or JavaScript hooks.

Book of Speed

An online book about website performance by Stoyan Steganov, released into the public domain. Excellent!

CSS Lint

Nicholas and Nicole have unveiled the CSS companion to JS Lint. And yes, it will your hurt your feelings.

JoshEmerson.co.uk · Blog · Base64 and the tiling background

Josh explains the pros and cons of embedding background images in your CSS using base 64 encoding.

Google Analytics Blog: Measure Page Load Time with Site Speed Analytics Report

Great news! Google Analytics now tracks page load times.

Page Speed Online

A supremely useful tool from Google for measuring performance.

HTTP Archive

This is wonderful stuff: a long-term project to track the performance of high-traffic sites over time: oodles of lovely data and some quite shocking stats.

filamentgroup/Responsive-Images - GitHub

Some very smart ideas here for responsively enhancing image requests.

Mobile Web Application Best Practices

This W3C document is done and dusted: proposed recommendation. Every one of the guidelines for optimising for mobile also holds true for "desktop" sites.

HTML Resource Packages

An interesting performance proposal from mozilla that will degrade nicely in legacy browsers.

10K Apart | Inspire the web with just 10K.

I'll be sitting in judgement on the entries to this neat competition which harks back to the good ol' days of 5k.org.

Web fonts test

Test cases for font-linking.

High Performance Web Sites :: @font-face and performance

Steve Souders does the research and reveals the sad truth about the effect font-linking has on performance.

Make Photoshop Faster

Two little tips courtesy of Dan.

Let's make the web faster - Google Code

A whole heap of optimisation techniques from Google for faster CSS, JavaScript, markup and PHP.

Douglas Crockford: "Ajax Performance" on Yahoo! Video

An excellent overview of Ajax and optimisation.

Thirteen Simple Rules for Speeding Up Your Web Site

The justification behind YSlow. If you've heard Nate Koechley speak, some of this will be familiar to you. It's all solid advice as far as I can tell.

YSlow for Firebug

The YUI folks have released an add-on for Firebug that will analyse your pages and suggest ways of speeding it up.

U2's City of Blinding Lights

William Gibson gives a first-hand account of U2's redristribution of the future.