🧵 Two of my most- and first-used checks when doing a performance audit are surprisingly old school: 1) Validate HTML 2) Disable JS.
Validate HTML? Yep. We haven’t really cared about ‘valid HTML’ for valid HTML’s sake for about a decade, but certain errors can actually be pretty significant. What’s wrong with this picture? 
It’s this lil’ fella right here. <span> isn’t allowed in the <head>, so when the browser encounters the <span>, it assumes the <head> should have been closed already.
This is a feature. This is what allows us to omit certain closing tags like </p>, </li>, </tbody>, and—you guessed it!—</head>. The appearance of certain opening tags implies the closing of certain preceding ones.
The practical upshot of which is that non-<head> elements early-terminate the <head> tags, pushing all of your important <head> resources into the <body>. Oops!
Disable JavaScript? I think building sites for people who’ve turned JS off is an expensive waste of time: they’ve turned it off! Leave them to it. But! I do feel it’s vital that we can fail reasonably elegantly when JS fails (and it will).
I strongly hold @adactio and @jaffathecake’s respective (and paraphrased) opinions about JS: ‘How well does it fail?’ and ‘All your users are non-JS until your JS is downloaded and run’.
From a performance perspective, I don’t want to see your core content buried away in JS. JS is slower than HTML. If you need JS to display core content, you’re on the slow path. The quickest way for me to ascertain whether content is coming out of JS? Disable it!
Do I care that CNN doesn’t work with JS disabled? Not necessarily. But immediately I can see that their content is reliant on the successful download and execution of JS. This is always going to be slower than having it in the HTML—the first (and successful) response.
</🧵>
• • •
Missing some Tweet in this thread? You can try to
force a refresh
