Using Macros

Pellentesque habitant morbi tristique senectus et netus et malesuada @@ -103,7 +103,7 @@ The process will go a little like this: The majority of the work happens in the CSS. The first chunk isn’t really aything exciting: it’s just cosmetic styling and laying out our items. -``` +```scss /** * 1. Clearfix our filter context. */ @@ -143,7 +143,7 @@ aything exciting: it’s just cosmetic styling and laying out our items. Now things start to get a little more interesting: -``` +```scss .c-filter__target:not(:target) ~ .c-filter__item { opacity: 1; } @@ -165,7 +165,7 @@ actually started off as `display: block;` in my first version of this). The next bit of CSS looks quite similar: -``` +```scss .c-filter__target:target ~ .c-filter__item { opacity: 0.25; } @@ -184,7 +184,7 @@ specific DOM nodes: we can’t use a blanket rule. I’m using Sass to help me out here, and that looks like this: -``` +```scss @each $tag in html, css, accessibility, performance, vim { [id="tag:#{$tag}"]:target ~ [data-tag~="#{$tag}"] { @@ -199,7 +199,7 @@ I’m using Sass to help me out here, and that looks like this: Here we have a loop that contains every one of my tags, and goes through them all making selectors that look like this: -``` +```scss [id="tag:css"]:target ~ [data-tag~="css"] { ... } ``` @@ -224,7 +224,7 @@ So if we’re targeting the `css` anchor, please go ahead and find all elements tagged with `css` later in the DOM tree. Once you’ve found them, please turn them on: -``` +```scss opacity: 1; ``` @@ -241,7 +241,7 @@ certainly not insurmountable. Inside of the same Sass loop as before, I’m generating a new suite of selectors that each look like this: -``` +```scss [id="tag:css"]:target ~ .c-filter__links [href="#tag:css"] { ... } ``` @@ -280,7 +280,7 @@ anchors, they will always be positioned at the very top-left of the viewport. The practical upshot of this is that the anchors will always be exactly where the user has scrolled to, so the page didn’t actually have to jump anywhere. -``` +```scss .c-filter__target { position: fixed; } diff --git a/_posts/2016-10-19-continue-normalising-your-css.md b/_posts/2016-10-19-continue-normalising-your-css.md index 2464b2e3..3c548bb6 100644 --- a/_posts/2016-10-19-continue-normalising-your-css.md +++ b/_posts/2016-10-19-continue-normalising-your-css.md @@ -3,6 +3,7 @@ layout: post title: "Continue Normalising Your CSS" date: 2016-10-19 12:40:58 categories: Web Development +toc: false meta: "Why we should still be using Normalize.css" --- diff --git a/_posts/2016-11-28-nesting-your-bem.md b/_posts/2016-11-28-nesting-your-bem.md index 5631eb27..e9401719 100644 --- a/_posts/2016-11-28-nesting-your-bem.md +++ b/_posts/2016-11-28-nesting-your-bem.md @@ -3,14 +3,14 @@ layout: post title: "Nesting Your BEM?" date: 2016-11-28 12:50:39 categories: Web Development -meta: "A look at the possible benefits off nesting BEM, and mitigating the side effects" +meta: "A look at the possible benefits of nesting BEM, and mitigating the side effects" --- Let me please start this post by saying that this is **not a recommendation or new ‘best practice’**. This is me thinking out loud. I’m a huge fan and proponent of -[BEM](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/), +[BEM](/2013/01/mindbemding-getting-your-head-round-bem-syntax/), and have been for many years. It’s kinda funny looking, sure, but it provides me with a lot of things: @@ -63,7 +63,7 @@ because it * increases fragility (nesting means more chances for the selector to go wrong). In short, [keep your CSS selectors -short](http://csswizardry.com/2012/05/keep-your-css-selectors-short/). +short](/2012/05/keep-your-css-selectors-short/). But in the case of nesting BEM we see that nesting does in fact give us tangible benefits. How do we deal with the downsides? @@ -81,7 +81,7 @@ only selectors are IDs would have well managed specificity: the specificity would be universally high, but would at least all be equal and consistent. When we talk about well managed specificity, we’re talking about [Specificity -Graphs](http://csswizardry.com/2014/10/the-specificity-graph/) which are as flat +Graphs](/2014/10/the-specificity-graph/) which are as flat as possible. If we look at the following CSS for a series of components: diff --git a/_posts/2016-11-30-css-wizardry-newsletter.md b/_posts/2016-11-30-css-wizardry-newsletter.md index 2c130057..257c6325 100644 --- a/_posts/2016-11-30-css-wizardry-newsletter.md +++ b/_posts/2016-11-30-css-wizardry-newsletter.md @@ -30,7 +30,7 @@ within the remit of a Tweet or a blog post. This means more curated and exclusive content; it means more off-topic and obscure; it means more personable and direct. -Sign up +Sign up ### Exclusive Content @@ -95,4 +95,4 @@ touch](/contact/) with me to discuss options. Cool! Get yourself [signed up below](#mc_embed_signup) or directly on [the MailChimp -site](http://csswizardry.us14.list-manage2.com/subscribe?u=95f3f41085f5f957a07ba5efd&id=ba05b5418d). +site](https://csswizardry.us14.list-manage2.com/subscribe?u=95f3f41085f5f957a07ba5efd&id=ba05b5418d). diff --git a/_posts/2016-12-12-css-shorthand-syntax-considered-an-anti-pattern.md b/_posts/2016-12-12-css-shorthand-syntax-considered-an-anti-pattern.md index 9eca4786..be04b25c 100644 --- a/_posts/2016-12-12-css-shorthand-syntax-considered-an-anti-pattern.md +++ b/_posts/2016-12-12-css-shorthand-syntax-considered-an-anti-pattern.md @@ -3,6 +3,7 @@ layout: post title: "CSS Shorthand Syntax Considered an Anti-Pattern" date: 2016-12-12 14:11:38 categories: Web Development +toc: false meta: "Avoid using CSS’ shorthand syntax" --- @@ -18,25 +19,29 @@ intended to modify.** When we write something like: - .btn { - background: red; - } +```css +.btn { + background: red; +} +``` …we’re likely to get a red background colour applied to our button. But what we’re really saying is this: - .btn { - background-image: initial; - background-position-x: initial; - background-position-y: initial; - background-size: initial; - background-repeat-x: initial; - background-repeat-y: initial; - background-attachment: initial; - background-origin: initial; - background-clip: initial; - background-color: red; - } +```css +.btn { + background-image: initial; + background-position-x: initial; + background-position-y: initial; + background-size: initial; + background-repeat-x: initial; + background-repeat-y: initial; + background-attachment: initial; + background-origin: initial; + background-clip: initial; + background-color: red; +} +``` Simply by using the shorter syntax, we have implicitly decided that we want no image to start top-left, repeat x and y, to scroll with @@ -52,9 +57,11 @@ should be avoided. CSS is a lot harder to undo than it is to do. In this example, what we really wanted to say was this: - .btn { - background-color: red; - } +```css +.btn { + background-color: red; +} +``` Here we’ve done exactly what we needed to do, and absolutely nothing else. @@ -63,7 +70,7 @@ Here we’ve done exactly what we needed to do, and absolutely nothing else. One such example I encountered on a client project earlier this year looked a little like this: -``` +```css .base-class { background-position: 0 0; background-repeat: no-repeat; @@ -95,7 +102,7 @@ The `background` example is just one of many instances in which we shouldn’t b using shorthand. Another very common use-case is vertical centring using `margin: 0 auto;`: -``` +```css .wrapper { margin: 0 auto; } @@ -110,7 +117,7 @@ intentionally introduced elsewhere. If all you want to do is centre a `div`, then don’t mention anything to do with its top and bottom edges. Favour the longhand version: -``` +```css .wrapper { margin-right: auto; margin-left: auto; @@ -126,7 +133,7 @@ So far we’ve looked at the problem with inadvertently unsetting other properties, but there is a scenario in which shorthand would be okay. Take for example: -``` +```css .box { padding: 10px; } @@ -135,7 +142,7 @@ example: Here we aren’t inadvertently unsetting anything because we do want all four sides to carry `10px` padding. Here, shorthand makes complete sense. Also: -``` +```css .btn { padding: 12px 24px; } @@ -143,14 +150,14 @@ sides to carry `10px` padding. Here, shorthand makes complete sense. Also: …and: -``` +```css .foo { margin: 12px 17px 16px 10px; } ``` Here—although I’d question the use of [magic -numbers](http://csswizardry.com/2012/11/code-smells-in-css/#magic-numbers)—we +numbers](/2012/11/code-smells-in-css/#magic-numbers)—we are still explicitly setting all four sides, so, again, this use of shorthand would still be okay. diff --git a/_posts/2017-01-04-choosing-the-correct-average.md b/_posts/2017-01-04-choosing-the-correct-average.md index 09f80d86..99fc9771 100644 --- a/_posts/2017-01-04-choosing-the-correct-average.md +++ b/_posts/2017-01-04-choosing-the-correct-average.md @@ -8,7 +8,7 @@ meta: "A look at which average works best for representing certain types of data More and more frequently I’m finding myself presenting data to clients. Wether it’s through [code reviews or performance -audits](http://csswizardry.com/code-reviews/), taking a statistical look at code +audits](/code-reviews/), taking a statistical look at code is an important part of my job, and it needs presenting to my clients in a way that is representative and honest. This has led me more and more into looking at different averages, and knowing when to use the correct one for each scenario. @@ -69,7 +69,7 @@ have a different outcome altogether: Paying £55.50 each to subsidise Chad’s expensive taste isn’t quite so fair. I’ve mentioned issues with the mean before, in my previous [post about -Parker](http://csswizardry.com/2016/06/improving-your-css-with-parker/). +Parker](/2016/06/improving-your-css-with-parker/). Sometimes it’s nicer to know either a more representative single number, or to know that _most values are x_. @@ -145,7 +145,7 @@ then it is 93. However, if we were to make our own silos of data points, we can begin looking at finding a mode: instead of representing each data point individually, we put -in into a pre-defined bin, e.g. <=60s, >60s, <=90s, etc. Now our data isn’t +in into a pre-defined bin, e.g. ≤60s, >60s, ≤90s, etc. Now our data isn’t whatever-it-ends-up-being, it’s actually inside a category we’re already aware of. @@ -162,7 +162,7 @@ a lot of data; secondly, this still only tells me how each page performs, and doesn’t give me a very good overview of the site’s performance like we wanted.

Chart showing load times of various pages on a website. View full size/quality (15KB)

@@ -173,7 +173,7 @@ A histogram plots the frequency of a data point, not the data point itself. This allows us to very easily identify the mode:

Chart showing load times of various pages on a website. View full size/quality (9KB)

@@ -197,9 +197,9 @@ statistical outliers should not be represented by the mean, as results are easily skewed. If we want to get a general overview of what most things are looking like, the mode might be the one to go for. -* Mean is good for data with a very small range, actually not usually that +* **Mean** is good for data with a very small range, actually not usually that useful. Good for working out average score, or splitting the cost of a meal. -* Median is good for finding a representative value of a skewed data set. Good - for measuring open-ended data. -* Mode is good for a holistic overview; if you can represent the data in a +* **Median** is good for finding a representative value of a skewed data set. + Good for measuring open-ended data. +* **Mode** is good for a holistic overview; if you can represent the data in a histogram then it will give you the mode. diff --git a/_posts/2017-01-08-preparing-vim-for-apples-touch-bar.md b/_posts/2017-01-08-preparing-vim-for-apples-touch-bar.md index 5611f5fa..3539c794 100644 --- a/_posts/2017-01-08-preparing-vim-for-apples-touch-bar.md +++ b/_posts/2017-01-08-preparing-vim-for-apples-touch-bar.md @@ -35,7 +35,7 @@ How can we switch between modes without having an Escape key?[^1] ## Remap Other Keys For almost as long as I’ve been using Vim⁠—⁠which is [a long time -now](http://csswizardry.com/2014/06/vim-for-people-who-think-things-like-vim-are-weird-and-hard/)⁠—⁠I’ve +now](/2014/06/vim-for-people-who-think-things-like-vim-are-weird-and-hard/)⁠—⁠I’ve been using `jj` and `jk` to leave Insert mode. These mappings are on the [Home Row](https://en.wikipedia.org/wiki/Touch_typing#Home_row), so always easy to reach, and the letter pairs very rarely (if ever) occur in the English language. @@ -66,40 +66,52 @@ This only really helps us out if we’re in Normal mode though: if we’re in Vi mode it’s just going to move our selection up or down, and Command mode will literally write the characters out. What else can we do? -A lot of people also like to map Caps-Lock to ``, however that needs -to be done at OS level. I personally don’t like the idea of having a system-wide -keyboard change for the sake of just my text editor, but that’s just me. +### Using CapsLock + +A lot of people also like to map CapsLock to ``, however that needs to be +done at OS level with a number of different third-party tools. I personally +don’t like the idea of having a system-wide keyboard change for the sake of just +my text editor, but that’s just me. + +#### Update 2017-05-24 + +If you’re running macOS Sierra, you can now natively map CapsLock to ``: + +

Remap CapsLock to Escape in System Preferences View full size/quality (120KB).

+ ## Alternatives to `` -Where as `jj` and `jk` are remapped to _act_ like ``, it turns out that +Whereas `jj` and `jk` are remapped to _act_ like ``, it turns out that there are some native alternatives to `` that we can use across modes. As I mentioned, hitting `jj` and `jk` in Command mode will be interpreted literally, and in Visual mode they will navigate, so in these modes we can use -either `Ctrl+[` (or ` in Vim-speak) or `Ctrl+C` (or ` in Vim-speak). +either `Ctrl-[` (or ` in Vim-speak) or `Ctrl-C` (or ` in Vim-speak). The Vim help even says: > Note: If your `` key is hard to hit on your keyboard, train yourself to -> use `CTRL-[`. +> use `Ctrl-[`. -So, whenever you’re in any modes other than Insert, reach for `Ctrl-[` or -`Ctrl-C` instead of ``. `Ctrl-C` is probably going to be a little easier to +So, whenever you’re in any modes other than Insert, reach for `` or +`` instead of ``. `` is probably going to be a little easier to remember, because you probably recognise it as the cancel signal in from your shell, however there are some subtle differences between the two… ### What’s the Difference? -`Ctrl-[` acts almost universally identically to `Esc`, so there’s nothing real -of note there. What does need a little further mention is `Ctrl-C`. +`` acts almost universally identically to `Esc`, so there’s nothing real +of note there. What does need a little further mention is ``. -`Ctrl-C` is a cancel signal, so its job is just to get you straight out of +`` is a cancel signal, so its job is just to get you straight out of whatever you’re doing and back into Insert mode as fast as possible. This means -that `Ctrl-C` will not complete any pending abbreviations or send the +that `` will not complete any pending abbreviations or send the `InsertLeave` signal back to Vim (which some of your plugins may depend on). -This doesn’t mean that `Ctrl-C` is bad or should be avoided; it’s just the most +This doesn’t mean that `` is bad or should be avoided; it’s just the most heavy handed of the two. Your mileage may vary. ## Expert Mode diff --git a/_posts/2017-01-09-a-new-year-a-new-focus.md b/_posts/2017-01-09-a-new-year-a-new-focus.md index c21bee13..5ea30052 100644 --- a/_posts/2017-01-09-a-new-year-a-new-focus.md +++ b/_posts/2017-01-09-a-new-year-a-new-focus.md @@ -16,11 +16,11 @@ see why. Over the past three years of consultancy work I’ve helped some [amazing people](/#section:clients) level up their CSS architecture, but there’s also -been a lot of other work that’s happened alongside that. With a great majority -of these clients, we’ve also taken a look at how their sites actually perform -both over the wire and on users’ devices. I’ve helped companies large and small -focus entirely on optimising performance, and it’s something I am very serious -and passionate about. +been a lot of other work that’s happened alongside it. With a great majority of +these clients, we’ve also taken a look at how their sites actually perform both +over the wire and on users’ devices. I’ve helped companies large and small focus +entirely on optimising performance, and it’s something I am very serious and +passionate about. It’s something I am keen to do more of. @@ -39,7 +39,7 @@ there are two workstreams flowing in opposite directions. The people tasked with building websites and applications often forget that they tend to do so in a bubble of wired connections and powerful machines, failing to -understand the real-world conditions that people use their products in. The +understand the real-world conditions in which people use their products. The [next Billion](https://qz.com/on/the-next-billion/) (with a capital B) internet users certainly [do not enjoy](https://www.webworldwide.io/) the increasingly Westernised conditions for which we seem to build things. @@ -47,12 +47,10 @@ increasingly Westernised conditions for which we seem to build things. The more I’ve traveled, worked with clients, or talked with developers, the more apparent it has become that there is a skills and/or knowledge gap across companies: from executive level, all the way down to development teams. A -conversation I had recently really highlighted this further. Whilst discussing -the intricacies of a certain performance (anti-)pattern, a developer brazenly -claimed that …let’s assume an 8MB connection and 50ms RTT.. It’s exactly -these lines of thinking that I want to help to change. - - +conversation I had recently served to highlight this issue further. Whilst +discussing the intricacies of a certain performance (anti-)pattern, a developer +brazenly claimed …let’s assume an 8MB connection and 50ms RTT.. It’s +exactly these lines of thinking that I want to help to change. But! The good thing about being in this position is that it gives us a lot of room for improvement. Let’s make it better. diff --git a/_posts/2017-01-17-ack-for-css-developers.md b/_posts/2017-01-17-ack-for-css-developers.md new file mode 100644 index 00000000..5df60976 --- /dev/null +++ b/_posts/2017-01-17-ack-for-css-developers.md @@ -0,0 +1,186 @@ +--- +layout: post +title: "Ack for CSS Developers" +date: 2017-01-17 19:07:24 +categories: Web Development +meta: "Using the Ack tool to audit and profile your CSS" +--- + +[Ack](http://beyondgrep.com/) is a powerful and very user-friendly alternative +to grep. Designed for programmers, it’s purpose-built to run searches over +source code. By default it will ignore your `.git` or `.svn` directories, and +you can tell it which types of files you’d like it to search in. For example: + +``` +$ ack --html "foo" +``` + +…will search for the string `foo` only in your HTML files. + +``` +$ ack --html --js --css "bar" +``` + +…will search for the string `bar` in your HTML, JS, and CSS files. Neat, huh? + +Get into the habit of always wrapping your search terms in quotes. Without this, +we run the risk of our search terms and regexes being interpreted as command +line arguments. + +I use Ack as part of auditing a project, or when trying to find my way around a +larger codebase. It’s also pretty useful for tracking down bugs and oddities. In +this short post, we’ll look at a small number of ways CSS developers can make +use of Ack in their workflow. + +## Installing and Configuring + +If you’re on a Mac, you can install Ack using Homebrew: + +``` +$ brew install ack +``` + +As simple as that! + +For other operating systems, check [the official installation +guide](http://beyondgrep.com/install/). + +To use Ack, you’ll probably want to `cd` into the root of your project, or the +root of your CSS directory. Ack searches all files on and below your current +location. Here’s what my terminal looks like whilst writing this article: + +``` +harryroberts in ~/Sites/csswizardry.com on (master) +» ack +``` + +### `.ackrc` + +Ack is extensible and configurable, making use of its own `.ackrc` dotfile. This +lives in your home directory, alongside your `.vimrc`, `.bashrc`, etc. Here are +some things that I added to mine that you’ll probably like as well: + +``` +--ignore-directory=is:node_modules +--ignore-directory=is:bower_components +--type-set=sass:ext:scss,sass +--type-set=markdown:ext:md,markdown +``` + +Here I’m telling Ack to exclude my `node_modules` and `bower_components` +directories, as well as adding Markdown and Sass as new filetypes. This means +that if I run: + +``` +$ ack --sass "foo" +``` + +…Ack will search every `.scss` and `.sass` file in my project. To see what +filetypes Ack will search, run: + +``` +$ ack --help-types +``` + +If you think something is missing, add it to your `.ackrc`. + +### A Note on Regex + +To use Ack, you will need to know a little bit of regex. Don’t worry though: my +regex is pretty weak and even I can still manage. + +## Find Decimal Pixel Values + +``` +$ ack --css "\d*\.\d*px" +``` + +We don’t want to have any decimal places in any of our pixel values (e.g. +`7.5px`), so let’s search for those: + +* `\d*` will match zero or more (`*`) `\d`igits. The reason I’m looking for zero + or more is because I want to find both `.5px` or `11.2px`. +* `\.` will match a literal full-stop/period character. +* `\d*` is the same as before. This means I will find both `97.856px`, or + `52.px` (which is actually just an error). +* `px` will match the literal string `px`: I don’t want to look for ems or rems + or percentages because they accept float values. + +See [the demo](https://regex101.com/r/JhFQD3/1). + +## Find IDs + +We definitely [shouldn’t be using IDs in +CSS](http://cssguidelin.es/#ids-in-css), so let’s look for them: + +``` +$ ack --css -i "#[-_a-z][-_a-z0-9]*(?=[^}]*\{)" +``` + +Firstly, notice the `-i` flag. This tells Ack to run our regexes case +insensitively. + +This pretty complex regex does a few things: + +* `#` finds a literal hash (`#`) symbol. +* `[-_a-z]` finds a single hyphen (`-`), underscore (`_`), or case insensitive + `a-z`, denoting a valid start to an ID. +* `[-_a-z0-9]*` does almost exactly the same as above, except this time we’re + looking for zero or more (`*`) characters, and for digits as well (`0-9`). + We’re doing this separately from the previous lookup because IDs can’t start + with numbers. +* `(?=[^}]*\{)` is running a positive lookahead, just checking that we encounter + an opening curly brace (`\{`) next, and not a closing one (`[^}]`). + +This means we will find IDs, but not hex values. + +**N.B.** Because of Sass’ nesting abilities, nested code containing hex values +becomes a false positive. As such, only run this regex over your compiled CSS. +Please refer to [the demo](https://regex101.com/r/BhVEcz/1). + +## Background Shorthand + + +``` +$ ack --css -i "background:\s*#[a-f0-9]*;" +``` + +I [recently +wrote](/2016/12/css-shorthand-syntax-considered-an-anti-pattern/) +about how I consider background shorthand syntax an anti-pattern, so we should +probably look for that whilst we’re here. + +* `background:` finds the literal string background followed by a colon (`:`). +* `\s*` matches zero or more units of whitespace between the colon and the + beginning of a hex value. +* `#` is the literal hash symbol (`#`), the beginning of a hex value. +* `[a-f0-9]*` is a valid hex value (e.g. `#f00`, `#BADA55`). Setting the `-i` + flag means that our regex is now case insensitive. +* `;` matches the literal semi-colon character (`;`) which denotes the + termination of the declaration. + +See [the demo](https://regex101.com/r/1gqf73/1). + +## Find Unitted Zeroes + +``` +$ ack --css "\b0(px|r?em)" +``` + +This is a little pedantic of me, but putting a unit (e.g. `px`) on a zero (`0`) +is redundant: zero pixels is the same distance as zero lightyears. Let’s look +for them. + +* `\b` looks for a word boundary. This means we’re looking for zeroes at the + start of a string (i.e. `0px`) and not midway through one (e.g. `210px`). +* `0` is looking for the literal zero character (`0`). +* `(px|r?em)` looks for the literal strings `px` or `rem` or `em`. +* `r?em` makes the `r` optional, so we can match either `rem` or `em` at the + same time. + +See [the demo](https://regex101.com/r/EoH8Z6/1). + +Those are just a few of the most common things I search CSS files for as part of +an audit, but of course Ack can help me find all manner of things, from finding +specific classes, properties, selectors, or values, right the way to finding +errors and bugs. diff --git a/_posts/2017-01-25-moving-css-wizardry-onto-https-and-http-2.md b/_posts/2017-01-25-moving-css-wizardry-onto-https-and-http-2.md new file mode 100644 index 00000000..da12debc --- /dev/null +++ b/_posts/2017-01-25-moving-css-wizardry-onto-https-and-http-2.md @@ -0,0 +1,138 @@ +--- +layout: post +title: "Moving CSS Wizardry onto HTTPS and HTTP/2" +date: 2017-01-25 11:45:58 +categories: Web Development +meta: "Improving security and performance on CSS Wizardry" +--- + +Hopefully by now, you should be able to [read this article over +HTTPS](/2017/01/moving-css-wizardry-onto-https-and-http-2/) +and HTTP/2. (If that link doesn’t work, please hit your back button and [let me +know](https://twitter.com/csswizardry)!) I made the switch yesterday, and all +being well the new DNS settings have propagated through. At some point soon I +will begin forcing all HTTP traffic to HTTPS. + +The site is still built with Jekyll and hosted on GitHub Pages, but it’s now +fronted by Cloudflare who offer a plethora of [performance-related +services](https://www.cloudflare.com/performance/). I was only really interested +in HTTPS because it allows me to use, among other things, HTTP/2[^1], Brotli, +and Service Worker (~~I’m not actually using the latter two yet, but now at +least I can~~ CSS Wizardry is now running on a simple Service Worker!), and +when my buddy [James](https://twitter.com/jameskirkby) tipped me off as to [just +how +simple](https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/) +the process is, I got stuck in and got it done. + +As an aside, I had some issues specific to my domain registrar (not GitHub or +Cloudflare) which my very good friend +[Steve](https://twitter.com/StephenMelrose) helped out with. He’s a very +talented software and Ops engineer who managed to solve in _minutes_ a problem +that had troubled me all day. Thanks, Steve! + +## HTTPS + +My site is completely static; it doesn’t take any user input, there is no logic +or scripting, no database, so I didn’t feel like the need for HTTPS _from a +security point of view_ was all that pressing[^2]. However, HTTPS is a +prerequisite for a number of other technologies, and having a secure +site—regardless of its content—is never a bad thing. More on the first bit in a +moment, but for now I want to talk a little about security. + +I imagine that although most users won’t have much of an understanding as to the +technical implications behind a secure or a not-secure site (I’m hesitant to use +the word _insecure_), they are becoming aware that there is such thing as +security. With Google’s intent to [mark certain webpages as +insecure](https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html), +and the general increase in awareness, users _do_ know that secure websites are +a thing. The implication, therefore, is that any site that isn’t explicitly +marked as being secure must be insecure (whether that’s actually the case or +not). + +To this end, I think that HTTPS is as much an exercise in branding and trust as +it is in security, and that it will steadily become more and more ubiquitous. +This is only a good thing. + +Further, HTTPS is required in order for certain other technologies to be +utilised: + +* **Brotli**, an improved compression algorithm from Google, needs to run over + HTTPS because of third parties (ISPs, proxies, etc.) infamously trying to + recompress already compressed transfer. By preventing them getting at it in + the first place, it means that they can’t try running gzip over a new, unknown + content encoding (e.g. Brotli). +* **Service Worker** absolutely needs to run over HTTPS, because it’s basically + a man in the middle. We’re building a proxy that sits in between our users and + our servers, so the need for security there should be pretty clear. + +## HTTP/2 + +HTTP/2 (or H2, as it’s commonly referred to) is a vast, vast improvement on the +HTTP/1.1 protocol that we’ve been using for almost two decades. It brings many +benefits to both developers and users, but many of its best features are centred +around performance: + +* **Compressed headers**: HTTP/1.1 sends its headers uncompressed, which creates + a surprising amount of overhead. HTTP/2 reduces that by compressing the + response headers as well as the response body. +* **Multiplexing:** get around head of line blocking and lack of parallelisation + by sending multiple assets asynchronously over the same TCP connection. +* **Server push**: allows developers to send late requested assets preemptively. + +A lot of HTTP/2’s additions will moot the domain sharding, concatenating, and +inlining strategies we came up with as hacks, and will instead allow us to +deliver faster experiences with simpler architectures: we can optimise assets +all we like, but there is no denying that HTTP/2 gives developers an astounding +performance boost right out of the box. + +Currently I’m not making that much use of anything HTTP/2 offers me other than +multiplexing and header compression (because I didn’t even have to lift a +finger for those). My site is already pretty slim, and I’m serving so few assets +that one could almost argue over-engineering, but one really great example of +where I will benefit from HTTP/2 multiplexing is this [relatively large list of +images on the homepage](/#section:clients). + +## Browser Support + +Support for HTTP/2 is [pretty good](http://caniuse.com/#feat=http2), and always +improving. Servers capable of serving over HTTP/2 will also still deliver to +HTTP/1.x clients, so nothing will break. + +However, it might not be time for your company to switch over too. +Unfortunately, HTTP/2 best practices become bad practices in HTTP/1.1, and +HTTP/1.1 best practices become bad practices in HTTP/2. Optimising for one will +be detrimental to the other, and it’s pretty hard to satisfy both camps. + +Fortunately for me, looking at the data, over the past 24 months over 85% +of CSS Wizardry’s traffic has come from a browser that supports HTTP/2. For me +it’s pretty clear that using HTTP/2 is the right decision. Other companies +(government, ecommerce, etc.) might not have quite such a clear cut view. + +## What Next + +~~Next up, I can look at implementing~~ I have now implemented a simple +Service Worker to provide better caching strategies, as well as a simple offline +page for users on poor or non-existent connections. I should also look into +splitting up my CSS into more granular, individually cacheable chunks. + +Unfortunately, given that I am still hosting on GitHub Pages, I am limited in +how much I can implement. Things like enabling Brotli will have to be done by +Cloudflare, and utilising Server Push would require access to server-level +configuration. That stuff will have to wait, but I can probably manage without +it whilst I’m serving up a flat-file website with such a small footprint in the +first place. + +- - - + +With all of this said, despite HTTP/2’s clearly superior approach to optimising +user experiences, there is still great need for fundamental performance +knowledge within teams: optimising assets, structuring more elegant delivery, +and building to support non-HTTP/2 environments are all still very important. + +If you’d like any advice or help with any of the above, I am lining up +performance consultancy work for Q2 onward. [Get in touch.](/contact/) + +- - - + +[^1]: Interestingly, the HTTP/2 standard doesn’t define HTTPS as being mandatory, but almost all browser vendors have stated that they will only support HTTP/2 over a secure connection, which makes it pretty mandatory in practice. +[^2]: I know, I know: there’s a lot more benefit to HTTPS than that. diff --git a/_posts/2017-02-06-typography-for-developers.md b/_posts/2017-02-06-typography-for-developers.md new file mode 100644 index 00000000..4be000e6 --- /dev/null +++ b/_posts/2017-02-06-typography-for-developers.md @@ -0,0 +1,213 @@ +--- +layout: post +title: "Typography for Developers" +date: 2017-02-06 22:22:34 +categories: Web Development, Typography +meta: "A look at the simple differences that developers and engineers can make in order to improve the quality of their typography" +--- + + + +Since as long as I can remember, I’ve had a soft spot for typography, and when +it makes up so much of the web, typography should be good. Learning how to +design with type, and pair typefaces, is a skill unto itself, but the good news +for us less design-minded developers is that there are a few simple rules we can +follow to get guaranteed better looking text with almost zero effort. And if +there’s one thing developers love, it’s rules. + +Time and again I see mis-implemented type that could have been avoided simply by +developers having a better appreciation for, and understanding of, some +typographical nuance. Learn and memorise the rules in this article and you’ll +find that your text will become much more harmonious and polished, and you won’t +have designers bugging you about using the wrong type of dash… + +## Ellipses + +Let’s start with the simplest one, the ellipsis. The ellipsis represents an +omission or trailing of thought. It is a single glyph comprising three dots, +like so: + +

To be continued…

+ +Try highlighting the three dots: notice how there’s only one character there, +not three? That because the ellipsis is not three separate period glyphs, and it +most **definitely** isn’t a whole series of periods: + +

To be continued........

+ +That isn’t a thing at all, so certainly never do that. + +If you want to write an ellipsis character, you have a few options: + +| Mac | Win | HTML | Output | +| ----- | -------- | ---------- | ------ | +| Alt+; | Alt+0133 | `…` | … | + +- - - + +## Quotes + +The quotes you find on your keyboard are ambidextrous, or _dumb_ quotes. They +are big, awful, clumsy, straight lines that look like wedges jammed into your +text. They exist purely because of space constraints on modern keyboards: there +just isn’t enough room to have left and right single- and double-quote marks, so +instead we have quote marks that can do both. + +

'Single' and "double" dumb quotes. Ugly.

+ +These are the kinds of quotes you’re used to writing in your code, and they’re +fine there, but in any prose we want to make sure we use proper _book_ quotes. +Their purposefully designed shapes are much more sympathetic to the typeface, +and are visually much less jarring: + +

‘Single’ and “double” book quotes. Beautiful.

+ +### Apostrophes + +Apostrophes follow the same rule as quotes, and use the same glyph as a right +single quote: + +

It's awful like this.

+ +See how awkward and harsh that looks? Like it doesn’t belong? + +

It’s much nicer like this.

+ +| Mac | Win | HTML | Output | +| ----------- | -------- | --------- | ------ | +| Alt+] | Alt+0145 | `‘` | ‘ | +| Alt+Shift+] | Alt+0146 | `’` | ’ | + +### Sixty-Sixes and Ninety-Nines + +When I was at school we were taught that opening quotes look like two sixes, 66, +and that closing quotes look like two nines, 99. This likeness is much more +apparent in serif faces: + +

“Sixty-sixes and ninety-nines.”

+ +| Mac | Win | HTML | Output | +| ----------- | -------- | --------- | ------ | +| Alt+[ | Alt+0147 | `“` | “ | +| Alt+Shift+[ | Alt+0148 | `”` | ” | + +However, I seldom use double quotes. I share Jost Hochil’s sentiment that [a] +more attractive appearance is achieved by using single quotation marks for the +more frequently occurring quotations, and the double version for the less +frequent occurrence of quotations within quotations.[^1] + +American English tends toward the use of “double quotes”, but I much prefer the +less obtrusive appearance of ‘single quotes’. They look far more subtle in +passages of text, and the best typography always goes unnoticed. + +

‘Sixes and nines.’

+ +- - - + +## Dashes + +Dashes are a whole chapter unto themselves. Again, as with the ambidextrous +quotes, physical limitations on keyboards meant that we have just one catch-all +key, the hyphen, that is often called upon to fulfil the role of all kinds of +dash. + +### Hyphens + +The hyphen on your keyboard is actually only useful for a small number of tasks. +If you need a compound modifier (e.g. a _light-green dress_), a double barrelled +name (e.g. _Robert Bayden-Powell_), or words split over two lines in justified +text, you should use a hyphen. Pretty much everything else has a more specific +type of dash that should be used. + +

Front-end Developer

+ +| Mac | Win | HTML | Output | +| ----------- | -------- | --------- | ------ | +| - | - | `-` | - | + +### Minuses + +If you really want to show off, there’s technically a different character for +minuses. A hyphen is a very close approximation, but is set a little lower and +shorter than a true minus. + +

Your balance is £-1902.

+ +

Your balance is £−1902.

+ +Use this in any math you need to write, or for displaying negative values. +Unfortunately it’s a little harder (read, potentially impossible) to write out +on a Mac. + +| Mac | Win | HTML | Output | +| ----------- | -------- | --------- | ------ | +| N/A | Alt+2212 | `−` | − | + +### En Dashes + +The en dash is a slightly longer dash used to denote ranges or relations, e.g.: + +

Refer to pages 88–93.

+ +

Father–son relationship.

+ +It is typically, though not necessarily, half the width of the em dash. + +| Mac | Win | HTML | Output | +| ----------- | -------- | --------- | ------ | +| Alt+- | Alt+0150 | `–` | – | + +### Em Dashes + +The em dash is usually one em wide (hence the name), meaning that it would be 24 +points wide in a 24pt font, 12pt wide in a 12pt font, and so on. It represents a +change in thought, and is a slightly more elegant substitute for parenthesis. + +

It has been said—though I would say otherwise—that I’m +something of a pedant.

+ +It could also be used in place of a colon. + +

The three technical ingredients for responsive web +design—fluid grids, flexible images, and media queries.

+ +| Mac | Win | HTML | Output | +| ----------- | -------- | --------- | ------ | +| Alt+Shift+- | Alt+0151 | `—` | — | + +Em dashes are usually set with no space between them and the adjoining +character, however some people prefer to use an en dash set with spaces and +avoid the em dash altogether. I’m not so much a fan of this approach as it can +often look a little ambiguous, but let your decision be guided by your +styleguide and/or the typeface. + +

Spaced en dashes – like these – can take the place of +ems.

+ +#### Hair Spaces + +Again, if you’re feeling particularly fancy, you can set your em dashes with +hair spaces (` `) either side of them. + +

Hair-spaced em dashes — like +these — are pretty neat.

+ +| Mac | Win | HTML | Output | +| ----------- | -------- | --------- | --------- | +| N/A | N/A | ` ` | ] [ | + +- - - + +There’s plenty more out there to be learned, but for now I think that would make +a great start. A few simple rules that drastically improve the quality of your +text without you needing any real design knowledge. + +- - - + +[^1]: [Detail in Typography](https://www.amazon.co.uk/Jost-Hochuli-Typography-English-Reprint/dp/2917855665/) diff --git a/_posts/2017-02-08-code-smells-in-css-revisited.md b/_posts/2017-02-08-code-smells-in-css-revisited.md new file mode 100644 index 00000000..e8dd4b3e --- /dev/null +++ b/_posts/2017-02-08-code-smells-in-css-revisited.md @@ -0,0 +1,369 @@ +--- +layout: post +title: "Code Smells in CSS Revisited" +date: 2017-02-08 12:14:18 +categories: Web Development +meta: "An update to my 2012 article, Code Smells in CSS" +--- + +Way back in 2012, I wrote a post about potential CSS anti-patterns called +[Code Smells in CSS](/2012/11/code-smells-in-css/). Looking back on +that piece, I still agree with all of it even four years later, but I do have +some new things to add to the list. Again, these aren’t necessarily always bad +things, hence referring to them as code smells: they might be perfectly +acceptable in your use case, but they still smell kinda funny. + +Before we start, then, let’s remind ourselves what a Code Smell actually is. +From [Wikipedia](https://en.m.wikipedia.org/wiki/Code_smell) (emphasis mine): + +> Code smell, also known as bad smell, in computer programming code, refers to +> any symptom in the source code of a program that **possibly indicates a deeper +> problem**. According to Martin Fowler, ‘a code smell is a surface indication +> that usually corresponds to a deeper problem in the system’. Another way to +> look at smells is with respect to principles and quality: ‘smells are certain +> structures in the code that indicate **violation of fundamental design +> principles** and negatively impact design quality’. Code smells are usually +> not bugs—**they are not technically incorrect** and do not currently prevent +> the program from functioning. Instead, **they indicate weaknesses in design +> that may be slowing down development** or increasing the risk of bugs or +> failures in the future. Bad code smells can be an indicator of factors that +> contribute to technical debt. Robert C. Martin calls a list of code smells a +> ‘value system’ for software craftsmanship. + +So they’re not technically, always wrong, they’re just a good litmus test. + +## `@extend` + +Hopefully I can keep this first one nice and brief: I have long been vocal about +the side effects and pitfalls of `@extend`, and now I would actively consider it +a code smell. It’s not absolutely, always, definitely bad, but it usually is. +Treat it with suspicion. + +The problems with `@extend` are manifold, but to summarise: + +* **It’s actually worse for performance than mixins are.** Gzip favours + repetition, so CSS files with greater repetition (i.e. mixins) achieve a + greater compression delta. +* **It’s greedy.** Sass’ `@extend` will `@extend` every instance of a class that + it finds, giving us crazy-long selector chains [that look like + this](https://twitter.com/gaelmetais/status/564109775995437057). +* **It moves things around your codebase.** Source order is vital in CSS, so + moving selectors around your project should always be avoided. +* **It obscures the paper-trail.** `@extend` hides a lot of complexity in your + Sass that you need to unpick more gradually, whereas the multiple class + approach puts all of the information front-and-center in your markup. + +For further reading: + +* [Mixins Better for + Performance](/2016/02/mixins-better-for-performance/) +* [When to Use `@extend`; When to Use a + Mixin](/2014/11/when-to-use-extend-when-to-use-a-mixin/) +* [Extending Silent Classes in + Sass](/2014/01/extending-silent-classes-in-sass/) + +## String Concatenation for Classes + +Another Sass-based gripe is the use of the `&` to concatenate strings in your +classes, e.g.: + +``` +.foo { + color: red; + + &-bar { + font-weight: bold; + } + +} +``` + +Which yields: + +``` +.foo { + color: red; +} + +.foo-bar { + font-weight: bold; +} +``` + +The obvious benefit of this is its terseness: the fact that we have to write our +`foo` namespace only once is certainly very DRY. + +One less obvious downside, however, is the fact that the string `foo-bar` now no +longer exists in my source code. Searching my codebase for `foo-bar` will +return only results in HTML (or compiled CSS if we’ve checked that into our +project). It suddenly became a lot more difficult to locate the source of +`.foo-bar`’s styles. + +I am much more a fan of writing my CSS longhand: on balance, I am far more +likely to look for a class than I am to rename it, so findability wins for me. +If I join a project making heavy use of Sass’ string concatenation, I’m usually +expecting to have a hard time tracking things down. + +Of course you could argue that sourcemaps will help us out, or that if I’m +looking for a class of `.nav__item` then I simply need to open the `nav.scss` +file, but unfortunately that’s not always going to help. For a little more +detail, I made [a screencast](https://www.youtube.com/watch?v=MGzoRM3Al40) about +it. + +## Background Shorthand + +Something else I discussed only recently is the use of `background` shorthand +syntax. For full details, please refer to [the relevant +article](/2016/12/css-shorthand-syntax-considered-an-anti-pattern/), but the +summary here is that using something like: + +``` +.btn { + background: #f43059; +} +``` + +…when you probably meant: + +``` +.btn { + background-color: #f43059; +} +``` + +…is another practice I would consider a code smell. When I see the former being +used, it is seldom what the developer actually intended: nearly every time they +really meant the latter. Where the latter _only_ sets or modifies a background +colour, the former will also reset/unset background images, positions, +attachments, etc. + +Seeing this in CSS projects immediately warns me that we could end up having +problems with it. + +## Key Selector Appearing More Than Once + +The key selector is the selector that actually gets targeted/styled. It is +often, though not always, the selector just before your opening curly brace +(`{`). In the following CSS: + +``` +.foo {} + +nav li .bar {} + +.promo a, +.promo .btn {} +``` + +…the key selectors are: + +* `.foo`, +* `.bar`, +* `a`, and +* `.btn` respectively. + +If I were to take a codebase and [ack for +`.btn`](/2017/01/ack-for-css-developers/), I might see some output like this: + +``` +.btn {} + +.header .btn, +.header .btn:hover {} + +.sidebar .btn {} + +.modal .btn {} + +.page aside .btn {} + +nav .btn {} +``` + +Aside from the fact that a lot of that is just generally pretty poor CSS, the +problem I’m spotting here is that `.btn` is defined many times. This tells me +that: + +1. **there is no Single Source of Truth** telling me what buttons look like; +2. **there has been a lot of mutation** meaning that the class `.btn` has many + different potential outcomes, all via mutable CSS. + +As soon as I see CSS like this, I’m aware of the fact that doing any work on +buttons will have a large surface area, tracking down exactly where buttons’ +styles come from will be a lot more difficult, and that changing anything will +likely have huge knock-on effects elsewhere. This is one of the key problems +with mutable CSS. + +Make use of something like BEM in order to create completely brand new classes +that carry those changes, e.g.: + +``` +.btn {} + +.btn--large {} + +.btn--primary {} + +.btn--ghost {} +``` + +Just one key selector each. + +## A Class Appearing in Another Component’s File + +On a similar but subtly different theme as above, the appearance of classes in +other components’ files is indicative of a code smell. + +Where the previous code smell deals with the question of there being more than +one instance of the same key selector, this code smell deals with where those +selectors might live. Take this question from [Dave +Rupert](https://twitter.com/davatron5000): + +

+
+ .some-context .thing { /* special rules and overrides */ } +
Does that go in thing.css or some-context.css? +
+ — Dave Rupert (@davatron5000) 7 February, 2017 +

+ + + +If we need to style something differently because of its context, where should +we put that additional CSS? + +1. In the file that styles the thing? +2. In the file that controls that context? + +Let’s say we have the following CSS: + +``` +.btn { + [styles] +} + +.modal .btn { + font-size: 0.75em; +} +``` + +Where should `.modal .btn {}` live? + +It should live **in the `.btn` file.** + +We should do our best to group our styles based on the subject (i.e. the key +selector). In this example, the subject is `.btn`: that’s the thing we actually +care about. `.modal` is purely a context for `.btn`, so we aren’t styling it at +all. To this end, we shouldn’t move `.btn` styling out into another file. + +The reason we shouldn’t do this is simply down to collocation: it’s much more +convenient to have the context of all of our buttons in one place. If I want to +get a good overview of all of the button styles in my project, I should expect +to only have to open `_components.buttons.scss`, and not a dozen other files. + +This makes it much easier to move all of the button styles onto a new project, +but more importantly it eases cognitive overhead. I’m sure you’re all familiar +with the feeling of having ten files open in your text editor whilst just trying +to change one small piece of styling. This is something we can avoid. + +Group your styles into files based on the subject: if it styles a button, no +matter how it goes about it, we should see it in `_components.buttons.scss`. + +As a simple rule of thumb, ask yourself the question am I styling +x or am I styling y? If the answer is x, +then your CSS should live in `x.css`; if the answer is y, it should +live in `y.css`. + +### BEM Mixes + +Actually, interestingly, I wouldn’t write this CSS at all—I’d use a BEM mix—but +that’s an answer to a different question. Instead of this: + +``` +// _components.buttons.scss + +.btn { + [styles] +} + +.modal .btn { + [styles] +} + + +// _components.modal.scss + +.modal { + [styles] +} +``` + +We’d have this: + +``` +// _components.buttons.scss + +.btn { + [styles] +} + + +// _components.modal.scss + +.modal { + [styles] +} + + .modal__btn { + [styles] + } +``` + +This third, brand new class would get applied to the HTML like this: + +``` + +``` + +This is called a BEM mix, in which we introduce a third brand new class to refer +to a button belonging to a modal. This avoids the question of where things live, +it reduces the specificity by avoiding nesting, and also prevents mutation by +avoiding repeating the `.btn` class again. Magical. + +## CSS `@import` + +I would go as far as saying that CSS `@import` is not just a code smell, it’s an +active bad practice. It poses a huge performance penalty in that it delays the +downloading of CSS (which is a critical asset) until later than necessary. The +(simplified) workflow involved in downloading `@import`ed CSS looks a little +like: + +1. Get the HTML file, which asks for a CSS file; +2. Get the CSS file, which asks for another CSS file; +3. Get the last CSS file; +4. Begin rendering the page. + +If we’d got that `@import` flattened into one single file, the workflow would +look more like this: + +1. Get the HTML file, which asks for a CSS file; +2. Get the CSS file; +3. Begin rendering the page. + +If we can’t manage to smush all of our CSS into one file (e.g. we’re linking to +Google Fonts), then we should use two `` elements in our HTML instead of +`@import`. While this might feel a little less encapsulated (it would be nicer +to handle all of these dependencies in our CSS files), it’s still much better +for performance: + +1. Get the HTML file, which asks for two CSS files; +2. Get both CSS files; +3. Begin rendering the page. + +- - - + +So there we have a few additions to my previous piece on Code Smells. These are +usually all things I have seen and suffered in the wild: hopefully now you can +avoid them as well. diff --git a/_posts/2017-02-12-base64-encoding-and-performance-part-2.md b/_posts/2017-02-12-base64-encoding-and-performance-part-2.md new file mode 100644 index 00000000..ada0839a --- /dev/null +++ b/_posts/2017-02-12-base64-encoding-and-performance-part-2.md @@ -0,0 +1,262 @@ +--- +layout: post +title: "Base64 Encoding & Performance, Part 2: Gathering Data" +date: 2017-02-12 15:47:21 +categories: Web Development +meta: "Statistics, tests, and numbers looking at the performance costs of Base64" +--- + +**This is the second in a two-part post. [Read Part +1](/2017/02/base64-encoding-and-performance/).** + +Hopefully you made it here after reading [part +1](/2017/02/base64-encoding-and-performance/) of this post. If not, I’d +encourage you to start there for some context. + +- - - + +After writing a somewhat insistent piece on the pitfalls of using Base64 +encoding to inline assets (predominantly images) into stylesheets, I decided to +actually gather some data. I set about a simple test in which I would measure +some milestone and runtime timings across ‘traditionally’ loaded assets, and +again over assets who’ve been inlined using Base64. + +## The Test, and Making It Fair + +I started out by creating two simple HTML files that have a full-cover +background image. The first was loaded normally, the second with Base64: + +* [Normal](https://csswizardry.net/demos/base64/) +* [Base64](https://csswizardry.net/demos/base64/base64.html) + +The [source image](https://www.flickr.com/photos/rockersdelight/26842162186/) +was taken by my friend [Ashley](https://twitter.com/iamashley). I resized it +down to 1440×900px, saved it out as a progressive JPEG, ran it through JPEGMini +and ImageOptim, and only then did I take a Base64 encoded version: + +``` +harryroberts in ~/Sites/csswizardry.net/demos/base64 on (gh-pages) +» base64 -i masthead.jpg -o masthead.txt +``` + +This was so that the image was appropriately optimised, and that the Base64 +version was as similar as we can possibly get. + +I then created two stylesheets: + +``` +* { + margin: 0; + padding: 0; + box-sizing: border-box; +} + +.masthead { + height: 100vh; + background-image: url("[masthead.jpg|]"); + background-size: cover; +} +``` + +Once I had the demo files ready, I hosted them on a live URL so that that we’d +be getting realistic latency and bandwidth to measure. + +I opened a performance-testing-specific profile in Chrome, closed every single +other tab I had open, and I was ready to begin. + +I then fired open Chrome’s Timeline and began taking measurements. The process +was a little like: + +0. Disable caching. +0. Clear out leftover Timeline information. +0. Refresh the page and record Network and Timeline activity. +0. Completely discard any results that incurred DNS or TCP connections (I didn’t + want any timings affected by unrelated network activity). +0. Take a measurement of **DOMContentLoaded**, **Load**, **First Paint**, + **Parse Stylesheet**, and **Image Decode**. +0. Repeat until I got 5 sets of clean data. +0. Isolate the median of each measurement (the median is the [correct average to + take](/2017/01/choosing-the-correct-average/)). +0. Do the same again for the Base64 version. +0. Do it all again for Mobile (ultimately I’m collecting four sets of data: + Base64 and not-Base64 on Desktop and on Mobile[^1]). + +Point 4 was an important one: any connection activity would have skewed any +results, and in an inconsistent way: I only kept results if there was absolutely +zero connection overhead. + +### Testing Mobile + +I then emulated a mid-range mobile device by throttling my CPU by 3×, and +throttled the network to Regular 2G and did the whole lot again for Mobile. + +You can [see all the +data](https://docs.google.com/spreadsheets/d/1P720QU6CQ7pZUgCLtkOdUmwpwp_8nEyTMBN2zq5Ajmc/edit?usp=sharing) +that I collected on Google Sheets (all numbers are in milliseconds). One thing +that struck me was the quality and consistency of the data: very few statistical +outliers. + +Ignore the _Preloaded Image_ data for now (we’ll come back to that +[later](#a-third-approach)). Desktop and Mobile data are in different sheets +(see the tabs toward the bottom of the screen). + +## Some Insights + +The data was very easy to make sense of, and it confirmed a lot of my +suspicions. Feel free to look through it in more detail yourself, but I’ve +extracted the most pertinent and meaningful information below: + +* Expectedly, the **DOMContentLoaded event remains largely unchanged** between + the two methods on both Desktop and Mobile. There is no ‘better option’ here. +* The **Load event** across both methods is similar on Mobile, but **on Desktop + Base64 is 2.02× slower** (Regular: 236ms, Base64: 476ms). Base64 is slower. +* Expectedly, **parsing stylesheets** is dramatically slower if they’re full of + Base64 encoded assets. On Desktop, parsing was **over 10× slower**. On + **Mobile, parsing was over 32× slower**. Base64 is eye-wateringly slower. +* On Desktop, Base64 images **decoded 1.23× faster than regular images**. Base64 + is faster. +* …but on mobile, **regular images decoded 2.05× faster** than Base64 ones. + Base64 is slower. +* **First Paint** is a great metric for measuring perceived performance: it + tells us when the users first starts seeing something. On Desktop, regular + images’ First Paint happened at 280ms, but Base64 happened at 629ms: **Base64 + was 2.25× slower**. +* On **Mobile, First Paint** occurred at 774ms for regular images and at 7950ms + for Base64. That’s a **10.27× slowdown for Base64**. Put another way, regular + images begin painting in under 1s, whereas Base64 doesn’t start painting until + almost 8s. Staggering. Base64 is drastically slower. + +It’s quite clear to see that across all of these metrics, we have an outright +winner: nearly everything—and on both platforms—is faster if we stay away from +Base64. We need to put particular focus on lower powered devices with higher +latency and restricted processing power and bandwidth, because the penalties +here are substantially worse: **32× slower stylesheet parsing and 10.27× slower +first paint**. + +## A Third Approach + +One problem with loading images the regular way is the waterfall effect it has +on downloads: we have to download HTML which then asks for CSS which then asks +for an image, which is a very synchronous process. Base64 has the theoretical +advantage in that loads the CSS and the image at the same time (in practice +there is no advantage because although they both show up together, they both +arrive late), which gives us a more concurrent approach to downloading assets. + +Luckily, there is a way we can achieve this parallelisation without having to +cram all of our images into our stylesheets. Instead of leaving the image to be +a late-requested resource, we can preload it, like so: + +``` + +``` + +I made another demo page: + +* [Preloaded Image](https://csswizardry.net/demos/base64/preload.html) + +By placing this tag in the `head` of our HTML, we can actually tell the HTML to +download the image instead of leaving the CSS to ask for it later. This means +that instead of having a request chain like this: + +``` + | +|-- HTML --| | + |- CSS -| | + |---------- IMAGE ----------| + | +``` + +We have one like this: + +``` + | +|-- HTML --| | + |---------- IMAGE ----------| + |- CSS -| | + | +``` + +Notice a) how much quicker we get everything completed, and b) how the image is +now starting to download before the CSS file. Preloading allows us to manually +promote requests for assets who normally wouldn’t get requested until some time +later in the rendering of our page. + +I decided to make a page that utilised a regular image, but instead of the CSS +requesting it, I was going to preload it: + +``` + + +Preloaded Image + + +``` + +I didn’t notice any drastic improvements on this reduced test case because +preload isn’t really useful here: I already have such a short request chain that +we don’t get any real gains from reordering it. However, if we had a page with +many assets, preload can certainly begin to give us some great boosts. I +actually use it [on my homepage](/) to [preload the +masthead](https://github.com/csswizardry/csswizardry.github.com/blob/21044ecec9e11998d7a1e12e9f96be2aa990c652/_includes/head.html#L5-L15): +this is above the fold content that is normally quite late requested, so +promoting it this way does yield some significant change in perceived +performance. + +One very interesting thing I did notice, however, was the decode time. On +Mobile, the image decoded in 25ms as opposed to Desktop’s 36.57ms. + +* Preloaded images on Mobile decoded **1.46× faster than preloaded images did + on Desktop**. +* Preloaded images on Mobile **decoded 3.53× faster that non-preloaded images** + did on Mobile. + +I’m not sure why this is happening, but if I were to make a wild guess: I would +imagine images don’t get decoded until they’re actually needed, so maybe if we +already have a bunch of its bytes on the device before we actually have to +decode it, the process works more quickly…? Anyone reading who knows the answer +to this, please tell me! + +## Some Interesting Things I Learned + +* **Progressive JPEGs decode slower than Baseline ones.** I guess this is to be + expected given how progressive JPEGs are put together, but progressive JPEGs + _are_ better for perceived performance. Still, it is the case that decoding a + progressive JPEG takes about 3.3× as long as a baseline one. (I would still + absolutely recommend using progressive, because they feel a lot faster than + their baseline counterparts.) +* **Base64 images decode in one event,** whereas regular images decode across + several. I’m assuming this is because a data URI can’t be decoded unless it’s + complete, whereas partial JPEG data can be…? + +## Improving the Tests + +Although I did make sure my tests were as fair and uninfluenced as possible, +there are a few things I could do even better given the time (it’s the weekend, +come on…): + +* **Test on an actual device.** I throttled my CPU and connection using + DevTools, but running these tests on an actual device would have no doubt been + better. +* **Use a more suitable image on Mobile.** Because I was keeping as many + variables as possible the same across tests, I used the exact same image for + Desktop and Mobile. In fact, Mobile was only really simulating lowered device + and network power, and was not run with smaller screens or assets. Hopefully + in the real world we’d be serving a much smaller image (in terms of both + dimensions and filesize) to smaller devices. I was not. I was loading the + exact same files on the exact same viewport, only with hobbled connection and + CPU. +* **Test a more realistic project.** Again, these were very much laboratory + conditions. As I noted with preloading, this isn’t the kind of environment in + which it would shine. To the same extent, expect results to be different when + profiling a non-test-conditions example. + +- - - + +And that concludes my two-part post on the performance impact of using Base64. +It kinda just feels like confirming what we already know, but it’s good to have +some numbers to look at, and it’s especially important to take note of lower +powered connections and devices. Base64 still feels like a huge anti-pattern. + +- - - + +[^1]: Excuse the semantics here: I’m basically testing on my laptop and an emulated mobile device, but I’m not talking about screensizes. diff --git a/_posts/2017-02-12-base64-encoding-and-performance.md b/_posts/2017-02-12-base64-encoding-and-performance.md new file mode 100644 index 00000000..6f37ccb3 --- /dev/null +++ b/_posts/2017-02-12-base64-encoding-and-performance.md @@ -0,0 +1,339 @@ +--- +layout: post +title: "Base64 Encoding & Performance, Part 1: What’s Up with Base64?" +date: 2017-02-12 12:11:13 +categories: Web Development +meta: "A look at the many huge disadvantages of Base64 encoding assets into your CSS" +--- + +**This is the first in a two-part post. [Read Part +2](/2017/02/base64-encoding-and-performance-part-2/).** + +Prominent performance advice of a few years back simply stated that we should +‘reduce the number of requests we make’. Whilst this is, in general, perfectly +sound advice, it’s not without its caveats. We can actually make pages load much +more quickly by elegantly spreading our assets over a few more well considered +requests, rather than fewer. + +One of the touted ‘best practices’ born of this advice was the adoption of +Base64 encoding: the act of taking an external asset (e.g. an image) and +embedding it directly into the text-resource that would utilise it (e.g. a +stylesheet). The upshot of which is that we reduce the number of HTTP requests, +and that both assets (e.g. the stylesheet and the image) arrive at the same +time. Sounds like a dream, right? + +Wrong. + +_**Still seeing nine-hundred-kilobyte stylesheets?** [See my performance-audit +service](/consultancy/) to cut parse times in half._ + +Unfortunately Base64 encoding assets is very much an anti-pattern[^1]. In this +article I’m hoping to share some insights as to critical path optimisation, +Gzip, and of course, Base64. + +## Let’s Look at Some Code + +The reason I was motivated to write this article is because I’ve just been doing +a [performance audit](/performance-audits/) for a client, and I came across the very +issues I’m about to outline. This is an actual stylesheet from an actual client: +things are anonymised, but this is a completely real project. + +I ran a quick network profile over the page, and discovered just one stylesheet +(which is sorta good in a way because we definitely don’t want to see 12 +stylesheet requests), but that stylesheet came in at a whopping **925K** after +being decompressed and expanded. The actual amount of bytes coming over the wire +was substantially less, but still very high at 232K. + +As soon as we start seeing stylesheets of that size, we should start panicking. +I was relatively certain—without even having to look—that there would be some +Base64 in here. That’s not to say that I expected it to be the only factor +(plugins, lack of architecture, legacy, etc. are all likely to play a part), but +stylesheets that large are _usually_ indicative of Base64. Still: + +1. Base64 or not, 925K of CSS is terrifying. +2. Minifying it only reduces to 759K. +3. Gzipping takes us down to a mere 232K. The exact same code compressed down by + 693K. +4. 232K over the wire is still terrifying. + +It takes an eye watering 88ms even just to _parse_ a stylesheet of that size. +Getting it over the network is just the start of our troubles: + +

+ +I prettified the file[^2], saved it to my machine, ran it through +[CSSO](https://github.com/css/csso), then ran that minified output through Gzip +on its regular setting. This is how I arrived at those numbers, and I was left +looking at this: + +``` +harryroberts in ~/Sites//review/code on (master) +» csso base64.css base64.min.css + +harryroberts in ~/Sites//review/code on (master) +» gzip -k base64.min.css + +harryroberts in ~/Sites//review/code on (master) +» ls -lh +total 3840 +-rw-r--r-- 1 harryroberts staff 925K 10 Feb 11:23 base64.css +-rw-r--r-- 1 harryroberts staff 759K 10 Feb 11:24 base64.min.css +-rw-r--r-- 1 harryroberts staff 232K 10 Feb 11:24 base64.min.css.gz +``` + +The next thing to do was see just how many of these bytes were from Base64 +encoded assets. To work this out, I simply (and rather crudely) removed all +lines/declarations that contained `data:` strings (`:g/data:/d`[^3] for the Vim +users reading this). Most of this Base64 encoding was for images/sprites and a +few fonts. I then saved this file as `no-base64.css` and ran the same +minification and Gzipping over that: + +``` +harryroberts in ~/Sites//review/code on (master) +» ls -lh +total 2648 +-rw-r--r-- 1 harryroberts staff 708K 10 Feb 15:54 no-base64.css +-rw-r--r-- 1 harryroberts staff 543K 10 Feb 15:54 no-base64.min.css +-rw-r--r-- 1 harryroberts staff 68K 10 Feb 15:54 no-base64.min.css.gz +``` + +In our uncompressed CSS, we’ve managed to lose a whole 217K of Base64. This +still leaves us with an alarming amount of CSS (708K is pretty unwieldy), but +we’ve managed to get rid of a good 23.45% of our code. + +Where things really do get surprising now though is after we’ve Gzipped what’s +left. We managed to go from 708K down to just 68K over the wire! That’s **a +saving of 90.39%**. Wow. + +## Gzip Saves… + +Gzip is incredible! It’s probably the single best tool for protecting users from +developers. We managed to make a 90% saving over the wire just by compressing +our CSS. From 708K down to 68K **for free**. + +### …sometimes + +However, that’s Gzip working over **the non-Base64 encoded version**. If we look +at the original CSS (the CSS with Base64 encoding), we find that we only made a +74.91% saving. + +| Base64? | Gross Size | Compressed Size | Saving | +| ------- | ------------: | --------------: | -----: | +| Yes | 925K | 232K | 74.91% | +| No | 708K | 68K | 90.39% | + +The difference between the two two options is a staggering 164K (70.68%). **We +can send 164K less CSS over the wire just by moving those assets out to +somewhere more appropriate.** + +Base64 compresses terribly. Next time somebody tries the ol’ Yeah but +Gzip… excuse on you, tell them about this (if they’re trying to justify +Base64, that is). + +## So Why Is Base64 So Bad? + +Okay, so we’re pretty clear now that Base64 increases filesize in a manner that +Gzip can’t really help us with, but that’s only one small part of the problem. +Why are we so scared of this increase in filesize? A single image might weigh +well in excess of 232K, so aren’t we better off starting there? + +Good question, and I’m glad you mentioned images… + +## We Need to Talk About Images + +In order to understand how bad Base64 is, we first need to understand how _good_ +images are. Controversial opinion: **images aren’t as bad for performance as you +think they are**. + +Yes, images _are_ a problem. In fact, they’re the number one contributor to page +bloat. As of [2 December +2016](http://httparchive.org/interesting.php?a=All&l=Dec%202%202016), images +make up around 1623K (or 65.46%) of the average web page. That makes our 232K +stylesheet seem like a drop in the ocean by comparison. However, there are +fundamental differences between how browsers treat images and stylesheets: + +**Images do not block rendering; stylesheets do.** + +A browser will begin to render a page regardless of whether the images have +arrived or not. Heck, a browser will render a page even if images never arrive +at all! Images are not critical resources, so although they do make up an +inordinate amount of bytes over the wire, they are not a bottleneck. + +CSS, on the other hand, _is_ a critical resource. Browsers can’t begin rendering +a page until they’ve constructed the render tree. Browsers can’t construct the +render tree until they’ve constructed the CSSOM. They cannot construct the CSSOM +until all stylesheets have arrived, been uncompressed, and parsed. CSS is a +bottleneck. + +Hopefully now you can see why we’re so scared of CSS bytes: they just serve to +delay page rendering, and they leave the user staring at a blank screen. +Hopefully, you’ve also realised the painful irony of Base64 encoding images into +your CSS files: **you just turned hundreds of kilobytes of non-blocking +resources into blocking ones** in the pursuit of performance. All of those +images could have made their way over the network whenever they were ready, but +now they’ve been forced to turn up alongside much lighter critical resources. +And that doesn’t mean the images arrive sooner; it means the critical CSS +arrives later. Could it really get much worse?! + +Oh yes, it can. + +Browsers are smart. Really smart. They make a lot of performance optimisations +for us because—more often than not—they know better. Let’s think about +responsive: + +``` +.masthead { + background-image: url(masthead-small.jpg); +} + +@media screen and (min-width: 45em) { + + .masthead { + background-image: url(masthead-medium.jpg); + } + +} + +@media screen and (min-width: 80em) { + + .masthead { + background-image: url(masthead-large.jpg); + } + +} +``` + +We’ve given the browser three potential images to use here, but it will only +download one of them. It works out which one it needs, fetches that one, and +leaves the other two untouched. + +As soon as we Base64 these images, the bytes for all three get downloaded, +effectively tripling (or thereabouts) our overhead. Here’s an actual chunk of +CSS from this project (I’ve stripped out the encoded data for obvious reasons, +but in full this snippet of code totalled 26K before Gzip; 18K after): + +``` +@media only screen and (-moz-min-device-pixel-ratio: 2), + only screen and (-o-min-device-pixel-ratio:2/1), + only screen and (-webkit-min-device-pixel-ratio:2), + only screen and (min-device-pixel-ratio:2), + only screen and (min-resolution:2dppx), + only screen and (min-resolution:192dpi) { + + .social-icons { + background-image:url("data:image/png;base64,..."); + background-size: 165px 276px; + } + + .sprite.weather { + background-image: url("data:image/png;base64,..."); + background-size: 260px 28px; + } + + .menu-icons { + background-image: url("data:image/png;base64,..."); + background-size: 200px 276px; + } + +} +``` + +All users, whether on retina devices or not (heck, even users with browsers that +don’t even support media queries), will be forced to download that extra 18K of +CSS before their browser can even begin putting a page together for them. + +Base64 encoded assets will always be downloaded, even if they’re never used. +That’s wasteful at best, but when you consider that it’s waste that actually +blocks rendering, it’s even worse. + +## And We Need to Talk About Fonts + +I’ve only mentioned images so far, but fonts are almost exactly the same except +for some nuance around how browsers handle the Flash Of Unstyled/Invisible Text +(FOUT or FOIT). Fonts in this project total 166K of uncompressed CSS (124K +Gzipped (there’s that awful compression delta again)). + +Without derailing the article too much, fonts are also assets that do not +naturally live on your critical path, which is great news: your page can render +without them. The problem, however, is that browsers handle web fonts +differently: + +* **Chrome and Firefox show no text at all** for up to 3 seconds. If the web + font arrives within this three seconds the text swaps from invisible to your + custom font. If the font still hasn’t arrived after 3 seconds, the text swaps + from invisible to whatever fallback(s) you have defined. This is FOIT. +* **IE displays the fallback font immediately** and then swaps it out for your + custom font as soon as it arrives. This is FOUT. This is, in my opinion, the + most elegant solution. +* **Safari shows invisible text** until the font arrives. If the font never + arrives, it never shows a fallback. This is FOIT. It’s also an absolute + abomination. There’s every chance that your users will never be able to see + any text on your page. + +In order to get around this, people started Base64 inlining their fonts into +their stylesheets: if the CSS and the fonts arrive at the exact same time, then +there wouldn’t be a FOIT or a FOUT, because CSSOM construction and font delivery +are happening at more or less the same time. + +Only, as before, moving your fonts onto the critical path doesn’t speed up their +delivery, it just delays your CSS. There are some pretty intelligent font +loading solutions out there, but Base64 ain’t one of them. + +## And We Need to Talk About Caching + +Base64 also affects our ability to have more sophisticated caching strategies: +by coupling our fonts, images, and styles together, they’re all governed by the +same rule. This means that if we change just one hex value in our CSS +somewhere—a change that might represent up to six bytes of new data—we have to +redownload hundreds of kilobytes of styles, images, and fonts. + +In fact, fonts are a really bad offender here: fonts are very, very unlikely to +ever change. They’re a very infrequently modified resource. In fact, I just went +and checked a long-running project that another client and I are working on: the +last change to their CSS was yesterday; the last change to their font files was +eight months ago. Imagine forcing a user to redownload those fonts every single +time you update anything in your stylesheet. + +Base64 encoding means that we can’t cache things independently based on their +rate of change, and also means that we have to cache bust unrelated things +whenever something else does change. It’s a lose-lose situation. + +This is basic separation of concerns: my fonts’ caching should not be dependent +on my images’ caching should not be dependent on my styles’ caching. + +- - - + +Okay, so let’s quickly recap: + +* Base64 encoding increases filesize in ways that we can’t effectively mitigate + (e.g. Gzip). This increase in filesize delays rendering, because it’s + happening to a render-blocking resource. +* Base64 encoding also forces non-critical assets onto the critical path. (e.g + images, fonts) This means that—in this particular case—instead of needing to + download 68K of CSS before we can begin rendering the page, we need to + download over 3.4× that amount. We’re just keeping the user waiting for assets + that they originally would have never needed to wait for! +* Base64 encoding forces all asset bytes to be downloaded, even if they’ll never + be used. This is a waste of resources and, again, it’s happening on our + critical path. +* Base64 encoding restricts our ability to cache assets individually; our images + and fonts are now bound to the same caching rules as our styles, and vice + versa. + +All in all, it’s a pretty bleak situation: please avoid Base64. + +## Data Talks + +All of this article was written using things I already know. I didn’t run any +tests or have any data: it’s just how browsers work™. However, I decided to go +ahead and run some tests to see just what kind of facts and figures we’re +looking at. [Head over to Part 2 to read +more](/2017/02/base64-encoding-and-performance-part-2/). + +- - - + +[^1]: There are some very exceptional cases in which it may be sensible, but you will be absolutely certain of those cases when they arise. If you’re not absolutely certain, then it probably isn’t one of those cases. Always err on the side of caution and assume that Base64 isn’t the right approach to take. +[^2]: Open the stylesheet in Chrome’s _Sources_ tab, press the `{}` icon at the bottom left of the file, done. +[^3]: Run the global command (`:g`) across all lines; find lines that contain `data:` (`/data:`) and delete them (`/d`). diff --git a/_posts/2017-03-16-configuring-git-and-vim.md b/_posts/2017-03-16-configuring-git-and-vim.md new file mode 100644 index 00000000..d55bf901 --- /dev/null +++ b/_posts/2017-03-16-configuring-git-and-vim.md @@ -0,0 +1,289 @@ +--- +layout: post +title: "Configuring Git and Vim" +date: 2017-03-16 21:41:11 +categories: Web Development +meta: "Both amazing tools in their own rights, how can we get both playing nicely together?" +--- + +Two of my absolute all time favourite development tools have to be Git and Vim. +Easily. I’ve used both almost daily for the last (_at least_) five or so years, +so I want to share a handful of tips to help when using both together. + +This is a very short post that only shares a couple of pertinent tips, so if you +have any advancements or additional insights then please do [let me +know](https://twitter.com/csswizardry). + +## Commit Message Templates + +If you’re anything like me, you’re a bit of a stickler for formatting, +consistency, and process. If that is the case, you might be interested in +setting up a Git commit template that will be loaded every time you run: + +``` +$ git commit +``` + +This template works across all text editors (i.e. you don’t have to be using +Vim), and will automatically pre-populate the commit message with your chosen +placeholder text, ready for you to fill in and customise. + +The benefits of a template are manifold, but the main points for me are: + +1. **Process** is adhered to every time you make a commit. +2. **Automation** means that you don’t need to lift a finger, but still get + nicely formatted commit messages every time. +3. **Consistency** means that you could roll the template out across your team + and get identical commit messages from everyone. + +Luckily, Git commit templates are incredibly simple to set up. Start by creating +a file called `.git-commit-template` in your home directory (`~/`). + +Now open this file and add your placeholder text. Mine is as simple as this: + +``` +[refs #00000] Subject line + +Body (72 chars) +``` + +The first line is the title of the commit. This should be short enough to be +digestible, but long enough to convey the general scope of the commit. + +You’ll notice that it starts with `[refs #00000]`: this is a reference to an +issue or ticket number that lives elsewhere (e.g. GitHub issues). Let’s say +somebody opened an issue on your open source project to let you know that your +function wasn’t rounding its output to the nearest integer. That issue will have +an associated number, e.g. 57. + +To that end, we’d have a commit title that looks like this: + +``` +[refs #00057] Fix rounding issue with grid mixin +``` + +This means that when I’m viewing a `$ git log`, I can quickly see what each +commit is working toward, which is particularly useful when I’m logging any +non-feature branches that contain commits from many different places. As well as +that, we also get the added benefit of services like GitHub actually linking +that commit message directly to the issue in their GUI. + +The next section is the body of the commit message, where we describe or explain +the commit in greater detail, for example: + +``` +[refs #00057] Fix rounding issue with grid mixin + +The grid mixin was working largely as expected, but would not round +the output if passed an odd number. This led to scenarios where +developers were seeing grid gutters of e.g. 12.5px. + +I’ve simply wrapped the Sass `round()` function around the output, so +people will now get the nearest integer whether rounded up or down. +``` + +This expanded message offers up additional insights as to why the commit exists +and how we implemented it, and is also constrained to 72 characters in width to +ensure it fits on most (if not all) terminal screens[^1]. + +Finally, we need to tell Git that the template exists: + +``` +$ git config --global commit.template ~/.git-commit-template +``` + +Which should leave something like the following new lines in your `.gitconfig`: + +``` +[commit] + template = /Users//.git-commit-template +``` + +## Writing Commit Messages in Vim + +By default, whenever we write a commit message (not using the `-m` flag) we’re +going to get thrown into Vim. If you’re a Vim user, this is great! This is +exactly what we want. If you’re not a Vim user, [skip +ahead](#git-commit-messages-in-atom): I got you covered. + +### Constraining Columns + +You may well have Vim set up to constrain your text editing to a certain number +of columns (usually 80). If you do, great! If you don’t, simply add the +following to your `.vimrc`: + +``` +" Force the cursor onto a new line after 80 characters +set textwidth=80 +``` + +This will forcibly push your cursor onto a new line (and wrap your text for +you!) if you go beyond your 80 character limit. This is really nice whilst +writing code, because 80 characters is a pretty [widely agreed +standard](http://softwareengineering.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width). + +We can also set another option—`colorcolumn`—to let us know visually when we’re +approaching our boundary: + +``` +set colorcolumn=81 +``` + +What this will do is highlight our 81st column which lets us know that **no text +should sit on this line**. Pretty neat! + +However, as above, our commit messages need to be constrained to 72 characters, +not 80. How do we solve that problem? + +One option is to run this _every time_ we end up writing a commit message: + +``` +:set tw=72 +``` + +…but who’s got time for that?! Not me. + +Luckily we can use an `autocmd` to solve this for us! We can tell Vim that +Hey! Any time I enter a Git commit message, please can you do something for +me? + +That looks like this: + +``` +" However, in Git commit messages, let’s make it 72 characters +autocmd FileType gitcommit set textwidth=72 +autocmd FileType gitcommit set colorcolumn=73 +``` + +If the filetype is a Git commit message, automatically set new values for +`textwidth` and `colorcolumn`. + +As nice as this is, we can actually go one step further: wouldn’t it be nice to +not have to hard code our `colorcolumn` every time we change our `textwidth`? It +turns out that we can actually set `colorcolumn` to be relative to +`textwidth`[^2]: + +``` +set colorcolumn=+1 +``` + +This means that the column immediately after (`+1`) our `textwidth` cutoff point +will be highlighted, regardless of whether the number is 80, 72, or anything. So +now our Vim settings look a little like this (There is a more up to date +snippet [below](#update-2017-04-09)): + +``` +" Force the cursor onto a new line after 80 characters +set textwidth=80 +" However, in Git commit messages, let’s make it 72 characters +autocmd FileType gitcommit set textwidth=72 +" Colour the 81st (or 73rd) column so that we don’t type over our limit +set colorcolumn=+1 +``` + +It’s just a single line of config to get Vim in perfect shape for commit +messages. + +### Update 2017-04-09 + +It gets even better! The ideal commit message has a title constrained to 50 +characters and a body constrained to 72 characters. The setup we have above will +only highlight our 72 character limit for body text though, meaning we have to +work out our title’s limit more manually. However, I recently learned that the +`colorcolumn` setting can accept more than one value! We can highlight both our +title and our body’s constraints: + +``` +" Force the cursor onto a new line after 80 characters +set textwidth=80 +" However, in Git commit messages, let’s make it 72 characters +autocmd FileType gitcommit set textwidth=72 +" Colour the 81st (or 73rd) column so that we don’t type over our limit +set colorcolumn=+1 +" In Git commit messages, also colour the 51st column (for titles) +autocmd FileType gitcommit set colorcolumn+=51 +``` + +The key difference in this snippet is the last line, in which we don’t set a new +`colorcolumn` value, but we actually append the existing one (by using `+=`) and +add column number `51`. This means that—in Git commit messages—we’re still +highlighting the column immediately after our character limit by using the +relative `+1` value, and the 51st column by using the absolute `51` value. + +

Columns 51 and 73 highlighted in a Git commit message in + Vim. View full + size/quality (132KB).

+ +## Git Commit Messages in Atom… + +…or Sublime, or VS Code, etc. + +You might not want to use Vim at all, and that’s cool! But you will have +probably noticed an annoying default in Git: commit messages open in a Vim +instance! + +I can’t remember exactly, but I’m willing to bet that my first ever exposure to +Vim was through a merge conflict or expanded commit message in Git. As a +full-time Vim user now, this isn’t an issue at all, but if you prefer Atom, or +Sublime Text, or VS Code, or whatever it is you use, you’d probably rather write +your commit messages there than in Vim. + +Thankfully this is a really simple change to make: + +``` +$ git config --global core.editor +``` + +For example, if you use Atom: + +``` +$ git config --global core.editor atom +``` + +If you use Sublime: + +``` +$ git config --global core.editor 'subl --wait' +``` + +This will now open all of your commit messages there, instead of the command +line. For Sublime you need `subl`; for TextMate you need `mate`. If in doubt, +just Google [Open \ from the command +line](https://www.google.com/search?q=Open++from+the+command+line). + +Hopefully now you’ll see something like this in your `.gitconfig`: + +``` +[core] + editor = atom --wait +``` + +The `--wait` flag tells the editor to Wait for window to be closed before +returning., meaning our committing doesn’t resume/continue until we’ve saved +and closed our text editor window. + +Vim users, we’re probably pretty well set already, but if you want to make +double sure then just run: + +``` +$ git config --global core.editor vim +``` + +Which will look like this inside of `~/.gitconfig`: + +``` +[core] + editor = vim +``` + +- - - + +Regardless of which editor you use, it’s worth knowing that you can tie it and +Git together a little more closely. This should, if nothing else, make you more +comfortable, if not more productive. + +[^1]: I’d really recommend [this article](https://chris.beams.io/posts/git-commit/) if you want to read more about good commit message formatting. +[^2]: Many thanks to [Chayoung You](https://twitter.com/_Yous/status/841667465679523841) for the tip. diff --git a/_posts/2017-05-10-writing-tidy-code.md b/_posts/2017-05-10-writing-tidy-code.md new file mode 100644 index 00000000..5177df84 --- /dev/null +++ b/_posts/2017-05-10-writing-tidy-code.md @@ -0,0 +1,527 @@ +--- +layout: post +title: "Writing Tidy Code" +date: 2017-05-10 12:45:56 +categories: Web Development +meta: "Even the most inexperienced developers can write great looking code" +--- + +My friend [Tom](https://twitter.com/TomNomNom) recently gave an excellent talk +titled [_Writing Readable Code_](https://www.youtube.com/watch?v=OVf0xP4BLq0). +It’s only 15 minutes long, and is packed full of great little tips and pearls of +wisdom. I’d highly recommend watching it. + +After viewing Tom’s talk (three times now) I decided to jot down some of my own +thoughts about what I find not necessarily _readable_ code, but neat and tidy +code. + +- - - + +I spend a _lot_ of time reading [other peoples’ code](/code-reviews/), and +honestly, most of us could do better. Something I urge everyone to bear in mind +is that **pride in your work is something that transcends all skills levels**. + +One thing that the best developer in the world and the newest developer in the +world both have in common is that either can be just as neat and tidy as the +other: tidiness is divorced from skill or quality, and that’s some good news. + +Pride in your work speaks for a lot, and leaving clean and tidy code behind you, +among other things: + +1. gets you in the correct frame of mind for valuing quality, and; +2. sets the bar nice and high for the rest of your colleagues. + +It seems like a very superficial thing to worry about, but to my mind, tidy code +signals something more important: I would assume that a tidy developer has +better attention to detail, is more likely to follow process, and is more likely +to spot mistakes. Rightly or wrongly, I see it as a litmus test for more general +approaches and attitudes. + +## What Is Tidy Code? + +Naturally this is very subjective, but to my mind tidy code is code +that—separately to its function—is well documented, formatted, and presented. +It’s more about cosmetics than it is about quality. So I guess herein lies +a warning: **bad code can still look tidy!** + +This means that one could conceivably write code littered with IDs and ridden +with `!important`s and it could still look pleasing. The alternative title for +this article is _Making Bad Code Look Good_. You have been warned. + +## Whitespace + +I cannot stress this enough: whitespace is free—use as much as you like! + +Nothing feels more untidy, cramped, and claustrophobic than opening a file with +a complete lack of whitespace: + +``` +.c-btn { + display: inline-block; + vertical-align: middle; + text-decoration: none; + text-align: center; + background-color: #C0FFEE; + padding: 0.5em 1em; + &:hover, + &:focus { + background-color: #BADA55; + } +} +.c-btn--secondary { + background-color: #BADA55; + &:hover, + &:focus { + background-color: #C0FFEE; + } +} +.c-btn--tertiary { + background-color: #DE1E7E; + &:hover, + &:focus { + background-color: #C0DEC5; + } +} +.c-btn--small { + padding: 0.25em 0.5em; +} +.c-btn--large { + padding: 1em 2em; +} +``` + +I mean, that just looks plain _wrong_, no? + +When we scan text, we do so in _saccades_, which +are _rapid movements of the eye between fixation points_. Whitespace creates +these fixations points which help to guide the reader thematically: blank space +between lines tells me that two or more blocks are separate; lack of blank +spaces tells me that all code in a block is related. This helps people to focus +on the smallest or most concentrated area at a time, allowing them to ignore +anything that might not be immediately relevant. + +``` +.c-btn { + display: inline-block; + vertical-align: middle; + text-decoration: none; + text-align: center; + background-color: #C0FFEE; + padding: 0.5em 1em; + + &:hover, + &:focus { + background-color: #BADA55; + } + +} + + + + + +.c-btn--secondary { + background-color: #BADA55; + + &:hover, + &:focus { + background-color: #C0FFEE; + } + +} + +.c-btn--tertiary { + background-color: #DE1E7E; + + &:hover, + &:focus { + background-color: #C0DEC5; + } + +} + + + + + +.c-btn--small { + padding: 0.25em 0.5em; +} + +.c-btn--large { + padding: 1em 2em; +} +``` + +Immediately—even without syntax highlighting—that is instantly more readable, +more parsable. At a glance I get a rough idea of the chunking of the code; +I know that some pieces are closely related, and others less related, to the +rest. The size of the gaps in the code are proprtional to the relation. + +Let your code breathe. + +### Whitespace Can Be Semantic + +As well as being useful for glancing at files, whitespace can also provide +actual meaning. When I talk about semantic whitespace, I’m not necessarily +talking about whitespace sensitive languages (like Sass or Python or Haskell), +but about manipulation within a text editor or regular expression. + +In my text editor, Vim, whitespace is actually meaningful—I can use empty lines +to navigate, delete, move, or otherwise manipulate code. In Vim, hitting `{` +will jump my cursor to the previous empty line, and `}` will jump me to the +next. This means that I can jump around blocks of code just by using these keys. + +But it gets better: I can combine the brace keys with other useful options and +begin to manipulate code by the block: + +* `d{}}}p`: Delete the block of code above my cursor, jump three blocks down the + file, paste the block back in. +* `>}`: Indent the block below my cursor by one level. +* `gU{`: Convert the block above the cursor to uppercase. + +

+Gif showing the `{`, `}` command in Vim. [View full size (3.0MB)](/wp-content/uploads/2017/05/screencast-vim-brace.gif). +

+ +For anyone whose editors have similar capabilities, whitespace isn’t just useful +for scanning documents, but fundamental to the way we manipulate and edit them. +A lack of whitespace is crippling, really giving productivity a huge knock. + +## Comments + +To my mind, comments provide two key functions: + +1. They signal the intent of a piece of code, or an entire file, acting more + like waymarkers and context. +2. They document intricacies and oddities in specific pieces of code. + +``` +/* ========================================================================== + #BUTTONS + ========================================================================== */ + +/** + * Buttons can be applied to any HTML element that is used to trigger a user + * action (e.g. following a call to action link, submitting a form). + * + * 1. Line differently sized buttons up a little nicer. + */ + +.c-btn { + display: inline-block; + vertical-align: middle; /* [1] */ + text-decoration: none; + text-align: center; + background-color: #C0FFEE; + padding: 0.5em 1em; + + &:hover, + &:focus { + background-color: #BADA55; + } + +} + + + + + +/* Style variants + ========================================================================== */ + +.c-btn--secondary { + background-color: #BADA55; + + &:hover, + &:focus { + background-color: #C0FFEE; + } + +} + +.c-btn--tertiary { + background-color: #DE1E7E; + + &:hover, + &:focus { + background-color: #C0DEC5; + } + +} + + + + + +/* Size variants + ========================================================================== */ + +.c-btn--small { + padding: 0.25em 0.5em; +} + +.c-btn--large { + padding: 1em 2em; +} +``` + +The main comment at the top acts as a title, and is prefixed with a hash (`#`) +so that I can very easily grep for specific pieces of code (useful when looking +through compiled stylesheets). It grounds the file and introduces its intent. + +Subsequent comments guide me around the sub-components of the file, or provide +more granular details about the code itself. + +Write more comments. + +## Invisibles + +Tabs vs. spaces: it doesn’t matter which you use (as long as it’s spaces…) but +what does matter is that you’re consistent. If you don’t have invisibles turned +on in your editor then stop reading this post _right now_ and go and enable +them. If you’re not sure how to enable them, click [this +link](https://www.google.com/search?q=turn+on+invisibles+[EDITOR]). If you use +Vim: + +``` +" Show invisibles +set list +set listchars=tab:»-,trail:·,eol:¬ +``` + +Once you’ve turned invisibles on, your text might go from looking like this: + +``` +.c-banner { + display: block; + padding: 1em; + margin-bottom: 1em; + background-color: hotpink; +} +``` + +…to looking something like this: + +``` +.c-banner {¬ + display: block;¬ +»-padding:»-»-»- 1em;¬ +»-margin-bottom: 1em;···¬ + background-color: hotpink;¬ +}·¬ +``` + +Ewww! What’s all that? Was that there the whole time? + +Yes, it was. + +By turning on invisibles, we’ve immediately seen what a hidden mess our code +was—mixtures of tabs and spaces, and a bunch of trailing spaces. + +So many times I have opened a file that superficially seems tidy only to find +that it’s a real mess of poor and inconsistent formatting. Turn on invisibles +and ensure that you’re not leaving a total mess in your wake. + +## Automation + +One thing that I really believe is that we should make it easy for people to +follow our rules: I want them to have as few barriers as possible preventing +them from doing the right thing. + +### EditorConfig + +Everyone has their own preferences, but a project should have its own consistent +code style, and that may well differ from yours. This kinda sucks, but it’s just +one of those things. + +However, it does leave us with a bit of a dilemma: + +1. Do we change our coding style to match that of the project? What happens when + we move to another project that is different still? +2. Do we update our text editor’s settings every time we move from one project + to the next? I don’t think any of us are that conscientious. + +So it’s quite likely that people are not going to adapt to a different but +consistent coding style very readily. We need to automate it. + +[EditorConfig](http://editorconfig.org/) is a project designed to help… + +> …developers define and maintain consistent coding styles between different +> editors and IDEs. + +It takes the form of a small dotfile, `.editorconfig`, that lives in the root of +your project and defines simple rules for specific and/or all types of text file +you might edit. Two spaces by default, but four for Python? Easy. Delete all +trailing whitespace, except in Markdown where it’s meaningful? Done. + +``` +# editorconfig.org +root = true + +[*] +charset = utf-8 +indent_size = 2 +indent_style = space +trim_trailing_whitespace = true + +[*.js] +indent_size = 4 + +[*.py] +indent_size = 4 + +[*.{md,markdown}] +trim_trailing_whitespace = false +``` + +The beauty of this is that you don’t have to manually or consciously change your +own coding style; you just carry on as you ever would and everything is taken +care of for you. + +Your editor probably supports EditorConfig, so you should definitely [check it +out](https://www.google.com/search?q=editorconfig+[EDITOR]). Then define your +team’s style (best of luck) and check your agreed `.editorconfig` into your +project. + +### Git + +Git has a bunch of whitespace related settings that will mark errors with mixed +tabs and spaces in `diff`s. Take a read of the docs: + +``` +$ git --help config +``` + +…and then once in your pager, search for `core.whitespace` by first hitting `/` +(forward slash) to enter search mode, and then typing: + +``` +core\.whitespace +``` + +Taking a look through those settings, you’ll likely be able to enforce some +rules specific to your project, for example: + +``` +$ git config core.whitespace tab-in-indent +``` + +…will mark lines starting with tabs as being errors. + +Read more [in the +documentation](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#__code_core_whitespace_code). + +### Templates + +Something I’ve implemented with a few clients now is the idea of a template +which they use to pre-populate all new files with. The template can contain +exactly as much or as little as you like, and should be used to get developers +started with a file containing the correct formatting and layout for them to +build upon. + +I set up a template file for [inuitcss](https://github.com/inuitcss/)’ +[maintainers](https://github.com/orgs/inuitcss/teams/core) to use so that they +could very easily follow the code style we laid out. That [template +file](https://github.com/inuitcss/template/blob/master/_layer.file.scss) looks +like this: + +``` +/* ========================================================================== + #TITLE + ========================================================================== */ + +/** + * Long-form comment. + * + * This spans multiple lines and is also constrained to no longer than 80 + * characters in width. + * + * 1. Provide line-comments like this. + */ + +.X-class { + color: red; /* [1] */ +} + + + + + +/* Sub-title + ========================================================================== */ +``` + +Right out of the box we get: + +1. Titling rules +2. Sub-titling rules +3. 80th column markers (ends of the `=== */` lines) +4. Spacing rules +5. Doc-block comment style +6. Line-comment style +7. Class-namespacing rules + +If we want to do things relatively long-hand, developers can simply duplicate +this file and rename it on the filesystem, but that feels a little cumbersome… +Because this file lives in [its own GitHub +repository](https://github.com/inuitcss/template), it is accessible at an HTTP +endpoint. This means it’s `curl`able: from right there on the CLI, a developer +can run [the following +command](https://explainshell.com/explain?cmd=curl+-L+git.io%2Finuitcssnew+-o+_layer.file.scss): + +``` +$ curl -L git.io/inuitcssnew -o _layer.file.scss +``` + +…which will create a brand new, on-spec inuitcss file called `_layer.file.scss` +on their machine. + +**N.B.** I’m using [GitHub’s own URL +shortener](https://github.com/blog/985-git-io-github-url-shortener) to have +a nice short URL as opposed to something more verbose. + +If we don’t want to save the file to disk immediately, or we’d rather just get +to work right away, we can pipe the curl output straight into our text editor: + +``` +$ curl -L git.io/inuitcssnew | vim - +``` + +**N.B.** Passing the `-` flag to Vim opens it with the contents of STDIN. + +Or—another bonus for the Vim users—we can open a totally blank file that does +not yet exist: + +``` +$ vim _components.buttons.scss +``` + +…and then use the `read` command to read the contents or a local template file +into the current, empty buffer: + +``` +:read ../path/to/_template.scss +``` + +You can see [a GIF of +that](https://twitter.com/vimgifs/status/842015277235769348) in action. + +## Closing + +As superficial at it may seem, writing neat and tidy code can be a very valuable +exercise, and I don’t think I can overstate this enough: no matter your +experience or skill level, you can all write neat and tidy code. + +* **Use as much whitespace as you like** to open your code up and let it + breathe. It’s scannable and often meaningful. +* **Use more comments** to help people navigate your files. It’s difficult to + write too many comments, so just go for it. +* **Turn on invisibles** and make sure you’re not accidentally leaving behind + a tangled mess. You might be surprised just how messy your project is. +* **Automate** things to make it as easy as possible for people to do the right + thing. Configure your editor and your VCS to fix and/or detect issues; use + templates to provide your team with a solid starting point. diff --git a/_posts/2017-05-23-little-things-i-like-to-do-with-git.md b/_posts/2017-05-23-little-things-i-like-to-do-with-git.md new file mode 100644 index 00000000..13642b71 --- /dev/null +++ b/_posts/2017-05-23-little-things-i-like-to-do-with-git.md @@ -0,0 +1,349 @@ +--- +layout: post +title: "Little Things I Like to Do with Git" +date: 2017-05-23 14:39:29 +last_modified_at: 2025-06-02 +categories: Web Development +meta: "Handy Git tricks and aliases: leaderboards, praise, word-diff, branch history, daily recaps, changelog generation, and more in one quick guide." +--- + +I was chatting with [Tim](https://twitter.com/tkadlec) just the other day about +how much I love Git—it’s such a powerful, elegant tool and it’s one I use the +most often. I thought I would note down some useful little Git snippets that +I use the most frequently. + +## Leaderboards + +Whether you think gamification or competitiveness in your work is a good or +a bad thing is a different discussion for a different time, but if you’re +interested in seeing who has committed how much to your project, `shortlog` can +give us the answer: + +```bash +$ git shortlog -sn --all --no-merges + 80 Harry Roberts + 34 Samantha Peters + 3 Tom Smith +``` + +The `shortlog` gives us summaries of `git log`; the `-s` flag will suppress +commit description and provide a commit count summary only, and the `-n` +flag will sort output according to the number of commits per author instead +of author alphabetic order. The `--all` flag logs all branches, and +`--no-merges` ensures that merge commits aren’t being counted. + +The above shows all commits for the lifetime of the project, but if you want to +see how much people have done during a specified timeframe, you can use the +`--since` and `--until` flags: + +```bash +$ git shortlog -sn --since='10 weeks' --until='2 weeks' + 59 Harry Roberts + 24 Samantha Peters +``` + +I have this aliased to `$ git stats`. + +## Praise People + +Git has a very useful `blame` feature which allows us to check which developer +was responsible for changing a particular piece of code: + +```bash +# See who last changed lines 5 through 10 of the buttons’ CSS: +$ git blame -L5,10 _components.buttons.scss +``` + +The issue here is the wording. It’s pretty loaded and implies that the developer +we’re looking for did something wrong, and this might not always be the +case—they may have done something particularly clever or impressive and we might +want to find out who we should ask about it (Whoa! I haven’t seen this +feature before—I wonder who did that?!) + +Taking the lead from SVN, I alias `praise` onto `blame`, so I can use either +depending on my context: + +```bash +$ git config --global alias.praise blame +``` + +This now means I can do this: + +```bash +# Find out who implemented Resource Hints and buy them a coffee: +$ git praise -L18,23 _includes/head.html +``` + +Or, for a completely neutral option, we can alias `who` onto `blame`: + +```bash +$ git config --global alias.who blame +``` + +Which, predictably, looks like this: + +```bash +# Find out who wrote great comments: +$ git who -L1,9 module.js +``` + +Small change, but it’s pretty nice. + +## Hide Whitespace Noise + +When you `diff` or `show` an object with a lot of whitespace changes, we’re left +looking at a lot of visual noise which can make it hard to see anything more +important. + +Thankfully, removing this noise is pretty trivial by using the `-w` flag which +can be used alongside `git diff` and `git show`. For example, before: + +```diff + a { + color: $color-links; + +-&:hover { +- color: $color-links-hover; +-} ++ &:hover { ++ color: $color-links-hover; ++ text-decoration: underline; ++ } + +} +``` + +…and after: + +```diff + a { + color: $color-links; + + &:hover { + color: $color-links-hover; ++ text-decoration: underline; + } + +} +``` + +Now it’s easy to see that the only _meaningful_ change was the addition of +`text-decoration: underline;`, and the rest of the diff was somewhat misleading +noise. + +## Show Changed Words Instead of Whole Lines + +When editing prose, as opposed to code, it can often be much more useful to see +changed words rather than whole changed lines; this is particularly helpful when +writing markdown, like I am right now. + +Thankfully, we can show only changes words by using the `--word-diff` flag: + +```bash +$ git diff --word-diff +``` + +Running a diff without the `--word-diff` flag shows quite a large difference: + +```diff +-My friend Tom recently gave an excellent talk ++My good friend Tom gave an excellent talk +``` + +…but rerunning the diff with `--word-diff` enabled gives us a much more +digestible and helpful overview: + +```diff +My {+good+} friend Tom [-recently-] gave an excellent talk +``` + +Note how only the changed text is highlighted (within `{+ +}` and `[- -]`). + +## See Which Branches You Recently Worked On + +It’s not uncommon for me to jump between lots of different branches on any given +project, and keeping track of them can be pretty tricky. We can get Git to help +us work this out: + +```bash +$ git for-each-ref --count=10 --sort=-committerdate refs/heads/ --format="%(refname:short)" +``` + +This will show us the last 10 (`--count=10`) branches that we worked on, sorted +by the time that we were last working there. It only shows us local branches +(`refs/heads/`) and in a much nicer `--format`. + +This is a bit verbose to commit to memory, so I have it aliased to `$ git +recent`. + +## See What Everyone’s Been Getting Up To + +Sometimes—especially for team leads—it’s useful to get a general idea of what +everyone has been getting up to across all branches. Once again, Git makes that +really easy for us: + +```bash +$ git log --all --oneline --no-merges +``` + +This will give us a simplified log of everybody’s work across `--all` branches +(with `--no-merges`). + +We can also limit the number of commits we return by complementing the command +with a `--since`: + +```bash +$ git log --all --since='2 weeks' --oneline --no-merges +``` + +Now we can see what everyone did in the last two weeks (since the start of the +sprint, for example). + +I have this aliased to `$ git overview` + +## Remind Yourself What You’ve Been Up To + +You move back onto an old project, or come back to the office after a prolonged +break, and you’re not sure what the last things you worked on are—it happens. We +can ask Git to give us a quick recap of our work on a project quite easily: + +```bash +$ git log --all --oneline --no-merges --author= +``` + +This is really, really similar to the above, only we’re limiting the log only to +our own commits. We can also augment it with `--since` limits. + +I have this aliased to `$ git recap`. + +## Today’s Work + +Again, I’m not here to discuss how developers’ productivity should be measured, +but I frequently find it useful (mandatory, even) to let my clients know what +I’ve been up to on any given day. Rather than keeping a detailed list of tasks +that I’ve completed, I can just ask Git to pull up all of that information for +me: + +```bash +$ git log --since='midnight' --all --no-merges --oneline --author= +``` + +This will `log` `--all` branches showing you the work that the specified +`--author` has done `--since` midnight that day (but `--no-merges`), and present +a simplified `--oneline` overview. + +I have this aliased to `$ git today`. + +### Yesterday’s Work + +Similarly, if you want to remind yourself of yesterday’s work—in advance of your +standup, for example—we have: + +```bash +$ git log --since='yesterday.midnight' --until='midnight' --all --no-merges --oneline --author= +``` + +This, predictably, is aliased to `$ git yesterday`. + +## Generate a Changelog + +Writing a CHANGELOG can be a little tedious; we have to look over all of the +work we’ve done since our last release and then pull out all of the useful bits. +Thankfully we can use Git to give us a head start: + +```bash +$ git log --oneline --no-merges ..HEAD +``` + +**N.B.** `HEAD` is optional here—if you omit it (i.e. `... --no-merges ..`) then `HEAD` is implied. That saves you a couple of keystrokes. + +This will create a simplified log showing all commits (excluding merge commits) +that took place between your last release and `HEAD`. + +For example: + +```bash +$ git log --oneline --no-merges 1.0.0.. +1257b95 [refs #00019] Bump version +2b9b28e [refs #00019] Add auto width class +17b8eb1 [refs #00015] Tidy up README.md +bbe7d05 [refs #00012] Rename Supercell main mixin +``` + +This tells me that since my last release (`1.0.0`) and the current state of my +project (`HEAD`), I’ve done these bits of work. That’s quite a nice basis for +a CHANGELOG. + +**N.B.** You’re not limited to just tags: you can use commit hashes. + +## Check Which Changes You’re About to Pull + +If you haven’t worked on a project for a little while, you might want to check +what’s happened upstream before you pull all of those changes down into your +local branch. + +```bash +$ git log --oneline --no-merges HEAD../ +``` + +**N.B.** Again, `HEAD` is optional here, and omitting it will leave it implied. + +For example, let’s see what someone has been doing in a particular feature +branch whilst you were on holiday: + +```bash +$ git checkout feature/fonts +$ git fetch +$ git log --oneline --no-merges ..origin/feature/fonts +``` + +I have this aliased to `$ git upstream`. + +## Review What You’re About to Push + +Hopefully you commit and push often, but if—for whatever reason—you find +yourself with a large amount of local commits that are yet to be pushed, it’s +probably wise to quickly review what they all are. + +In order to do this, we’re effectively just inverting the previous command: + +```bash +$ git log --oneline --no-merges /..HEAD +``` + +For example: + +```bash +$ git fetch +$ git log --oneline --no-merges origin/feature/fonts..HEAD +``` + +**N.B.** Again, `HEAD` is optional here, and omitting it will leave it implied. + +This logs the commits that `/` needs before it resembles `HEAD`. + +I have this aliased to `$ git local`. + +## View Complex Logs + +Pretty much every example above uses simplified logs because I just want to get +a quick idea of what’s going on. For more forensic details I use a `--graph` log +with some extra options: + +```bash +$ git log --graph --all --decorate --stat --date=iso +``` + +This will give me `--graph`-based logs for `--all` branches showing commit +`--stat`s (additions, deletions). `--decorate` will give me information about +which branch a commit was made on where applicable, and I also get a much +stricter date format. + +I have this aliased to `$ git graph`. + +## And you…? + +I’m sure you’ve all got loads of your own tips and trick: share them on this +post’s [GitHub +issue](https://github.com/csswizardry/csswizardry.github.com/issues/66). diff --git a/_posts/2017-06-02-refactoring-tunnels.md b/_posts/2017-06-02-refactoring-tunnels.md new file mode 100644 index 00000000..c3492d4b --- /dev/null +++ b/_posts/2017-06-02-refactoring-tunnels.md @@ -0,0 +1,162 @@ +--- +layout: post +title: "Refactoring Tunnels" +date: 2017-06-02 12:19:58 +categories: Web Development +toc: false +meta: "A metaphor for defining the scope of refactoring tasks" +main: "/wp-content/uploads/2017/06/tunnel.jpg" +--- + +In my work, I tend to get involved in a lot of refactoring projects. From +small-scale tweaks of work-in-progress frameworks or styleguides, right through +to full-scale refactors of years-old legacy projects. In fact, I do so much work +with clients who need to refactor that I spent [much of 2016 speaking about +it](https://speakerdeck.com/csswizardry/refactoring-css-without-losing-your-mind). + +There are many interesting things about refactoring—from technical to +logistical to cultural—but two points that are most relevant to this article +are: + +1. **The business is almost always hesitant to fund refactoring work**. Nearly + every development team I have ever spoken to has told me that their manager + or client is the main reason they do not get to refactor as often as they + would like to. This is understandable: the cost of moving developers away + from product work to rewrite code with no discernible benefit to the user[^1] + is a cost that most managers would rather not incur. +2. **Refactoring can be scary.** On a sufficiently large or legacy application, + there can be so much fundamentally wrong with the codebase that many + refactoring tasks will run very deep throughout the whole project. This puts + a lot of pressure on developers, especially considering that this is their + chance to get it right this time. This can feel debilitating: Where + do I start? How long is this going to take? How will I know if + I’m doing the right thing? + +A concept I came up with to help my clients and their teams tackle these two +problems was the idea of a _Refactoring Tunnel_. + +

+ +A Refactoring Tunnel is a metaphor in which the length or size of the +refactoring task is represented by a tunnel of a corresponding size: long +tunnels represent large refactoring tasks; short tunnels represent small ones. + +A more developer oriented way of looking at or defining the size of +a refactoring task might be to describe its surface area: how much of the +codebase does the body of work touch? + +The Refactoring Tunnel metaphor works like this: + +- - - + +On day one, you pick your refactoring task: you step into the tunnel. At this +point, you can see the light at the tunnel’s entrance behind you, but you can’t +see the light at the exit—perhaps it’s close but around a sharp bend, or maybe +it is just that far away. At this point, we don’t know, but it doesn’t concern +us because we have only just started. + +Day two: we continue working on our refactoring task, and proceed further into +the tunnel. Just like yesterday, we can still see the light at the entrance +behind us, but the light at the exit still evades us. That is to say, we have +a good idea of where we’ve come from, but still don’t know how far away the exit +is: is it another week? Two weeks? Three days? + +We press on, day after day making our way further into the tunnel, until day +nine. All of a sudden, the light behind us has disappeared. We know we did nine +days of work, but we’ve now lost the security of being able to see a fixed point +behind us. + +To compound the problem, we still can’t see the light at the exit either. The +panic sets in; we’re lost. The site is broken around our feet. The quick +find-and-replace for the class names didn’t work as we’d hoped, and now some +JavaScript has stopped working. Many of our tests are failing, but we’re not +sure why. We’ve tried to keep merging `master` into our topic branch, but we see +more and more merge conflicts. And we still have no idea where the exit is. Is +it quite close? Would it be worth continuing another day or so? Or is it still +many days—or even weeks—away from us? We have no way of knowing. The uncertainty +is stressful; it is a gamble. We begin to wish we’d never started, and in total +desperation, we do this: + +```bash +$ git reset --hard origin/master +``` + +We just throw everything away. We hard reset ourselves to a point in time we +knew to be safe—and we do begin to feel safer again—but we have to face up to +the fact that we just spent nine days of time and money getting to precisely +nowhere. That’s going to be a difficult one to explain at your stand up, and +will likely reduce the chances of the business trusting developers with +refactoring time in future. + +I’ve done this, and seen it done, more times than I would care to remember (or +admit). I’m sure you’ve done it at some point as well. This is the danger of +entering long Refactoring Tunnels. + +- - - + +Tasks with a large surface area—and thus, a long tunnel—might be things like + +* rewriting all of your Sass as PostCSS; +* renaming all of your classes from BEM to BEM(IT), or; +* moving your entire project’s layout from floats to Grid. + +While each of these may be worthy and worthwhile changes to make, they’re +relatively large. They will affect and modify the entire project’s codebase, +which means a few things: + +1. **It will take a lot of time to implement and test.** Even if you get it + right first time, it’s a significant spend that you will have to be able to + justify. +2. **The likelihood of introducing new bugs and regressions increases.** It + stands to reason that if you’re impacting large and far-reaching parts of + your codebase, you are far more likely to introduce new or + different faults along the way inadvertently. +3. **The chance of pesky merge conflicts goes up.** As oddly-specific as it + might seem, this is a real issue. Diverging from your colleagues’ codebases + on such a massive scale means you’re going to run into workflow issues. +4. **It may well become overwhelming. Scary, even.** The most drastic outcome is + that you realise you’ve bitten off more than you can chew and you have to + bail out completely. + +**Don’t enter a tunnel whose end you can’t see, or that you can’t exit from +quickly and cheaply.** + +## Short Refactoring Tunnels + +Resist the temptation to refactor anything that runs right the way throughout +the project. Instead, identify smaller and more manageable tasks: tasks that +have a much smaller surface area, and therefore a much shorter Refactoring +Tunnel. + +These tasks can still aim toward a larger and more total goal but can be +realised in much safer and shorter timeframes. Want to move all of your +classes from BEM to BEM(IT)? Sure, but maybe just implement it on the nav first. +Attacking the problem this way has many benefits: + +1. **You’re minimising your liabilities.** The maximum risk at any given time is + significantly reduced. Even in the worst case scenario, we only need to abort + a much smaller piece of work. +2. **The shorter tunnel can be used as a test-bed for larger bodies of work.** + This will help you work out projected overall cost based on a smaller sample. + It will allow you to stress-test certain new techniques, methodologies, or + approaches in a smaller sandbox. The upshot of this is that the overall + refactoring project can be defined based on a more trivial task up front. +3. **You can move back onto product work much sooner.** This keeps managers + happy—the fact that you’re only out of action for a few days, rather than + many weeks, at a time is a hugely attractive proposition and is more likely + to get approval than the alternative. +4. **It’s a chance to encapsulate.** By working in these smaller units, it + becomes almost necessary to begin defensively encapsulating code as you + refactor it. This means that your codebase will gradually become more robust + as a result, which will help with almost all future work. + +Your overall goals for the project can remain the same but try to [identify and +isolate](/2016/08/refactoring-css-the-three-i-s/) the +sub-tasks into much smaller and safer units. Make sure you only ever step into +short tunnels. + +- - - + +[^1]: I firmly believe that the user will ultimately benefit from a refactored codebase, but in ways that are hard to actually measure. diff --git a/_posts/2017-07-31-performance-and-resilience-stress-testing-third-parties.md b/_posts/2017-07-31-performance-and-resilience-stress-testing-third-parties.md new file mode 100644 index 00000000..163060de --- /dev/null +++ b/_posts/2017-07-31-performance-and-resilience-stress-testing-third-parties.md @@ -0,0 +1,213 @@ +--- +layout: post +title: "Performance and Resilience: Stress-Testing Third Parties" +date: 2017-07-31 16:10:13 +categories: Web Development +meta: "Assessing the fragility and resilience of third party resources" +--- + +When building almost any website of any reasonable size, we’re highly likely to +need to call on at least some third party resources: analytics, fonts, CDNs, ad +providers, to name just a few. + +Unfortunately, this puts a lot of your ability to be fast in someone else’s +hands, and the vast majority of performance slowdowns I encounter in my work +are, indeed, caused by external resources that we have little-to-no control +over. These issues could range from network issues on a CDN leading to slower +delivery of assets, to external JavaScript using older APIs like +`document.write()`; from third parties not properly compressing or caching their +resources, to ad networks not optimising their images; from third party +resources living on the Critical Path, to any combination of the above. + +The solutions to the above problems will range from trivial to non-existent and +will depend a lot on the third party in question, and on your own context. That +means that, in this post, I can’t necessarily discuss how to _fix_ these issues, +but I will show you a few tools you can use to identify and triage them and +learn just how susceptible you might be. + +## Bottom-Up Summaries + +Rightly or wrongly, a lot of performance optimisation is about playing something +of a blame game: what, or _who_, is making us slow? One of my favourite ways of +quickly working this out is to make use of DevTools’ _Bottom-Up_ summary of +runtime performance. + +After you’ve run a Performance profile over your page, you should see a pane +with a tab reading _Bottom-Up_. Head over to this view, and select _Group +by Domain_ from the available dropdown. Amazing! Now we can see exactly where +our overhead is coming from: + +

DevTool’s Bottom-Up feature. View full +size/quality (50KB).

+ +Above, we can see how `twitter.com` contributes a third of the work that happens +when loading a page on my website. Using this knowledge, we can more accurately +pinpoint problem areas, and begin investigating with a bit of evidence behind +us. We can then take that knowledge, and use it with the following… + +## Request Blocking + +As of [Chrome +59](https://developers.google.com/web/updates/2017/04/devtools-release-notes#block-requests) +(and long before that if you have Experiments enabled), we have the option to +prevent requests for specific asset URLs—or even assets on entire domains—from +going out. Whilst this doesn’t necessarily simulate any realistic network +conditions (the key thing to note with this feature is that it blocks outgoing +requests; it does not hit the network at all), it is a great way of seeing what +the absence of a particular asset would have on the current page. + +

The option to block requests from specific domains in DevTools. View +full size/quality (78KB).

+ +In DevTools’ Network panel, after you’ve run a waterfall chart, you’re now able +to to right-click an individual asset and mark it for blocking: you can either +block outgoing requests for a single file, or for all files from an entire +domain. + +### Use Cases + +I usually use this feature when I’m running performance audits: when +I’m profiling a live website, I might get a hunch that a certain third party is +causing slowdowns. Previously, in order to verify this, you’d have to remove the +third party asset from the source code, roll a new release to a staging +environment, and re-run your tests with the asset removed so as to measure your +before and afters. + +Now, however, you can simply wonder Hmm… I think this particular third party +tag manager is causing us some problems; let me quickly disable it and see what +happens. In fact, I did exactly this in front of a client only last week to +find that one particular third party JS file was contributing around half +a second of slowdown. + +In short, this feature is fantastic for profiling live sites and seeing exactly +what happens when we remove third party assets from the page load. + +## Charles Proxy + +[Charles](https://www.charlesproxy.com/) is a great little Swiss Army knife of +a tool that I use quite frequently. It allows us to proxy HTTP traffic, +observing exchanges between our machine and the network. The bit we’re most +interested in right now, though, is its throttling feature. Charles’ throttling +capabilities are twofold: + +1. Firstly, we can throttle our entire connection, simulating a poor network. + This is perfect for testing performance with empathy, using a forcibly worse + connection, and it a little more forensic than the similar feature found in + Chrome’s DevTools. +2. Secondly, and more pertinent to this article, is its ability only to throttle + specific hosts. + +

Charles Proxy’s throttling settings. View +full size/quality (103KB).

+ +Add a domain to the list, choose or configure a network condition, and begin +artificially slowing down traffic only from a specified host. + +### Use Cases + +It’s hopefully fairly self-explanatory, but this is a great way of assessing +what would happen if you weren’t necessarily on a slow connection, but if one of +your third parties was suffering a slowdown for whatever reason. What happens if +Google Fonts is having issues? What happens if Typekit gets DDoSed? Simulating +slowdowns on specific third parties is a good way to see how vulnerable we are. + +## Blackhole Servers + +The most extreme of scenarios: what happens if a third party has a complete +outage? As rare as this may be, it’s prudent to at least know how your site will +respond in the case that a third party you use goes completely offline. Best +case scenario, you fail gracefully with minimal disruption; worst case scenario, +you go down with it. + +A blackhole server can be used to route third party traffic through an endpoint +that effectively makes requests disappear, recreating the effects of a complete +outage (only for yourself, not the entire internet). +[WebPagetest](https://www.webpagetest.org/) have made a blackhole server +available at `72.66.115.13`. We can point specific domains at this IP address in +our `hosts` file, e.g.: + +``` +72.66.115.13 platform.twitter.com +72.66.115.13 connect.facebook.net +72.66.115.13 fonts.googleapis.com +72.66.115.13 assets.adobedtm.com +72.66.115.13 fast.fonts.net +``` + +Now—if you’ve cleared your browser’s and machine’s DNS cache—you should find +that all requests to assets on those domains will eventually time out. This is +where we begin to see interesting, and often much more severe, results. + +Let’s say you have a render-blocking asset hosted on an external domain, for +example: + +* A `script` that doesn’t have an `async` or `defer` attribute, such as Adobe + Tag Manager, or; +* A CSS file, such as Google Fonts. + +Because these types of assets block rendering, the browser will not paint +anything to the screen until they have been downloaded (and executed/parsed). If +the service that provides the file is offline, then that’s a lot of time that +the browser has to spend _trying_ to access the file, and during that period the +user is left potentially looking at a blank screen. After a certain period has +elapsed, the browser will eventually timeout and display the page without the +asset(s) in question. How long is that certain period of time? + +It’s **1 minute and 20 seconds.** + +If you have any render-blocking, critical, third party assets hosted on an +external domain, you run the risk of showing users a blank page for 1.3 minutes. + +Below, you’ll see the `DOMContentLoaded` and `Load` events on a site that has +a render-blocking script hosted elsewhere. The browser was completely held up +for 78 seconds, showing nothing at all until it ended up timing out. + +

A 1.3 minute `DOMContentLoaded` and `Load` +event when Adobe Tag Manager is offline. View full +size/quality (375KB).

+ +It’s very important to point out that **this isn’t necessarily the third party’s +fault**. The behaviour outlined above is expected: it’s how web pages and +browsers work. What we’re doing here is not apportioning blame, but learning +about how resilient _we_ are if one of our third parties goes down. + +Oftentimes, we don’t consider the implications or ramifications of such +scenarios, and we rarely realise just how severe the outcomes can be. I would +wholeheartedly recommend identifying and then testing any critical third parties +you have hosted on external domains. + +In the case of something like a Google Fonts CSS file, we should be using a more +robust and failsafe font-loading technique; in the case of JavaScript, we should +try utilising `async` or `defer` if possible. + +- - - + +Like it or not, third party providers are a necessary evil in almost all +development projects, and if we’re going to entrust parts of our site or product +to others, we ought to have a very good idea of what happens when things go +wrong. Stress-testing third parties is a standard part of any of the bits of +performance work I undertake, because the ramifications can be huge. And again, +this isn’t us blaming the providers: it’s finding out how well we handle +failures. + +## Update, 2017-09-14 + +[Ryan Townsend](https://twitter.com/RyanTownsend) wrote something of a follow-up +post, [How 3rd Party Scripts can be performant citizens on the +web](https://www.twnsnd.com/posts/performant_third_party_scripts.html). diff --git a/_posts/2017-10-30-airplanes-and-ashtrays.md b/_posts/2017-10-30-airplanes-and-ashtrays.md new file mode 100644 index 00000000..99e1e3c6 --- /dev/null +++ b/_posts/2017-10-30-airplanes-and-ashtrays.md @@ -0,0 +1,83 @@ +--- +layout: post +title: "Airplanes and Ashtrays" +date: 2017-10-30 12:53:49 +categories: Web Development +toc: false +meta: "Sometimes you need to make it possible to do the wrong thing…" +--- + +On 11 July 1973, 123 passengers lost their lives when their Varig 820 flight +from Rio de Janeiro to Paris crashed due to a fire on board[^1]. Only 11 +passengers survived. The fire started when a cigarette was disposed of in the +waste bin in the lavatory, where someone had gone for a secretive smoke. + +Inflight smoking has been almost universally banned on all commercial airlines +for the best part of two decades now. Still, in 2017, all planes are fitted with +ashtrays. Even brand new aircraft, built long after the ban was enforced, always +provide ashtrays for their passengers. Why? + +The answer is relatively straightforward: despite smoking on an airplane being +illegal, someone will, inevitably, break the rules. When this happens, we at +least want them to be able to dispose of the cigarette safely, thus avoiding +another Varig Flight 820 tragedy. We absolutely do not want people to smoke on +board, but if they do, then we need to handle the fallout from it in the +safest way possible. + +For me, the ashtray is a symbol of pragmatism. Of course we don’t want people to +smoke—we tell them not to!—but we have to accept that, at some point, they will. +This acceptance then paves the way for a more pragmatic compromise in which we +don’t have the perfect world that we want, but we also don’t have a disaster on +our hands. Nobody wins, but nobody loses. + +This is an analogy I use with almost all of my consultancy clients. The idea of +actively discouraging something, but still being able to cope with it when it +does inevitably happen. + +With the best of intentions, a lot of teams I work with design frameworks and +systems in such a way that bad practices are entirely forbidden, and are made +impossible to implement[^2]. The thinking here is that by being very strict and +forceful about what we allow and disallow, we’ll maintain a high quality of work +and nothing will (or can) go wrong. + +However, while the theory is nice, ten years of being a developer has taught me +that, sometimes, doing the wrong thing is the right thing to do. Making it +impossible to do something specific can often mean that people will do something +far more destructive as their ways around your defences get more and more +creative. This usually leaves teams in a worse position than if they’d just +allowed the thing they were scared of to happen in the first place. + +But it can get even worse: making something impossible can often lead to +complete abandonment. When a team cannot bend the rules of your system or +framework, they’ll often opt to simply not use it at all. This is a net loss, +whereas allowing them to do the wrong thing would have at least led to greater +adoption, more consistency, and less repetition. + +Whenever you plan or design a system, you need to build in your own ashtrays—a +codified way of dealing with the inevitability of somebody doing the wrong +thing. Think of what your ideal scenario is—how do you want people to use +whatever you’re building—and then try to identify any aspects of it which may be +overly opinionated, prescriptive, or restrictive. Then try to preempt how people +might try to avoid or circumvent these rules, and work back from there until you +can design a safe middle-ground into your framework that can accept these +deviations in the safest, least destructive way possible. + +The quickest example I can bring to mind is my own +[Shame.css](/2013/04/shame-css/). The idea behind +Shame.css is that we do not want any hacks or nasty CSS in our codebase—of +course we don’t!—but we also have to accept that they are inevitable. Instead of +leaving developers to introduce these hacks throughout the entire codebase, we +set aside a dedicated spot for them. We said, Look, we really don’t want any +hacky code if we can help it, but if we can’t avoid it then please leave it here +where we can easily find it again in future. + +This means that, although far from ideal, the impact of these hacks is well +contained and signposted, meaning that they won’t slip through the cracks and +remain hidden in the codebase for the next five years. + +This pragmatism and lack of stubbornness can make your codebase much more +malleable, resilient, and ultimately much more useful. Everything is +a compromise. + +[^1]: [wikipedia.org/Varig_Flight_820](https://en.wikipedia.org/wiki/Varig_Flight_820) +[^2]: Although not a client of mine, [eBay’s accessibility CSS framework](http://www.ebaytechblog.com/2015/11/04/how-our-css-framework-helps-enforce-accessibility/) is a good example of this. diff --git a/_posts/2017-11-10-relative-requirements.md b/_posts/2017-11-10-relative-requirements.md new file mode 100644 index 00000000..1a348864 --- /dev/null +++ b/_posts/2017-11-10-relative-requirements.md @@ -0,0 +1,261 @@ +--- +layout: post +title: "Relative Requirements" +date: 2017-11-10 18:23:12 +categories: Web Development +meta: "Define the relative importance of project traits in order to make development smoother" +--- + +Every developer and designer is different; they have they own skills, interests, +and abilities. Similarly, every project is different: where one project might +require the utmost focus on performance, the next might have a considerable need +for visually striking designs and interactions. While this variety keeps things +fresh and exciting, there comes a problem when a developer’s skill-set doesn’t +match the requirements of the project, or when teams approach new projects the +same way as the last despite the requirements being fundamentally different. + +This awkward matrix of skills against requirements can often lead to problems: +developers can end up over-engineering simple marketing sites, and designers +begin striving for pixel-perfection on quick-and-dirty internal dashboards that +just don’t need it. This can lead to internal friction and arguments between +team members, but also to excessive cost—spending three days writing the most +extensible and elegant code for a campaign site that will be live for a few days +is almost impossible to justify. + +I tend to, mainly, work with product and app companies; e-commerce, SaaS, etc. +These are companies where longevity and performance are usually paramount, and +my background in these kinds of environments lends itself very well to helping +organisations like these build bigger, faster, and more resilient products. + +As well as companies like these, I also work with more traditional client +services agencies. These companies still suffer the same problems, but in subtly +different ways: they don’t necessarily need the most maintainable or +long-lasting code, but they do need to scale and standardise workflows and +approaches over various projects at the same time. + +Here we have a situation where a developer who’s more inclined to optimise for +scale and speed needs to work in an environment where the actual projects +themselves might need to focus more on visual treatments and engagement, and +much less on architecture and maintainability. This is a prevalent problem +across a lot of companies I work with: how do we get the same development team +to change their approach when the requirements of the project change, +potentially going against their skill-set or even instincts? + +An exercise I came up with a couple of years ago aims to reconcile these issues: +_Relative Requirements_. The aim with Relative Requirements is to take all of +the possible traits a project may have (performance, accessibility, visual +design, etc.) and give them a relative grading against each other. For example, +you may have a project where visual design is paramount, so you assign that four +points. Perhaps, on the same project, performance is less important, so we might +award that just three points. We might never need to use this project again, so +we decide that we should assign zero time and effort to making the code +maintainable: + +| Trait | Score | +|-----------------|------:| +| Performance | 3 | +| Maintainability | 0 | +| Usability | 4 | +| Delighters | 4 | +| Visuals | 4 | +| Accessibility | 3 | + +Once we have all of our traits graded against each other, we can plot them on +a radar chart which shows us, relatively, which aspects of the build might be +more important than the others. + +

+Radar chart showing the relative importance of Performance, Maintainability, +Usability, Delighters, Visuals, and Accessibility, with a weighting toward +a visual-centric project. +

+ +Now, at a glance, anyone can see what the team deem to be the most important +traits for this particular project. + +## Choosing and Grading Your Traits + +The traits I outlined above are merely examples: when you draw up your own +relative requirements you may end up with a few more of a few less, and that’s +fine. The important bit is that the traits are well defined and understood by +everybody involved the process. To quickly define the traits I have used: + +* **Performance:** How important is it that this site is fast? For e-commerce + sites, it’s probably very important. For marketing or campaign sites, perhaps + less so. +* **Maintainability:** Does this codebase need to last a long time? Do we hope + to be adding to it in five years time? +* **Usability:** Is this the kind of site where we expect continued use? + Something like Basecamp or Google Sheets needs to be very usable; a site + promoting a new movie maybe needs to consider this a little less. +* **Delighters:** How important are subtle animations and UI treatments that are + absolutely not vital, but do make users smile? These are nice to have, but + most products can probably survive without them. +* **Visuals:** How important is striking visual design? How important is + pixel-perfection? For [Gov.uk](https://www.gov.uk/), striking visuals are + clearly less important than usability, but if we’re building a site to promote + a luxury hotel, we need to be focusing on lavish design. +* **Accessibility:** Of course, accessibility is always important—we should + always be building accessible sites and applications—but accessibility still + needs to be subjected to the same grading as everything else. + +Feel free to use these traits as-is, or use them as a basis for your own. + +**N.B.** These requirements are _relative_, which means a score of +2 doesn’t mean something is unimportant, it just means it’s _less important_ +than something else. The only way to signify that a trait is truly unimportant +is to give it a zero. + +### Involvement + +My advice here is that you should involve as many people as necessary, but as +few people as possible. It’s vital that key stakeholders and the designers and +developers expected to build the project are present, but inviting too many +people brings the risk of prolonged and dragged out discussions. + +You could even keep this exercise private to the development team, opting not to +involve the client at all. The main idea of Relative Requirements is to get the +team to agree on the importance of certain aspects of the build, so it could be +kept completely private to them. + +### Budgeting + +One clear problem that we could run into is the urge to just Make everything +a 5! Of course, this completely undermines the whole exercise, so I advise +setting up a budget that doesn’t allow this to happen. As a general rule, the +amount of points you can spend is defined by: number of traits × 3. +This means that if we have five traits, we have a total of 15 points to spend. +If we have six traits, our budget is 18 points, and so on. + +The 3 in this equation is derived from the [median +score](/2017/01/choosing-the-correct-average/) that any +trait could have. What this means is that, if we _really_ wanted to, we could +award all of our traits a 3 out of 5, allocating all of our budget equally: + +

+Radar chart showing what would happen if we decided every trait has equal +importance. +

+ +Doing this would also undermine the whole process, but starting from here we +could begin pulling one trait further out, and decide which traits have to move +inward to compensate. + +## Reading the Chart + +Try to arrange your traits in such a way that the resulting shape of the chart +has meaning. You’ll notice that I’ve grouped ‘similar’ traits together, which +means a graph that has a heavy weighting to a specific region indicates +a general theme: a top- to top-right heavy chart shows we might need our more +analytical designers and developers on this project. A bottom- to bottom-left +heavy chart shows us that we might need our more creative designers and +developers. + +

Heavy weighting toward performance and maintainability likely means +you want key architectural developers involved on the project.

+ +

A potential chart for a government service redesign: accessibility +and usability are essential; performance is important, as we have to serve +a large and diverse audience who might not have access to powerful devices and +fast connections; visual design is somewhat important, but not at the cost of +over-designing—we want to focus on a usable design rather than a striking +one.

+ +## Revisiting and Reassessing + +It is important that these Relative Requirement charts don’t become +a set-it-and-forget-it part of your process: they should be revisited and +revised as your project matures. + +For example, you might be embarking on an MVP for a potential product: your +first chart might put a heavy focus on on usability and visuals, medium on +performance, and less so on maintainability (the codebase might get thrown in +the bin if the project is not deemed viable) and delighters (they’re not +appropriate for an MVP). + +

Radar chart showing a theoretical MVP project.

+ +If your MVP proves successful, you’re likely to draw up a new strategy for +development after this point: you’ll no doubt have a lot of [tech +debt](https://24ways.org/2016/we-need-to-talk-about-technical-debt/) to clear, +and your focus will shift from quick proofs of concept to a more permanent +codebase. At this point, you’ll reassess your Relative Requirement and draw up +a new chart. + +

Radar chart showing a change in focus from an MVP to a more +long-lived project.

+ +This change signals a shift in priorities, and now might be a good time to set +your more creative designers and developers on newer projects, and draft in your +more senior or architectural staff to refactor and scale the MVP into a more +sustainable project. Again, a key skill here is to be able to quickly read the +shapes of your charts in order to, at a glance, ascertain what that general form +means. + +## Outcomes + +When implemented effectively, there are a number of advantages and benefits to +this model. + +The first one is that resource coordinators (project managers, scrum masters, +etc.) can quickly see which designers and developers might be best suited to +a particular body of work. Don’t assign your senior architects to a highly +creative marketing campaign; similarly, don’t put your most creative developer +on a long-running SaaS product. You’re unlikely to get the best out of either +person, and they’ll likely resent doing the kind of work they’re least suited +to. + +Another much more useful outcome is conflict resolution. Time and time again +I’ve seen design and development teams in arguments because a front-end +developer hasn’t implemented animations exactly as intended, or a designer is +slowing the process by fighting for pixel-perfection on a project that just +doesn’t require it, or a developer is over engineering some JavaScript in +pursuit of theoretical purity. + +By deciding what we value up-front, we have an agreement that we can look back +on in order to help us settle these conflicts and get us back on track again. If +we’re working on a short-term marketing campaign, another developer could +legitimately call me out if I’ve wasted half a day perfecting the BEM naming +used across the project. + +Relative Requirements remove the personal aspect of these disagreements and +instead focuses on more objective agreements that we made as a team. + +## Amazing Things Can Happen + +I’ll leave you with this: + +I ran this exercise with some designers, developers, and members of the business +at a large UK fashion retailer (if you live in the UK, you’ve heard of them). My +worry was that, as it was a fashion site, we’d be pulling fours and fives on the +visual treatments and dropping performance and accessibility to ones or even +zeroes. Then something remarkable happened: + +> Well, our brand is all about providing affordable and non-nonsense clothing to +> shoppers as quickly and effectively as possible, so if we hit high on +> performance and usability, we’re perfectly on brand. Let’s prioritise those. + +This was a really reassuring moment, and the site continues to be one of the +fastest in the e-commerce space. + +Try it out[^1]. Let me know how you get on. + +[^1]: Here’s [a Google Sheets document](https://docs.google.com/spreadsheets/d/17ZvkR-ycr3HcZxiBvNwJYA_f87fijuB2JNuoNb9xLKA/edit?usp=sharing) to make your own. diff --git a/_posts/2017-11-19-ten-years-old.md b/_posts/2017-11-19-ten-years-old.md new file mode 100644 index 00000000..1600e19d --- /dev/null +++ b/_posts/2017-11-19-ten-years-old.md @@ -0,0 +1,125 @@ +--- +layout: post +title: "Ten Years Old" +date: 2017-11-19 00:00:00 +categories: Business +toc: false +meta: "csswizardry.com turns ten today!" +--- + +Ten years ago today, a seventeen-year old Harry decided to register the domain +[csswizardry.com](). It was such a small and +inconsequential decision at the time: I only bought the domain because +[NuBlue](https://www.nublue.co.uk/), a British hosting firm, was running +a promotional offer in which a .com domain and a year’s hosting was about £39 (I +actually had to use my mother’s credit card, because I wasn’t old enough to have +one of my own). As I clicked that checkout button, little did I know that that +simple purchase would be the defining part of the next decade of my life. + +I chose the name CSS Wizardry because I knew I wanted to start a blog showcasing +CSS tricks and techniques, and I’d also just finished reading +[Andy’s](http://andybudd.com/) [CSS +Mastery](https://www.amazon.co.uk/gp/product/1430223979?ie=UTF8&tag=blogography-21&linkCode=as2&camp=1634&creative=6738&creativeASIN=1430223979) +which is a book that inspired me greatly. I actually loathe the name CSS +Wizardry now, but it’s stuck too well for me to change it: I guess it’s here to +stay. Incidentally, a lot of people think the name choice was making a play on +the whole Harry/wizard thing—it wasn’t. + +Fast forward a decade, and that whimsical purchase has probably been the most +influential decision I ever made. What started off as an overly-confident +teenager’s foray into front-end development ultimately led to my first job, +a speaking career, and a full-time consultancy firm. I struggle to believe it, +sometimes. + +Over the last ten years I’ve been fortunate enough to work for [a number of +companies](https://uk.linkedin.com/in/csswizardry), both large and small, as +a salaried front-end developer; I’ve spoken and workshopped at [over 85 public +events](/speaking/#section:past-events) (and countless +other private ones); I was able to start my own consultancy business through +which I’ve worked with some [truly amazing +clients](/#section:clients); I’ve been able to travel the +world visiting over 35 different countries; I’ve met countless new people and +made many wonderful new friends; I’ve experienced more amazing things than +I feel I deserve. It’s been a phenomenal journey and I’m grateful for it every +single day. Truly, I’m the luckiest person alive. + +As impersonal as it may seem through a blog post, I want to offer sincere thanks +every single person that’s joined me on this journey; no matter how much or how +little, you’ve all played a part. From colleagues, to managers, to bosses, to +clients, to conferences, and everyone in between: thank you. + +But it’s been hard work. A lot of continued hard work. Writing [over 200 +articles](/archive/), releasing [open-source +projects](https://github.com/csswizardry), developing and sharing new +methodologies and techniques, is all just a small part of what’s made this all +possible. Looking back on ten whole years begins to put a lot of it into +perspective. + +Bill Gates once famously said that… + +> [m]ost people overestimate what they can do in one year and underestimate what +> they can do in ten years. + +The CSS Wizardry journey, it turns out, has been a long one. People often ask me +how I got to where I am, and how they can emulate it themselves. They’re often +disheartened to hear that it’s taken me a decade, and to them I typically repeat +a phrase I learned some time ago: + +> The best time to plant a tree was 20 years ago. The second best time is now. + +Having this website changed and shaped my career. If you don’t have a blog, +I urge you, start working on one this weekend. Your own blog, with your own +content, at your own domain. It might just change your life. + +## Facts and Figures + +As CSS Wizardry is, first and foremost, a personal blog, it’s not as highly +trafficked as, say, a site like CSS Tricks might be. That said, here are some +interesting facts and figures[^1] from the last decade: + +* There have been **8,033,982** visitors from **238 countries** who have been + responsible for **14,237,772** pageviews. +* The most highly trafficked single article has been [Creating a pure CSS + dropdown + menu](/2011/02/creating-a-pure-css-dropdown-menu/), + taking 10.17% of the total pageviews. +* The most highly trafficked single day was **25 April 2013** with **34,374** + visitors. **74.25%** of them were reading about + [Shame.css](/2013/04/shame-css/) +* The most highly trafficked year was **2013**, which was when I was writing + with a much higher frequency. +* With **26.36%** of total visitors, **the US is the top location**, followed by + the UK (10.74%), and India (6.66%). +* I had one lonely visitor from **North Korea**. +* The ten **fastest** countries[^2] were: + + | Country | Mean Page Load (sec.) | + |-------------|----------------------:| + | Belize | 0.72 | + | Montenegro | 1.43 | + | Norway | 1.45 | + | Finland | 1.49 | + | Algeria | 1.55 | + | Malta | 1.64 | + | Luxembourg | 1.71 | + | Switzerland | 1.76 | + | Slovenia | 1.81 | + | Hungary | 1.86 | + +* The ten **slowest** countries were: + + | Country | Mean Page Load (sec.) | + |-----------|----------------------:| + | Lesotho | 122.24 | + | Cuba | 104.29 | + | Ecuador | 59.96 | + | Rwanda | 55.08 | + | Nigeria | 44.05 | + | Nepal | 37.81 | + | Ethiopia | 29.71 | + | China | 19.41 | + | Cyprus | 15.08 | + | St. Lucia | 14.71 | + +[^1]: All data is from Google Analytics. +[^2]: Performance data began getting captured on 13 Nov, 2011. diff --git a/_posts/2017-11-21-the-fallacies-of-distributed-computing-applied-to-front-end-performance.md b/_posts/2017-11-21-the-fallacies-of-distributed-computing-applied-to-front-end-performance.md new file mode 100644 index 00000000..a26e5813 --- /dev/null +++ b/_posts/2017-11-21-the-fallacies-of-distributed-computing-applied-to-front-end-performance.md @@ -0,0 +1,146 @@ +--- +layout: post +title: "The Fallacies of Distributed Computing (Applied to Front-End Performance)" +date: 2017-11-21 09:51:11 +categories: Web Development +meta: "What can front-end and performance engineers learn from the Fallacies of Distributed Computing?" +--- + +In the mid-nineties, [Laurence Peter +Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) and colleagues at Sun +Microsystems devised a list of what they called The Fallacies of +Distributed Computing. These were a list of common assumptions that +developers working on distributed systems were prone to making; mistakes that +would impact the reliability, security, or resilience of their software. Those +fallacies are as follows: + +1. The network is reliable. +2. Latency is zero. +3. Bandwidth is infinite. +4. The network is secure. +5. Topology doesn’t change. +6. There is one administrator. +7. Transport cost is zero. +8. The network is homogeneous. + +Interestingly, although Deutsch is given credit for The Fallacies of +Distributed Computing, the complete list of fallacies was penned by a number of +people over a period of years. A minor hero of mine, [Bill +Joy](https://en.wikipedia.org/wiki/Bill_Joy)—inventor of the ex, and later vi, +editors—is responsible for devising the first four fallacies, along with Tom +Lyon, in what they dubbed The Fallacies of Networked +Computing. + +Reading over the eight fallacies listed out so plainly, they seem so obvious and +clear that you’d struggle to believe that anyone would ever fall foul of them: +of course we know bandwidth isn’t infinite! The thing is, these fallacies _are_ +obvious, but they don’t exist to teach us anything new; they exist to remind us +of the fundamentals. Nor are they intended to explain or describe normal +condition; they’re intended to remind us of worst case scenarios. They’re not +saying that the network is always unreliable, or that latency is always high, or +that bandwidth is always low: they’re saying that, sometimes, one or all of them +will be sub-optimal. We should prepare for that. + +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. Developers frequently tell me things like most of our users +are on wifi, or 4G is pretty much everywhere now, or people only +ever visit the site from inside the office anyway. Even if this is +statistically true—even if your analytics corroborate the claim—planning only +for the best leaves you utterly unprepared for the worst. To paraphrase +[Jeremy](https://twitter.com/adactio), it’s not about how well it works, but +[how well it fails](https://www.youtube.com/watch?v=sMhzgKUKdBU). + +In this post, I want to focus on the first three fallacies in relation to +front-end performance, and how they impact us as front-end developers. Whether +we realise it or not, we’re in the business of distributed computing: you +probably want that CSS file you’re writing to make its way from one computer (a +server) to another computer (a user’s phone) over some kind of network (the +internet). + +## The Network is Reliable + +The network is not reliable, at all. How many times have you lost cellular +connection as your train enters a tunnel? How many times has the internet gone +down at your office? How many times have you been connected to spotty hotel or +conference wifi? Many times, I’m willing to bet. It happens to me numerous times +a week. We know from first-hand experience that the network can be unreliable, +yet we always build with the assumption that it will be present and correct. +With this frame of mind, we’ll struggle to deliver anything at all if our +assumptions are challenged—we’re likely to fail entirely. + +The adage goes, the best request is the one that’s never made. Although it’s not +always going to be possible, if we can avoid the network altogether, then that’s +going to hold us in good stead. We can begin to mitigate this with offline-first +approaches, aggressive and immutable caching, and Service Workers. + +**The network is hostile; assume it isn’t on your side.** + +## Latency is Zero + +One of the key limiting factors in front-end performance, more so even than +bandwidth, is latency. Professor Hari Balakrishnan and colleagues at MIT +conducted research in 2014, which Balakrishnan summarised with: + +> …slow load-times are more strongly related to network delays than available +> bandwidth. Rather than decreasing the number of transferred bytes, we think +> that reducing the effect of network delays will lead to the most significant +> speedups. + +For regular web browsing, high latency will be felt much more than low +bandwidth. Long round-trip times (RTT) delay the speed at which packets can be +transferred over the network. Cellular connections typically have much higher +latency than we might experience on broadband; fibre will be much lower. +Geographic locales also tend to suffer: if you’re hosting your application in +the US but expect Australian visitors, they will instantly pay a huge penalty +when visiting your site. + +We can begin to mitigate latency issues by using CDNs, by pre-connecting new and +important origins, by inlining small critical resources, and by reducing the +number of round trips needed to render pages. + +**When it comes to performance, particularly on mobile, latency is the real +killer.** + +## Bandwidth is Infinite + +Despite being less critical for general web browsing than latency, bandwidth is +still a key limiting factor in our users’ experiences. Bandwidth tends to be +a concern when we begin to download larger files: downloading a 50KB stylesheet +over an 8MB connection will feel much the same as it would on a 100MB +connection, but downloading or streaming large files such as software updates or +video will get much easier on high bandwidth connections. + +That said, we still need to be aware and mindful of the size of the files we +send over the wire: wrapping your entire application up in a 1.2MB JavaScript +bundle isn’t going to do too much in favour of the third fallacy. + +We can start to mitigate the impact of finite bandwidth by delivering payloads +of an appropriate size, optimising our images, and minifying and compressing our +text assets. + +**It is not safe or sensible to assume that users can download large files.** + +## Planning for the Worst + +

+
Expect the best, plan for the worst, and prepare to be surprised.
+ + Denis Waitley + +

+ +The key takeaway here is not that we should assume that everything will be bad +all of the time; it’s that if we don’t consider or prepare for the worst, then +we’re left entirely ill-equipped to recover. If you build and structure +applications such that they survive adverse conditions, then they will thrive in +favourable ones. Something I often tell clients and workshop attendees is that +if you optimise for the lowest rung, everything else on top of that comes for +free. + +Memorise these fallacies, catch yourself when you’re beginning to fall into +them, print them out and stick them on your office wall, and above all else, use +them as ammunition the next time you hear someone say well no one is going to +visit on a 2G connection. Rightly or wrongly, I often find that it’s much +easier to convince someone of your viewpoint if there happens to be a Wikipedia +page of old-time principles to back it up. diff --git a/_posts/2018-01-17-finding-dead-css.md b/_posts/2018-01-17-finding-dead-css.md new file mode 100644 index 00000000..f764ba2d --- /dev/null +++ b/_posts/2018-01-17-finding-dead-css.md @@ -0,0 +1,66 @@ +--- +layout: post +title: "Finding Dead CSS" +date: 2018-01-17 14:25:19 +categories: Web Development +toc: false +meta: "Finding dead or unused CSS on a live website" +--- + +During a performance workshop I was running this week, I was reminded of +a technique for finding dead CSS on a live site. Note that I’m purposely not +using the phrase ‘unused CSS’, but ‘dead CSS’—the specific scenario I’m +describing looks a little like this: + +Imagine you have a large, long-running project that contains hundreds of +thousands of lines of code, contributed by dozens of developers across many +different teams. Not only are you very, very likely to have unused CSS, you’re +also likely to have completely dead code: entire features that have been +decommissioned but whose code was never deleted; dead ends in the application +that are quite hard to find; pages on the site that may be impossible for a user +to reach, but whose legacy lives on. + +How do we go about identifying this dead code? Tools like +[uncss](https://github.com/giakki/uncss), although very powerful, don’t quite +fit the bill. What we need is an almost +[RUM](https://en.wikipedia.org/wiki/Real_user_monitoring)-like solution—how can +we see what code users actually see on-screen on a live site? + +It turns out that there’s a very simple, cost-effective solution. + +Let’s say you have an old checkout flow; a legacy booking system that has slowly +been phased out over a number of months to years (perhaps legacy clients took +longer to be transitioned over to the new codebase). You’re now at a point where +you _think_—at least in theory—all customers and end users have been moved onto +the new platform, and therefore you should be able to start deleting the code. + +The first thing you need to do is start with a hypothesis: which code do you +assume to be dead? Identify a CSS selector that you would no longer expect +a user to encounter (e.g. `#checkout_wrapper`). + +Next, you need to create a 1×1px transparent GIF called `dead-css.gif` or +similar, and add a URL parameter to reflect the selector you wish to monitor, +e.g.: `/assets/img/dead-css.gif?#checkout_wrapper`. + +After that, you just need to set that specific image as a background on the +corresponding selector in your CSS: + +```css +#checkout_wrapper { + background-image: url('/assets/img/dead-css.gif?#checkout_wrapper'); + // Existing, legacy code +} +``` + +Finally, you need to put that change live and then sit back and wait. After +perhaps three months, you need to check your server’s logs for any requests for +that image and URL parameter. If there are no entries, nobody had that legacy +component rendered on their screen: you can probably go ahead and delete it all. + +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. + +Of course, this technique isn’t totally fail-safe, but it does begin to provide +a good litmus test, and hopefully some useful insights as to how your code +appears in a production application. diff --git a/_posts/2018-03-01-measuring-the-hard-to-measure.md b/_posts/2018-03-01-measuring-the-hard-to-measure.md new file mode 100644 index 00000000..d212a76b --- /dev/null +++ b/_posts/2018-03-01-measuring-the-hard-to-measure.md @@ -0,0 +1,101 @@ +--- +layout: post +title: "Measuring the Hard-to-Measure" +date: 2018-03-01 13:45:19 +categories: Web Development +meta: "How can we gather valuable data about previously hard-to-measure things?" +--- + +Last night I gave a performance-oriented talk at the wonderful +[DaFED](https://dafed.org/) event in Novi Sad, Serbia. In the talk, I go into +detail about third parties, and how they can have tremendous negative impact on +our performance. I also mention that, sometimes, it’s more important to think +about resilience than speed. For example, what happens to us if a third party +script fails to load? Can we recover from that? What happens if a third party +has an outage? Do we suffer the effects of it? + +This led to a great question from [Dragan](https://twitter.com/draganeror) along +the lines of Nowadays, how important is it to test sites with JavaScript +disabled? It’s certainly a thought-provoking question, but I won’t be going +into my answer in this post. Instead, I want to talk about being able to measure +just how many users do have JavaScript disabled. Most analytics software is +powered by JavaScript, so detecting JavaScript becomes self-fulfillingly +impossible. I want to share an incredibly quick tip to measure how many of your +users turn up on a device with no JavaScript capabilities… + +## Beacons and Tracking Pixels + +I recently wrote an article about [finding dead CSS](/2018/01/finding-dead-css/) +by using a tracking pixel… we can use almost the exact same technique to detect +non-JavaScript browsers: + +```html + +``` + +Now, any browsers that have JavaScript disabled will make a request for +`no-js.gif`, and all we need to do is check our server logs after a few months +and we’ll get a rough idea of just how many users arrive with JavaScript +disabled. Based on this data, you can make much more informed decisions about +your policy for non-JavaScript users. + +I set up a local server to test this out. After disabling JavaScript and +visiting the relevant test page, sure enough, `no-js.gif` began to appear in my +logs: + +

A screenshot
+ showing non-JavaScript browsers making HTTP requests for a specific tracking
+ pixel.

+ +### Update 2018-03-01 12:53:00 UTC + +[Ryan](https://twitter.com/RyanTownsend) makes a great point: + +> Might be worth noting on your new article that you’ll want to set a far-future +> Cache-Control expiry header for the `no-js.gif` (or even use immutable) if you +> want to count the number of users without JS rather than counting the number +> of pageviews. + +## Print Stylesheets + +In recent discussions with the NHS, a client of mine, we wondering whether +a print stylesheet would be appropriate. Most of the discussion centred around +hypotheticals and maybes: I can imagine x user might want to print +y information. These were sensible and educated guesses, but +guesses nonetheless. Let’s gather some data: + +```css +@media print { + + html::after { + content: url('/pixels/print.gif'); + } + +} +``` + +Note that most printers will not print background-images and -colours by +default, so we insert the image via `content` rather than, say, +`background-image`. + +Now, whenever someone wants to print our page, a request for `print.gif` will +fire off and we can capture that information: we can make informed decisions +about if and how to implement a print stylesheet, and how much effort we should +put into it. + +Once again, I built a quick demo to test it out. Expectedly, as soon as I hit +⌘+P, a request for `print.gif` fires off: + +

A screenshot
+ showing how printing a page makes an HTTP request for a specific tracking
+ pixel.

+ +While tracking pixels are far from a new idea, there are creative ways in which +we can use them to collect data useful to developers. Once the data is gathered, +we can begin to make much more informed decisions about how we work. diff --git a/_posts/2018-04-02-my-digital-music-setup.md b/_posts/2018-04-02-my-digital-music-setup.md new file mode 100644 index 00000000..b6631dc3 --- /dev/null +++ b/_posts/2018-04-02-my-digital-music-setup.md @@ -0,0 +1,346 @@ +--- +layout: post +title: "My Digital Music Setup" +date: 2018-04-02 16:35:19 +categories: Off Topic +meta: "An overview of my hardware and software setup for listening to digital music" +--- + +I want to begin this post with a disclaimer: I’m not an audiophile, and I don’t +claim to be particularly knowledgable when it comes to music technology. If +I sound like I don’t have a clue what I’m talking about, that’s probably because +I don’t. That said, perhaps this article might provide some use to people +looking to get a better handle on their digital setup: I know I would have +certainly appreciated a post like this when I was setting out. + +## Background + +I listen to a lot of music. Last year I logged over 70,000 minutes of listening +time. That’s almot 50 non-stop days. 90% of that listening is digital audio from +Spotify. When I’m on the move I’m almost constantly plugged into some music. +This is usually in the form of Spotify offline playlists, but over some decent +quality earphones ([see below](#shure-se425--219)). At home, I’m used to just +streaming Spotify through an Amazon Echo. + +Here are my top five most-played tracks of 2017’s 70,000 minutes: + + + +However, after recently discussing one of my all-time favourite tracks with +a friend, and, bizarrely enough, with +[Nu:Tone](https://en.wikipedia.org/wiki/Nu:Tone) himself, I decided that +I wanted to start taking my listening a little more seriously. + +

Hey man! +Looping back round to this (almost 4yr later 😂). Know anywhere I can get hold +of a ‘dubious’ copy of this track? I’ll donate £25 to a charity of your choosing +(DMs are open). Cheers!
— Harry Roberts (@csswizardry) 18 March, +2018

+ + + +If you want to listen to the track—of course you do, it’s stunning—then you’ll +have to make do with the YouTube version. Couple it with some good headphones +and a decent amount of volume and you’ll still get the picture: + + + +After falling fully back in love with this track (and managing to track down +a quality version of it) I decided to ramp up my home digital music setup to +something a little better than my current one. I guess this one track kicked +everything off. + +### Requirements + +As I currently do listen to almost exclusively digitally streamed music, it was +important to design a solution that was appropriate. With streaming music, +particularly any lossless formats, you’re quickly going to hit diminishing +returns where even the best equipment in the world fails to make any noticeable +improvements to the music’s quality. + +With this in mind, I set about my research: I needed a high-quality speaker that +would work well with streamed media, but that wouldn’t be overkill. I didn’t +necessarily want to use Bluetooth as its lower throughput would mean lower +quality: I wanted a wifi enabled speaker that I could stream to directly. + +Further, I needed to be mindful of space. I live in a city-centre apartment +that,unfortunately, doesn’t leave me with much room to play with. Oh and I guess +whatever I was going to buy needed to look nice—I’m really fond of my apartment +and spent a lot of time furnishing it, so I wanted something that would look +good. + +Finally, while I was also prepared to spend some cash, I didn’t want to lay down +thousands for mere digital listening. When I’m rich and I’ve got a huge house, +then I’ll start spending! + +- - - + +## Hardware + +### Technics OTTAVA™ f SC-C70 – £799 + +

Technics OTTAVA in-situ. See full size/quality (2.7MB)

+ +* [Manufacturer’s Website](http://www.technics.com/uk/products/premium-class/all-in-one-music-system-ottava-f-sc-c70.html) + +One of the units that kept getting mentioned was the Technics OTTAVA (or the +Technics OTTAVA™ Forte SC-C70 to give it its rather catchy full name). It +certainly looked stunning and seemed to tick all of the right boxes. On +a whim—whilst I was technically just nipping out for coffee—I decided to drop +into [Richer Sounds](https://www.richersounds.com/) to see if they had one in +stock that I might be able to look at. + +

Nipped +out to grab a coffee; came home with this @technics OTTAVA +SC-C70 😍 Thanks for the help, @RicherSounds. +pic.twitter.com/2Pm6Gt7NXq
— +Harry Roberts (@csswizardry) March +20, 2018

+ +They did. + +The guy at Richer Sounds (cheers, Roger!) got his colleagues to set the unit up +in the demo room for me while we chatted about my needs and requirements. Once +it was set up, I was sat down and allowed to listen and play around with it. +After listening to some tracks from a CD (remember those?), I hooked up my +phone’s AirPlay to the OTTAVA and blasted out the Nu:Tone track (above). It +sounded unreal. I was sold! + +I bought the unit right there and then and then took it home to set it up +immediately. It turned out to be a pretty expensive coffee break, but I’m +absolutely convinced that it was worth it. It was an incredibly simple and +straightforward setup: plug it in, connect it directly to your router, and +that’s it. I played around with a suitable location and settled on placing it on +a bookshelf near an external wall. This had two benefits: + +1. The wall behind the speaker helps to project sound outward into the room. +2. There are no neighbours on the other side of the wall. + +The listening quality of the OTTAVA is sublime. Rich yet incredibly clear. Bold +without being aggressive. Nuanced but not tinny. It feels incredibly immersive, +and tracks I’ve known for years suddenly sounded so much more complex and +impressive than I’d ever been used to. It has a huge presence, and manages to +fill the room even on a modest volume setting. + +I would wholeheartedly recommend it. + +### Shure SE425 – £219 + +

Shure SE425 in-ear monitors. See full size/quality (3.6MB)

+ +* [Manufacturer’s Website](https://www.shure.co.uk/products/earphones/se425) +* [Review](https://www.whathifi.com/shure/se425/review) (★★★★★) + +I’ve always taken music semi-seriously, so I’ve always owned good quality ear- +and headphones. I’ve tried many brands and styles over the years, from in-ears, +to on-ears, to circumaural, to monitors, and finally settling on the Shure +SE425s a few years ago. They are by far my favourite. + +Sound isolating (not cancelling), incredible clarity, and unusually comfortable +for in-ear ’phones, they’re one of my favourite things I’ve ever owned. You +should buy some. I can comfortably wear these for hours on end, their durable +construction means that they travel well, and their clever design means that the +earbuds themselves detach from the cable, meaning any damage to a specific part +of the entire earphone can be replaced independently. + +In fact, about two years ago, my then-pair of SE425s suffered some damage and +the earphone nozzle sheared off of the earphone main unit. I could have put in +a warranty claim to get a replacement, however that would have meant several +weeks without the earphones while they got sent off. I love these way too much +to go two weeks without them, so I just went out and bought a whole other pair. +Unfortunately, I forgot to send the damaged unit off to Shure for repair, which +is pretty bad of me. (Shure, if you’re reading this, maybe you can send me +a replacement left-hand driver?) + +That said, they do lack a little depth in the bass, and they’re not the most +handsome things I’ve ever seen. Still, I do absolutely love ’em. + +### AudioQuest DragonFly Red DAC – £170 + +

AudioQuest DragonFly Red plugged into my MacBook. See full size/quality (3.3MB)

+ +* [Manufacturer’s Website](https://www.audioquest.com/dacs/dragonfly/dragonfly-red) +* [Review](https://www.whathifi.com/audioquest/dragonfly-red/review) (★★★★★) + +When listening to music from my earphones rather than a speaker, I’m most likely +listening on my laptop or my phone. In order to improve sound quality, +I usually use an external digital-to-analog converter (DAC). Most basic +machines’ DACs aren’t really geared toward high-quality listening: they’re more +functional out of necessity. [From _What +Hi-Fi?_](https://www.whathifi.com/advice/dacs-everything-you-need-to-know): + +> The biggest problem is the DAC circuits used in many devices are just not +> efficient enough to do justice to the original recording, so a DAC upgrade can +> be the simplest way to improve your digital music and really get the most from +> your system. + +I’ve previously owned and loved the AudioQuest DragonFly v1.2 +([review](https://www.whathifi.com/audioquest/dragonfly-v12/review) (★★★★★)), +but their new DragonFly Red offers the ability to use the DAC with your phone, +which means better quality listening on the move. + +

AudioQuest DragonFly Red plugged into my iPhone. See full size/quality (3.1MB)

+ +The DragonFly is tiny—the same size as a conventional USB stick—but there’s no +denying that it does bulk up your phone somewhat. I have to plug my Shure’s +3.5mm jack into the DAC, then the DAC into an Apple Lightning to USB Camera +Adapter, then the adapter into your phone. When I’m on a flight (as I am right +now) or a train, this extra bulk doesn’t bother me too much—I get settled in +anyway, so I don’t mind the extra room it takes. When I’m out and about, it’s +too much to really stuff into a pocket, so I do just tend to forgo it entirely. + +The improvement that the DAC provides is subtle, but definitely noticeable. The +extra clarity you gain (particularly in tracks like [Kygo’s +ID](https://open.spotify.com/track/4SBqydJCEhcroni09XgT2c?si=6Hd-XeTXTB-JLvWuN0S59A)) +is pretty amazing and opens up parts of tracks that you’ve probably always been +missing. + +When listening on my laptop, it simply plugs into my Mac’s USB port and adds no +real overhead. This is a great bit of kit, and if you’re listening to high +enough quality audio then I’d recommend picking one up. + +### Audio-Technica ATH-M50x – £130 + +

Audio-Technica’s ATH-M50x hooked up to Tidal. See full size/quality (3.6MB)

+ +* [Manufacturer’s Website](http://www.audio-technica.com/cms/headphones/99aff89488ddd6b1/) +* [Review](https://www.whathifi.com/audio-technica/ath-m50x/review) (★★★★☆) + +These get a lot less use than my Shures, but they are a great pair of +headphones. A wonderfully comfortable pair of over-ear monitors that offer great +clarity. I’m including them because, although I don’t use them so much any more, +if you’re looking for a great pair of long-listen ’phones for work, these would +be great. + +- - - + +## Software + +### Spotify – £9.99/mo + +* [Manufacturer’s Website](https://spotify.com/) +* [Review](https://www.whathifi.com/spotify/review) (★★★★★) + +I’ve been a loyal Spotify user for eight (what?!) years now. Although it isn’t +perfect, I am a huge Spotify fan. My only concern is that I never really own any +of my music, which is a frightening thought at times—if Spotify disappears then +I’m lost. What I do love about Spotify is its reliability, its vast catalogue, +and its discovery options. + +Something I like a little less about Spotify is that it only streams MP3 +formats, which is kind-of annoying. They teased mention of a Spotify Hi-Fi +service but that soon disappeared, and they’ve gone very quiet on that front +since: + +

That’s +four years old 😔
— Harry Roberts (@csswizardry) March +21, 2018

+ +If Spotify launch a hi-res service I would happily pay whatever extra cost and +close down my Tidal account. + +To mitigate this issue, I stream and download all music in the 320kbit/s +_Extreme_ format. This still sounds pretty nice when combined with the DragonFly +DAC and my SE425s. + +### Tidal – £20/mo + +* [Manufacturer’s Website](https://tidal.com/) +* [Review](https://www.whathifi.com/tidal/review) (★★★★★) + +With my move to better quality listening, I became more interested in Tidal for +their lossless and +[_HiFi_](https://support.tidal.com/hc/en-us/articles/203055911-High-Fidelity-HiFi-Sound) +offering. + +I was pretty hesitant about moving to Tidal. I’ve got such a long history with +Spotify that I was put off the idea of swapping, even if Tidal does provide +lossless streaming. Another blocker was that I had no way of finding out which +songs in my Spotify library would be available on the Tidal service. I decided +to take the month’s free trial and find out. + +The good news is that the Tidal catalogue almost exactly mirrors Spotify’s, so +plenty of the tracks I’d saved elsewhere were available. Unfortunately, though, +not all of them: only about 80% of my Starred playlist is available on Tidal. + +The practical upshot of which is that I’m unable to switch over fully, leaving +me in a slightly uncanny valley where I use both services depending on what +I want to listen to. Not the end of the world, but it does make everything feel +a little incomplete. Plus, like I said, if Spotify begin offering a hi-res +streaming service then I will swap fully back immediately. + +

Tidal streaming lossless FLAC audio. See full size/quality (437KB)

+ +### SongShift – £3.99 + +* [Manufacturer’s Website](https://songshiftapp.com/) + +Because I have eight years of history with Spotify, I was very hesitant to begin +moving to Tidal: that’s a _lot_ of music to transfer. It turns out that +SongShift for iOS is the perfect tool to help with that process. + +SongShift allows you to transfer playlists from one streaming provider to +another. The Pro version will keep tracking playlists across services and keep +them all in sync, which means anything I add to my Spotify Starred playlist will +automatically be replicated in Tidal (provided the track is available). That’s +such a neat feature, and makes the £3.99 asking price seem unjustly low. + +Sidenote: Always buy the premium version, even if you don’t need it. It’s +important to support independent app developers. + +- - - + +## What Next? + +I’m pretty happy with this setup for the vast majority of my listening, but +I guess if I were to do a few things next, they’d probably be… + +### Own My Music + +I’d like to start owning more of my music. I should really pay for digital +downloads: it will better support the artists but will also allow me to own my +own library and give me access (hopefully) to multiple file formats of my +choosing. + +If I go down this path, I’ll need to start considering many other things such as +storage, backups, compatible media players, and maybe even dedicated hardware. + +### Combine Libraries + +I’d like to eventually coalesce all of my music into one provider, but that will +depend on Spotify’s decision to offer hi-res streaming, or on Tidal matching +Spotify’s catalogue. I’m not going to hold my breath for either. + +### Custom Sleeves + +It would be pretty cool to get some custom sleeves made for the SE425s. I’m not +really sure how to go about getting that done, but I’m sure it can’t be that +complicated. diff --git a/_posts/2018-05-21-identifying-auditing-discussing-third-parties.md b/_posts/2018-05-21-identifying-auditing-discussing-third-parties.md new file mode 100644 index 00000000..821e11c8 --- /dev/null +++ b/_posts/2018-05-21-identifying-auditing-discussing-third-parties.md @@ -0,0 +1,269 @@ +--- +layout: post +title: "Identifying, Auditing, and Discussing Third Parties" +date: 2018-05-21 10:01:21 +categories: Web Development +meta: "Gathering data about third-parties using free and open-source tooling" +--- + +A large part of my performance consultancy work is auditing and subsequently +governing third-party scripts, dependencies, and their providers. Uncovering +these third-parties isn’t always so straightforward, and discussing them with +the internal teams responsible (more often than not, the Marketing Department) +is usually quite sensitive and often uncomfortable: after all, approaching +a third-party vendors, or your marketing team, and telling them that their +entire day job is detrimental to performance is never going to be well-received. + +In order to help me have these awkward discussions—and it’s often my job as +a consultant to be the one having them—I lean on a number of tools to help make +the topic as objective and straightforward as possible. I want to share them +with you. + +## Identifying + +The single most useful tool I make use of when it comes to simply identifying +third parties is [Simon Hearne](https://webperf.ninja/)’s indispensable +[_Request Map_](http://requestmap.webperf.tools/). The workflow around this tool +is pretty straightforward: + +0. drop a URL into the _Target URL_ field; +0. select a test location (if geographic locale might affect which third parties + are called then this feature may be particularly useful to you) +0. submit a test; +0. and wait. + +Once that’s done, you’ll be presented with what my clients and I have lovingly +dubbed _the jellyfish_: + +

+ A Request Map result showing CNN’s third parties. See full-resolution animated GIF (7.9MB) +

+ +This interactive data visualisation shows us all of the third-party domains that +the URL makes requests to, and their subsequent requests, and so on. + +Each blob (_node_) represents a domain; the size of the node represents the +proportional number of bytes that domain was responsible for; the distance +between nodes represents the mean TTFB of the domain; the thickness of each +line (_edge_) represents the number of requests from the domain; dotted edges +represent requests initiated from a script or identified through a referrer +header; circular edges represent requests initiated by the same domain. + +That takes a while to memorise, so to start with just remember that big blobs +mean lots of bytes, distant blobs mean high TTFB, and thick lines mean lots of +requests. This will give you an at-a-glance idea of the shape of things. +Contrast CNN (above) with CSS Wizardry’s [homepage](/): + +

+ A Request Map result showing CSS Wizardry’s third parties. See full size/quality (289KB) +

+ +You can quickly see the difference in third party health between the two. +Although there are plenty of other tools that we can and should use to help us +audit third parties, Request Map is the one I want to show you right now. + +## Auditing + +Auditing third parties is a huge task and can take many different forms, so I’m +not going to go into too much detail in this post: you can always [hire +me](/services/) to show you everything I know about that. + +One immediate thing we can do with the data from Request Map is simply get +a broad overview of our worst offenders: whose blobs are the biggest? Is anyone +suffering extreme TTFB? Are there any long chains of third, fourth, fifth party +requests? + +Taking things a step further, one thing I always do is rerun a WebPageTest with +all of the third parties missing. This is pretty extreme and non-scientific, but +it is nice to get a very quick idea just how much overhead the third parties +introduce. In order to do this, you’ll need to download the CSV file that +Request Map makes available to you. There’s a link right at the bottom of the +Request Map viewport, and that will give you a file that looks a little like +this: + +``` +host, company, category, total_bytes, average_ttfb, average_load, number_requests +cnn.com, Target Site, Target Site, 0, 33, 130, 1 +www.cnn.com, Target Site, Target Site, 232542, 510, 1473, 11 +www.i.cdn.cnn.com, Unknown, Unknown, 617784, 6053, 8335, 20 +cdn.optimizely.com, Optimizely, A-B Testing, 120965, 97, 625, 1 +cdn.cnn.com, Target Site, Target Site, 427640, 6079, 8236, 32 +ads.rubiconproject.com, The Rubicon Project, Ad Exchange, 25734, 130, 833, 1 +js-sec.indexww.com, WPP, Programmatic Marketing Platform, 23605, 177, 873, 1 +cdn.krxd.net, Krux Digital, Data Management Platform, 106664, 266, 1668, 5 +static.criteo.net, Criteo, Retargeting, 20938, 44, 833, 1 +c.amazon-adsystem.com, Amazon, Affiliate Marketing, 14885, 199, 875, 1 +... +``` + +Look at all that lovely, raw data! + +**N.B.** This excerpt has been formatted for presentation. + +Next up, if you’re comfortable with the command line, let’s run a quick AWK +one-liner to strip out the non-Target Site entries: + + $ awk -F',' '$2 != "Target Site" { print $1 }' cnn.csv + +* `awk` is a relatively standard text-processing language. +* `-F','` tells AWK to use a comma as our field separator (CSVs are, by + definition, comma separated). +* `$2 != "Target Site"` means if the second field is **not** _Target Site_. +* `{ print $1 }` means print out the first field, which happens to be the + domain. +* `cnn.csv` is the path to the CSV file we just downloaded. + +This will, very crudely, provide you with a list of all of the page’s third +party domains. I would always recommend sanity-checking this list for any false +positives, and once you’ve cleaned it all up, copy it to your clipboard. + +Now we want to head back over to WebPageTest and run a test with all of those +domains blocked: let’s see how the page feels with all of its third parties +missing. + +In WebPageTest’s _Advanced Settings_ panel, locate the _Block_ tab; now paste in +your list of third party domains: + +

+ Using WebPageTest’s _Block_ feature. See full size/quality (267KB) +

+ +Rerunning the test (with all previous settings identical where possible) +with this list of domains blocked will give you a very broad overview of how +fast the page would be with all third party resources absent. + +This should now arm us with rough data around which we can being centring our +discussions, for example: + +* With all third parties present, load time increases by 6.3s. +* Removing all third parties reduced the number of requests by 4.2×. +* Without any third parties, page weight dropped by 2.7×. + +Again, I am keen to stress that these insights are fairly non-scientific, but at +this point we just need to know roughly where we stand. This should help us +begin discussions… + +## Discussing + +The next task, and by far the hardest, is discussing these issues with people, +whether that’s the third party provider themselves, or people within your +organisation, it’s not going to be particularly easy. In the latter camp, you’re +quite often dealing with data, marketing, and insights teams: a lot of the third +parties that websites employ are likely non-user facing, and typically, although +not always, exist only to serve the business (analytics, AB testing, +retargeting, tracking, etc.). + +The reason these discussions are usually so difficult to have is because +engineers have a tendency to apportion blame—Marketing did this, the +tag manager does that—and you’ll rarely make progress if you appear to be +blaming someone. You can’t rock up to your marketing department and tell them +that everything they do day-in, day-out is bad for the site. We need a much more +_ask, don’t tell_ approach. + +To facilitate this, I devised a small Google Sheet that consumes your _Request +Map_ data, and presents the information in a much more digestible and objective +format. By pulling the data into a more universal style—like ’em or loathe ’em, +everyone understands a spreadsheet—we’re much better equipped to begin +discussing these issues with people who aren’t used to waterfall charts, flame +graphs, and spider diagrams. + +The small demo embedded below shows the exported Request Map data for my +homepage: + +

+ + + +The columns should all be fairly self-explanatory: + +* **A, B, and C** tell us the domain in question, the controller of that domain, + and what kind of service it provides (where known). +* **D, E, F, and G** show numerical data pertaining to relevant performance + measurements. +* **H** is left blank for now. This is an important column that we’ll come back + to a little later. + +The main thing I want to show, however, is the different colouring of certain +cells. Cells in columns _B_ and _C_ can be yellow; cells in _D_, _E_, _F_, or +_G_ can be varying shades of red. + +* **Yellow** cells highlight a duplicate provider or service type, for example, + two analytics packages, or hitting Facebook multiple times. +* **Red** highlights relative severity, and is a scale from white to very-dark + red. From the zeroth to the 90th percentile, we get a gradual darkening from + white to red; the 90th to 100th percentile all share the same heaviest shade: + these are your worst 10%, and probably want focusing on first. + +Using these two types of information, we can begin honing in on potential +redundancy in duplicate providers, and/or the impact and overhead that certain +providers carry. + +Armed with this raw data, it’s time to organise a meeting with whoever is +primarily responsible for your third party implementations. This could be one +distinct department, a cross section of the business, or anything in between. +The goal of this initial meeting is to learn. Remember: _ask, don’t tell_. + +Avoid the temptation of entering the meeting all guns blazing; you might be +armed with data, but it’s vital that you don’t weaponise it. Begin by explaining +that We’ve been doing a little housework and begun looking at the third +parties we use. I’ve put together a list of them but I could really use your +help understanding what they all are and what they all do. This sets the +tone that you need them, and at this point, you do. The goal of this meeting +isn’t to eradicate all of our third parties, nor is it to undermine anyone’s +efforts: the goal is to get an idea of why these things are used and what their +perceived value to the business is. + +Example questions include: + +* Can you talk me through Google Tag Manager? +* What does this particular third-party do for us? +* Who is responsible for this service? +* Which services do we use daily? +* Are there any services in here that we don’t recognise? + +Begin populating the _Notes_ column with answers, probe further, and avoid the +temptation to make any decisions in the meeting itself. + +Once you feel you’ve gathered enough answers, it’s time to go away and draw up +a potential action plan. Are there third parties that nobody can explain? +They’re an immediate candidate for removal. Are there duplicate third parties +that do almost identical jobs? Then which one could you decommission? Are there +any third parties that load an inordinate amount of bytes? Can you open support +tickets with the provider? + +### Using the Google Sheet + +If you want to make use of the Google Sheet, the simplest way I know _right now_ +is: + +0. [Open it up](https://docs.google.com/spreadsheets/d/1uTcRSoJAkXfIm2yfG5hvCSzvSZD9fAwXNQMVK3HdPMI/edit) +0. File » Make a copy… + 0. Save a version to your own Google Drive +0. Export your _Request Map_ data as a CSV +0. Import your own data into your duplicated sheet + 0. Select column _A2_ + 0. File » Import… + 0. Upload + 0. Navigate to your own CSV + 0. Replace data at selected cell + 0. Import data +0. Remove any duplicate or superfluous rows and data + +## Closing + +In the times I’ve used these tools and techniques to discuss third parties with +clients, I’ve always found that things have gone a lot more smoothly than +pointing fingers and taking a more ruthless approach. Nobody appreciates being +told that their main contributions to the website make it slower. Having raw +data, coupled with an _ask, don’t tell_ attitude, often yields much more +favourable results. I’ve made great headway by adopting this strategy—I hope it +helps you, too. diff --git a/_posts/2018-06-11-image-inconsistencies-how-and-when-browsers-download-images.md b/_posts/2018-06-11-image-inconsistencies-how-and-when-browsers-download-images.md new file mode 100644 index 00000000..0f7d7c33 --- /dev/null +++ b/_posts/2018-06-11-image-inconsistencies-how-and-when-browsers-download-images.md @@ -0,0 +1,338 @@ +--- +layout: post +title: "Image Inconsistencies: How and When Browsers Download Images" +date: 2018-06-11 19:02:54 +categories: Web Development +meta: "How and when do browsers download certain types of image? What does that +mean for performance?" +--- + +This year, I’ve been working closely with the wonderful +[Coingaming](http://coingaming.io/) team out in beautiful +[Tallinn](https://www.google.co.uk/search?q=tallinn&safe=off&tbm=isch). We’ve +been working pretty hard on making their suite of online products [much +faster](https://twitter.com/csswizardry/status/1003881067189800962), and I’ve +been the technical consultant leading the project. It’s been an incredibly fun +and rewarding engagement, and we’ve made some real business- and customer-facing +improvements. One of the key reasons I’ve found the project so fun is that it’s +given me a real chance to get very forensic. Naturally, a team should always +tackle the low-hanging fruit first, but once that’s done, you get to delve much +deeper into the weeds. This blog post comes from there. + +## Background + +In order to get better control over how a series of thumbnail images are +displayed on the homepage of one of their products, the team opted to build them +not as `` elements, but as CSS `background-image`s: this allowed them to +better size and position the images in their container, and, putting aside any +semantic concerns, it made sense from a styling point of view. My only +reservation was knowing that, because the images are defined in CSS rather than +HTML, their outgoing requests won’t start until the browser has created the +Render Tree: it’s not until all the CSS has been downloaded, parsed, and the +CSSOM constructed that the browser actually knows This `div` with this class +is currently visible on the page and its background is set to be this image: I’d +better download it!. + +The waterfall below shows the browser waiting for CSSOM completion before it +dispatches any requests for any images—you can clearly see that the CSS needs to +finish before any images start. This is down to the simple fact that the browser +doesn’t know which (if any) images it will need until the CSSOM has been built: + +

Waterfall showing that background images cannot be downloaded until +CSSOM has completed.

+ +This is too late for such important content of theirs—users want to see the +thumbnails as soon as possible. + +By moving the images to `` elements (which is also semantically more +appropriate), the browser can discover them far sooner—as they become exposed to +the browser’s preload scanner—and dispatch their requests before (or in parallel +to) CSSOM completion: + +

Waterfall showing how regular image elements can be downloaded +independently of CSSOM construction.

+ +This is stuff we already knew: + +1. Browsers can’t possibly download `background-image`s until they’ve built the + CSSOM. +2. Browsers shouldn’t base—thus delay—the downloading of ``s on CSSOM + completion. More on this later… + +Where it gets interesting is when I started to wonder how different browsers +handle different types of image when they’re visible or not: an `` +element with `display: none;` applied to it ideally wouldn’t get downloaded, but +the only way the browser would know that the image is indeed hidden is if it +waits for CSSOM completion, thus slowing down the default behavior of the ``: what’s going to happen? + +- - - + +## `background-image` + +I will start with `background-image` as that’s what my client’s initial use case +was. I feel like the behaviour for `background-image` should be the most +predictable as there are certain impossibilities at play (e.g. we can’t download +a `background-image` until we’ve built the CSSOM). + +### What I Would Expect + +I have a couple of expectations (or hopes) that I predict: + +1. Browsers do not (can not) trigger a download for a `background-image` until + it knows it needs it (i.e. until the CSSOM has been constructed). +2. Browsers would not download `background-image` that is applied to an element + that is hidden from view (e.g. `display: none;`). + +### What Actually Happens + +#### Chrome (v67.0.3396.79) + +* **Expectedly** Chrome does not download any `background-image` until the CSSOM + has been constructed: +

+* **Unexpectedly**, Chrome will download a `background-image` that isn’t visible + to the user: +

+ +#### Safari (v11.1 (13605.1.33.1.4)) + +* **Expectedly** Safari does not download any `background-image` until the CSSOM + has been constructed: +

+* **Expectedly**, Safari will not download a `background-image` that isn’t + visible to the user: +

+ +#### Firefox (v60.0.1) + +* **Expectedly** Firefox does not download any `background-image` until the + CSSOM has been constructed: +

+* **Expectedly**, Firefox will not download a `background-image` that isn’t + visible to the user: +

+ +#### Opera (v53.0.2907.68) + +* **Expectedly** Opera does not download any `background-image` until the CSSOM + has been constructed: +

+* **Unexpectedly**, Opera will download a `background-image` that isn’t visible + to the user: +

+ +#### Edge (v17.17134) + +* **Expectedly** Edge does not download any `background-image` until the CSSOM + has been constructed. +

+* **Unexpectedly**, Edge will download a `background-image` that isn’t visible + to the user. +

+* **Expectedly**, as a result of the above, Chrome will download `` that + ultimately end up invisible: +

+ +#### Safari + +* **Expectedly**, Safari will not block `` requests on CSSOM + construction: +

+* **Expectedly**, as a result of the above, Safari will download `` that + ultimately end up invisible: +

+ +#### Firefox + +* **Unxpectedly**, Firefox will block `` requests on CSSOM construction. + This means that `` requests are not dispatched until the CSSOM has been + built. This represents a surprising inefficiency: +

+* **Unexpectedly**, despite Firefox knowing it won’t need the ``—as + a result of it unexpectedly blocking on CSSOM construction—it will still + download the `` even if it knows it will not be visible. I find this + extremely bizarre: it seems to get things wrong on both counts: +

+ +#### Opera + +* **Expectedly**, Opera will not block `` requests on CSSOM + construction: +

+* **Expectedly**, as a result of the above, Opera will download `` that + ultimately end up invisible: +

+ +#### Edge + +* **Expectedly**, Edge will not block `` requests on CSSOM + construction: +

+* **Expectedly**, as a result of the above, Edge will download `` that + ultimately end up invisible: +

+ +### Summary + +**N.B.** _Yes_ or _No_ represents factual information. _✓_ and _✗_ +represent what I would consider good/expected and bad/unexpected behaviour, +respectively. + +| | Chrome | Safari | Firefox | Opera | Edge | +| ------------------------: | :----: | :----: | :-----: | :---: | :--: | +| **Block on CSSOM** | No ✓ | No ✓ | Yes ✗ | No ✓ | No ✓ | +| **Download if Invisible** | Yes ✓ | Yes ✓ | Yes ✗ | Yes ✓ | Yes ✓ | + +### Verdict + +**Firefox** appears to block `` on CSSOM construction. This seems like +a bad idea—no ``s will begin downloading until Firefox has downloaded, +parsed, and applied the CSS. This means that if you have blocking stylesheets, +they’re blocking your ``. This would be particularly troublesome if `` are key content (think Imgur, Flickr, etc.). + +**Firefox** gets weirder still! It waits until it’s constructed the CSSOM before +it fires off any `` requests, which means it knows if the `` will +be visible or not, but if the `` is invisible, it will download it +anyway. This is a double-hit: Firefox blocks `` on CSSOM construction yet +still downloads `` that aren’t visible. + +- - - + +## Key Takeaways + +### The Facts + +* **Chrome**, **Opera**, and **Edge** will download `background-image`s that + aren’t required for first render. This means that hidden DOM nodes that have + a `background-image` applied to them will still have that `background-image` + downloaded. **Beware unexpected downloads.** +* **Firefox** will block `` downloads on CSSOM construction, meaning + later-than-expected downloads. **Beware delays.** +* Further, **Firefox** will still download the `` even if it wasn’t + needed. **Beware unexpected downloads.** + +### How Might this Affect You? + +If you’re a product that relies heavily on content imagery (e.g. Flickr, online +publication, photographer) then Firefox will not download any of those images +until it’s dealt with your CSS. You should look into preloading any key image +content. + +If you’re making heavy use of background images and, for whatever reason, are +not showing all of them for first render, beware that some browsers will go +ahead and download them anyway: you might want to look into better strategies +for hidden content (e.g. removal from the DOM rather than `display: none;`). diff --git a/_posts/2018-07-21-getting-to-know-a-legacy-codebase.md b/_posts/2018-07-21-getting-to-know-a-legacy-codebase.md new file mode 100644 index 00000000..b3ad470d --- /dev/null +++ b/_posts/2018-07-21-getting-to-know-a-legacy-codebase.md @@ -0,0 +1,189 @@ +--- +layout: post +title: "Getting to Know a Legacy Codebase" +date: 2018-07-21 13:02:54 +categories: Web Development +meta: "What should you do when you first get launched into an old, sprawling CSS codebase?" +--- + +The other day, [Brad](http://bradfrost.com/) dropped me a message asking me +about the topic of getting to know a brand new (specifically CSS) codebase. The +kind of codebase that no one person truly understands any more; the kind of +codebase that’s had a dozen different contributors over just as many years; the +kind of codebase that’s never had a full-scale refactor or overhaul, but that’s +grown organically over time and changed with new techniques, styles, and trends. + +(Un)fortunately, I’ve dealt with a number of these types of project over time, +so I have a few tips about getting to know a codebase like this, and how to +begin making sense of it. + +## See What Breaks + +Honestly, to start with, I just identify a part of the codebase (it could be +a large or important feature, a frequently-occurring component, something +pertinent to current workstreams, etc.) and play around with it: bend it, break +it, change it, see what happens to it. + +Make a note of anything odd or unusual; if that thing happens again when you +play around elsewhere in the codebase, there could be some significance to it. + +## Identify Your Entry Points + +Try as much as you can to build up an idea of which files import which other +files; who passes what onto who; what inherits from where; what does your +dependency tree look like? + +Once I can work out where files are bundled up and imported from, I can build +a much better mental model of the topology of the codebase. + +## Get an Idea of What’s Been Changed + +It’s often a good idea to see what files were changed last: any files that +haven’t been altered in over a year are probably less important to current work. +One (rather cumbersome, I admit) way to see that is with the following: + +``` +$ git log --name-only --since="365 days" | sort -u | awk '/\.(le|c|sa|sc)ss$/{print}' | nl +``` + +**N.B.** This output will not be listed chronologically. + +This will log your codebase, list the filenames associated with any commits made +in the last year, it will then pass them off into `sort` where we leave only +unique entries, before passing it into Awk and printing only `.less`, `.sass`, +`.scss`, or `.css` filepaths, then finally passing it all into `nl` to number +the lines of output. + +This should give you a list of all the stylesheets changed in the last year. + +## Identify (Roughly) What is Used + +Chrome’s _Coverage_ tool is a great way to see at a very high-level glance what +CSS is being used by the current page. This very non-scientific method of +checking code usage should give you an approximate idea of what might be dead +code, or what you might simply be able to ignore. + +For a slightly more robust, but still imperfect method of identifying dead code, +try this technique that I wrote up [earlier in +2018](/2018/01/finding-dead-css/). + +Although very vague data, it should give some idea as to where to start looking. + +## Learn the Codebase Organically + +Don’t go looking for trouble. Work around learning the features you need to work +on immediately. If you never need to touch the help and support section, there’s +no point going out of your way to research it. Try to remain focused and learn +about the parts of the codebase that are most important and timely. + +This is general good advice with any tech debt or refactoring problem: don’t +increase your (cognitive) workload unnecessarily. + +## Set Up Regression Tests + +You need to make sure you don’t inadvertently mess anything up while you’re +looking around. There are two methods I would use here: the first is very +low-fidelity and a little coarse; the second is far more involved. + +If I’m playing around with Sass, or any other precompiled assets, I take +a checksum of the compiled CSS file before I start playing, and then a checksum +after I made any changes. If the two fingerprints differ, I know what whatever +changes I just made wound up in the compiled assets. This kind of light-touch +smoketest allows me to crudely figure out inputs and outputs. It can also help +me to figure out whether a particular variable or mixin might be being used in +the project: if I change a variable’s value, but the compiled CSS is identical, +I could make a note that that variable might be unused. + +``` +harryroberts in ~/Sites/csswizardry.com on (master) +» shasum _includes/css/csswizardry.min.css +7142689d6f79927f192577002f181aef5721d1bc _includes/css/csswizardry.min.css + +harryroberts in ~/Sites/csswizardry.com on (master) +» vim css/_settings.colors.scss + +harryroberts in ~/Sites/csswizardry.com on (master) +» shasum _includes/css/csswizardry.min.css +ae2a4c94c945d61f1c009d4fb14c40fa19f20ddd _includes/css/csswizardry.min.css +``` + +Note that the two checksums differ: this means that whatever I changed in +`css/_settings.colors.scss` did make its way into the complied CSS. Although +I might not know exactly what or how far reaching that change was, I do at last +know that the thing I altered will affect the project. + +For longer-term refactoring or auditing, it can be useful to set up a formal +regression testing tool such as +[BackstopJS](https://github.com/garris/BackstopJS). This will alert me if I do +any severe, customer-facing damage to the UI. Ideally, we’d have a regression +testing suite in-place permanently, so this is as good a time as any to start. + +## Learn How to Use Parker, ack, and ctags + +[Parker](https://github.com/katiefenn/parker/) is a wonderful static analysis +tool from my buddy [Katie](http://www.katiefenn.co.uk/). You can use it to grab +useful information about the overall make-up and health of your CSS: how many +IDs, mean specificity, how many `!important`s, etc. Learn more about Parker with +my post all about [demystifying its +output](/2016/06/improving-your-css-with-parker/). + +[ack](https://beyondgrep.com/) is an incredible little command line utility that +serves as a more useful, sensible, and user-friendly alternative to grep. You +can use it to quickly search entire codebases for specific strings using regex. +As an example: + +``` +$ ack --css "\d*\.\d*px" +``` + +This will search every CSS file for pixel values that contain decimals (e.g. +`24.1px`). ack is incredibly useful, so I’d recommend reading my [Ack for +CSS Developers](/2017/01/ack-for-css-developers/) +post for some more practical examples. + +If you’re feeling adventurous, install +[ctags](https://github.com/universal-ctags/ctags). Although a little old school, +ctags can be incredibly powerful on all manner of projects. Wikipedia defines +ctags as: + +> …a programming tool that generates an index (or tag) file of names found in +> source and header files of various programming languages. Depending on the +> language, functions, variables, class members, macros and so on may be +> indexed. These tags allow definitions to be quickly and easily located by +> a text editor or other utility. + +Basically, ctags will create a kind of of database of all of the function, +variable, mixin, ID, and class definitions for your project. Text editors that +support ctags can then use this information to begin linking up disparate parts +of the codebase for you, showing you where particular code is originally defined. + +For me, as a Vim user, I generate my project’s tags file from the project’s root +like so: + +``` +$ ctags -R +``` + +This will `-R`ecursively look through my project and make the database of its +references. Then, once in my text editor, hitting `Ctrl-]` with my cursor +over—for example—a Sass variable will jump me to the exact place that variable +was defined. + +## Git on Top of Things + +Learn some advanced Git logging, showing, and blaming. The entire project’s +history is contained here, and if you know how to interrogate it effectively, +you’ll be able to build up a really great context of how things came together. + +## Reach Out to People + +Your extensive detective work in Git will no doubt yield a number of different +names: if these people are still in the organisation, use them. Ask them to help +clarify things; see if they remember the events or decisions surrounding certain +features, etc. + +## What Next? + +None of these techniques will allow you to learn the codebase in an afternoon, +but if you keep referring back to them, you should find that navigating your way +around an existing, sprawling project becomes a little easier. diff --git a/_posts/2018-10-27-three-types-of-performance-testing.md b/_posts/2018-10-27-three-types-of-performance-testing.md new file mode 100644 index 00000000..bdc74738 --- /dev/null +++ b/_posts/2018-10-27-three-types-of-performance-testing.md @@ -0,0 +1,195 @@ +--- +layout: post +title: "The Three Types of Performance Testing" +date: 2018-10-27 10:02:39 +categories: Web Development +meta: "How can we make it easier for businesses to understand when and what to measure?" +--- + +A lot of companies—even if they are aware that performance is key to their +business—are often unsure of how, when, or where performance testing sits within +their development lifecycle. To make things worse, they’re also usually unsure +whose responsibility performance measuring and monitoring is. + +The short answers are, of course ‘all the time’ and ‘everyone’, but this mutual +disownership is a common reason why performance often gets overlooked. When +something is everyone’s responsibility, it normally becomes no one’s +responsibility. + + Diagram showing the circular nature of Proactve, then Reactive, then
+ Passive performance testing.

Diagram showing the circular nature of Proactve, then Reactive, then
+ Passive performance testing.

+ +To combat this, and make performance testing regular and routine, I try to +distill the types of testing that we do into three distinct categories: +**Proactive**, **Reactive**, and **Passive**. Each have their own time, place, +purpose, focus, and audience. Simply knowing the different forms of performance +testing that we have available to us, and where they sit in the product +development process, makes it much easier for businesses to adopt a performance +strategy and keep on top of things. + +In this short post, I want to introduce you to these three types of testing, how +and when they should be carried out, and what their aims and outcomes should be. +Each kind of testing is listed chronologically—that is, you should do them in +order—but all complement each other, and will ultimately feed into one another. + +## Proactive + +A lot of the time when auditing client sites, many of the issues and +inefficiencies I uncover could have quite easily been discovered by the +development team themselves. The problems could be been identified, nipped in +the bud, and never have made it in front of a customer at all if they’d just +known where to look! + +

+ +The first kind of testing a team should carry out is _Proactive_ testing: this +is very intentional and deliberate, and is an active attempt to identify +performance issues. + +This takes the form of developers assessing the performance impact of every +piece of work they do as they’re doing it. The idea here is that **we spot the +problem before it becomes problematic**. Prevention, after all, is cheaper than +the cure. Capturing performance issues at this stage is much more preferable to +spotting them after they’ve gone live. + +The reason I refer to this as Proactive testing is becasue we generally _do_ +need to go out of our way to spot the problems. Things always always feel fast +when we’re developing because, more often than not, we’re working on high-spec +machines on dedicated networks, and also serving from localhost which removes +the bulk of the latency and bandwidth issues that a real user would suffer. + +Unfortunately, most issues do not get captured at this point. This is good news +for me, because I get paid to come in and fix them, but businesses would +save—and indeed make—a lot more money if they caught all of their performance +issues here. It is vital, therefore, that engineers have a firm understanding of +performance fundamentals, as well as a solid command of their tools. + +This phase of testing is usually quite forensic, and isn’t normally very +business-facing: the wider organisation doesn’t need to know about any +bottlenecks, because they don’t exist in the product yet. + +My involvement with clients here is usually workshops and training: teaching +developers the knowledge and tooling required to effectively conduct performance +audits, and making teams self-sufficient. + +* **Who:** Engineers +* **When:** During development +* **Why:** Identify and fix issues before they make it into the release +* **How:** DevTools, browsers, local tooling + +## Reactive + +Of course, it is impossible to fix (or even find) every performance issue during +the development phase. Therefore, we introduce a slightly more defensive style +of testing: _Reactive_ testing. + +

+ +Reactive testing is usually done in response to an event in the development +lifecycle, such as a build or a release, and measures the cumulative effect of +all of your engineers’ changes. Perhaps each individual deems their changes to +be non-harmful, but all changes combined lead to an unacceptable regression. It +is important that we capture that. + +Reactive testing should be reasonably automated, and should be carried out in as +live-like an environment as possible. This could mean Gulp tasks that run +Lighthouse against your staging environment, automated WebPageTests that run at +every deployment, performance budgets that run on every build, and so on. + +

csswizardry.com’s Visually Complete budget being broken three days in a month

+ +This synthetic testing can allow us to measure regressions before they make it +into production, and the business can decide whether the regression is severe +enough to delay a release, or whether we prioritise its solution in the next +sprint. Accordingly, Reactive testing carries partial organisational +visibility—both developers and product people would be aware of and responsive +to reactive performance tests. + +Any issues spotted here will pass back into Proactive testing to be +troubleshooted and remedied locally. + +My involvement with clients here is assessing where best to introduce these +tools in the development–deployment lifecycle, and working to define suitable +thresholds and budgets. + +* **Who:** Engineers, Product Owners +* **When:** Each build, each release +* **Why:** Visibility of regressions about to go live +* **How:** Performance budgets, automation, synthetic testing, CI + +## Passive + +Despite two formal rounds of performance testing, we’re still unable to capture +everything before it goes live. Once in production, our site will likely look +very different to how it did in our development environment: tag managers have +kicked in, your ads are on the site, your analytics package is capturing data, +and all third parties are implemented and running. You’re out on the world wide +web—you have no idea who is turning up to the site, what their context is, what +hardware, software, or infrastructure they’re using, or anything. + +Now, we sit back and conduct _Passive_ tests to gather data over time and assess +the situation: can we spot patterns? Do certain browsers or geographic locales +suffer more than others? Do changes in performance correlate to changes in +business metrics? + +

csswizardry.com Start Render vs. Bounce rate for the last month

+ +For this, we need to turn to Real User Monitoring (RUM). RUM is great for +gathering real and historical data, but by this point there is an essence of +being a little too late… your performance slowdowns are already live! + +The good news, however, is that you’re at least aware of them. By passively +gathering RUM data from your actual visitors, you’re going to be far better +equipped to identify what kinds of issues your site suffers in the real world. + +

Rudimentary performance information in Google Analytics

+ +Issues captured here often take longer to fix as we need to gather and assess +the data, and then feed the changes back into the backlog (unless we have +something critical that we swarm), but they will head back into the Proactive +stage so that we can test and verify locally that we’re headed in the right +direction. + +My involvement with clients here is either assessing existing RUM data to +identify what their performance issues are, and helping them to define +a strategy for fixing them, or helping the business decide sensible and +relevant metrics to track. + +* **Who:** Engineers, Product Owners, Marketing +* **When:** Constantly in live environments +* **Why:** Awareness of current or historic performance issues in live +* **How:** RUM tooling, analytics, monitoring + +## What This Means for Developers + +Developers now have a clear understanding of what is expected of them. Things +should be scrutinised early and often, and regressions should be found and fixed +before they leave their machine. + +They have clear milestones throughout a project that will help them identify and +remedy performance issues, as well as visibility in front of the business, who +should by now be supporting their efforts. + +## What This Means for the Business + +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?’ + +By formalising what they are, and how and when to do them, it helps to make +performance monitoring become second nature. This means we capture regressions +much sooner, and ultimately make and save the business money. diff --git a/_posts/2018-11-09-css-and-network-performance.md b/_posts/2018-11-09-css-and-network-performance.md new file mode 100644 index 00000000..078299c4 --- /dev/null +++ b/_posts/2018-11-09-css-and-network-performance.md @@ -0,0 +1,695 @@ +--- +layout: post +title: "CSS and Network Performance" +date: 2018-11-09 19:57:12 +categories: Web Development +meta: "How can CSS impact network and resource-loading performance? Can things +be that serious?" +--- + +Despite having been called CSS Wizardry for over a decade now, +there hasn’t been a great deal of CSS-related content on this site for a while. +Let me address that by combining my two favourite topics: CSS and performance. + +CSS is critical to rendering a page—a browser will not begin rendering until all +CSS has been found, downloaded, and parsed—so it is imperative that we get it +onto a user’s device as fast as we possibly can. Any delays on the Critical Path +affect our Start Render and leave users looking at a blank screen. + +## What’s the Big Problem? + +Broadly speaking, this is why CSS is so key to performance: + +1. A browser can’t render a page until it has built the Render Tree; +2. the Render Tree is the combined result of the DOM and the CSSOM; +3. the DOM is HTML plus any blocking JavaScript that needs to act upon it; +4. the CSSOM is all CSS rules applied against the DOM; +5. it’s easy to make JavaScript non-blocking with `async` and `defer` + attributes; +6. making CSS asynchronous is much more difficult; +7. so a good rule of thumb to remember is that **your page will only render as + quickly as your slowest stylesheet**. + +With this in mind, we need to construct the DOM and CSSOM as quickly as +possible. Constructing the DOM is, for the most part, relatively fast: your +first HTML response _is_ the DOM. However, as CSS is almost always a subresource +of the HTML, constructing the CSSOM usually takes a good deal longer. + +In this post I want to look at how CSS can prove to be a substantial bottleneck +on the network (both in itself and for other resources) and how we can mitigate +it, thus shortening the Critical Path and reducing our time to Start Render. + +## Employ Critical CSS + +If you are able, one of the most effective ways to cut down the time to Start +Render is to make use of the Critical CSS pattern: identify all of the styles +needed for Start Render (commonly the styles needed for everything above the +fold), inline them in ` +{% endhighlight %} + +…will yield this waterfall: + +

Loss of parallelisation in Firefox due to ineffective Preload + Scanner (N.B. The same waterfall occurs in IE/Edge.)

+ +Here we can clearly see that the `@import`ed stylesheet does not start +downloading until the JavaScript file has completed. + +The problem isn’t unique to JavaScript, either. The following HTML creates the +same phenomenon: + +{% highlight html %} + + + +{% endhighlight %} + +

+ +The immediate solution to this problem is to swap the ` +{% endhighlight %} + +There is a fascinating behaviour present in all browsers that is intentional and +expected, yet I have never met a single developer who knew about it. This is +doubly surprising when you consider the huge performance impact that it can +carry: + +**A browser will not execute a ` +{% endhighlight %} + +This is by design. This is on purpose. Any synchronous ` +{% endhighlight %} + +Given this order, we can clearly see that the JavaScript file does not even +begin downloading until the moment the CSSOM is constructed. We’ve completely +lost any parallelisation: + +

Having a stylesheet before an async snippet undoes our opportunity +to parallelise.

+ +Interestingly, the Preload Scanner would like to have picked up the +reference to `analytics.js` ahead of time, but we’ve inadvertently hidden it: +`"analytics.js"` is a string, and doesn’t become a tokenisable `src` attribute +until the `` blocks have no dependency on CSS, place them +above your stylesheets.** + +Here’s what happens when we move to this pattern: + +{% highlight html %} + + + +{% endhighlight %} + +

Swapping a stylesheet and an async snippet around can regain +parallelisation.

+ +Now you can see that we’ve completely regained parallelisation and the page has +loaded almost 2× faster. + +### Place Any Non-CSSOM Querying JavaScript Before CSS; Place Any CSSOM-Querying JavaScript After CSS + +Dang. This article is getting way, way more forensic than I intended. + +Taking this even further, and looking beyond just async loading snippets, how +should we load CSS and JavaScript more generally? To work that out, I posed +myself the following question and worked back from there: + +If + +* synchronous JS defined after CSS is blocked on CSSOM construction, and; +* synchronous JS blocks DOM construction… + +then—assuming no interdependencies—which is faster/preferred? + +* Script then style; +* style then script? + +The answer: + +**If the files do not depend on one another, then you should place your blocking +scripts above your blocking styles**—there’s no point delaying the JavaScript +execution with CSS upon which the JavaScript doesn’t actually depend. + +(The Preload Scanner ensures that, even though DOM construction is +blocked on the scripts, the CSS is still downloaded in parallel.) + +If some of your JavaScript does but some does not depend on CSS, then the +absolute most optimum order for loading synchronous JavaScript and CSS would be +to split that JavaScript in two and load it either side of your CSS: + +{% highlight html %} + + + + + + + +{% endhighlight %} + +With this loading pattern, we get download and execution both happening in the +most optimum order. I apologise for the tiny, tiny details in the below +screenshot, but hopefully you can see the small pink marks that represent +JavaScript execution. Entry (1) is the HTML that is scheduled to execute some +JavaScript when other files arrive and/or execute; entry (2) executes the moment +it arrives; entry (3) is CSS, so executes no JavaScript whatsoever; entry (4) +doesn’t actually execute until the CSS is finished. + +

How CSS can impact the points at which JavaScript executes.

+ +**N.B.** It is imperative that you test this pattern against your own specific +use-case: there could be different results depending on whether or not there are +large differences in file-size and execution costs between your before-CSS +JavaScript file and the CSS itself. Test, test, test. + +## Place `` in `` + +This final strategy is a relatively new one, and has great benefit for perceived +performance and progressive render. It’s also very component friendly. + +In HTTP/1.1, it’s typical that we concatenate all of our styles into one main +bundle. Let’s call that `app.css`: + +{% highlight html %} + + + + + + + + + + + +

+ +

...

+ +

...

+ +

+ + + +

+ + + + +{% endhighlight %} + +This carries three key inefficiencies: + +1. **Any given page will only use a small subset of styles found in `app.css`:** + we’re almost definitely downloading more CSS than we need. +2. **We’re bound to an inefficient caching strategy:** a change to, say, the + background colour of the currently-selected day on a date picker used on only + one page, would require that we cache-bust the entirety of `app.css`. +3. **The whole of `app.css` blocks rendering:** it doesn’t matter if the current + page only needs 17% of `app.css`, we still have to wait for the other 83% to + arrive before we can begin rendering. + +With HTTP/2, we can begin to address points (1) and (2): + +{% highlight html %} + + + + + + + + + + + + + + + + + + + +

+ +

...

+ +

...

+ +

+ + + +

+ + + + +{% endhighlight %} + +Now we’re getting some way around the redundancy issue as we’re able to load CSS +more appropriate to the page, as opposed to indiscriminately downloading +everything. This reduces the size of the blocking CSS on the Critical Path. + +We’re also able to adopt a more deliberate caching strategy, only cache busting +the files that need it and leaving the rest untouched. + +What we haven’t solved is the fact that it all still blocks rendering—we’re +still only as fast as our slowest stylesheet. What this means is that if, for +whatever reason, `site-footer.css` takes a long time to download, the browser +can’t make a start on rendering `.site-header`. + +However, due to a recent change in Chrome (version 69, I believe), and behaviour +already present in Firefox and IE/Edge, ``s will only +block the rendering of subsequent content, rather than the whole page. This +means that we’re now able to construct our pages like this: + +{% highlight html %} + + + + + + + + + + + + + +

+ + +

+ +

...

+ + +

...

+ +

+ + + + +

+ + + + + +{% endhighlight %} + +The practical upshot of this is that we’re now able to progressively render our +pages, effectively drip-feeding styles to the page as they become available. + +In browsers that don’t currently support this new behaviour, we suffer no +performance degradation: we fall back to the old behaviour where we’re only as +fast as the slowest CSS file. + +For further detail on this method of linking CSS, I would recommend reading +[Jake’s article on the subject](https://jakearchibald.com/2016/link-in-body/). + +{% include promo.html %} + +## Summary + +There is a _lot_ to digest in this article. It ended up going way beyond the +post I initially intended to write. To attempt to summarise the best network +performance practices for loading CSS: + +* Lazyload any CSS not needed for Start Render: + * This could be Critical CSS; + * or splitting your CSS into Media Queries. +* Avoid `@import`: + * In your HTML; + * but in CSS especially; + * and beware of oddities with the Preload Scanner. +* Be wary of synchronous CSS and JavaScript order: + * JavaScript defined after CSS won’t run until CSSOM is completed; + * so if your JavaScript doesn’t depend on your CSS; + * load it before your CSS; + * but if it does depend on your CSS: + * load it after your CSS. +* Load CSS as the DOM needs it: + * This unblocks Start Render and allows progressive rendering. + +### Warning + +Everything I have outlined above adheres to specs or known/expected behaviour, +but, as always, test everything yourself. While it’s all theoretically true, +things always work differently in practice. Test and +[measure](/2018/10/three-types-of-performance-testing/). + +### Thanks + +I’m grateful to [Yoav](https://twitter.com/yoavweiss), +[Andy](https://twitter.com/andydavies), and +[Ryan](https://twitter.com/ryantownsend) for their insights and proof-reading +over the last couple of days. diff --git a/_posts/2018-11-23-what-if.md b/_posts/2018-11-23-what-if.md new file mode 100644 index 00000000..97a86e33 --- /dev/null +++ b/_posts/2018-11-23-what-if.md @@ -0,0 +1,77 @@ +--- +layout: post +title: "What If?" +date: 2018-11-23 17:51:40 +categories: Web Development +toc: false +meta: "How do we so often forget to ask the simple question: what if?" +--- + +I was recently conducting some exploratory work for a potential client when +I hit upon a pretty severe flaw in a design decision they’d made: They’d built +a responsive image lazyloader in JavaScript which, by design, worked by: + +0. immediately applying `display: none;` to the ``; +0. waiting until the very last of the page’s images had arrived; +0. once they’d arrived, removing the `display: none;` and gradually fading the + page into visibility. + +Not only does this strike me as an unusual design decision—setting out to build +a lazyloader and then having it intentionally block rendering—there had been no +defensive strategy to answer the question: what if something goes wrong with +image delivery? + +‘Something wrong’ is exactly what happened. Due to an imperfect combination of: + +0. images being completely unoptimised, plus; +0. a misconfiguration with their image transformation service leading to double + downloads for all images; + +…they’d managed to place 27.9MB of images onto the Critical Path. Almost 30MB of +previously non-render blocking assets had just been turned into blocking ones on +purpose with no escape hatch. Start render time was as high as 27.1s over +a cable connection[^1]. + +If you’re going to build an image loader that hides the whole page until all +images are ready, you must also ask yourself **what if the images don’t +arrive?** + +This isn’t the first time I’ve encountered such an odd choice of development +strategy. A popular A/B testing tool does something remarkably similar: they +instruct developers to drop a ` +{% endhighlight %} + +There are a number of perceived benefits to doing this, but my aim later in this +article is to either debunk these claims, or show how other costs vastly +outweigh them. + +* **It’s convenient.** It requires very little effort or brainpower to include + files like this. Copy and paste a line of HTML and you’re done. Easy. +* **We get access to a CDN.** `code.jquery.com` is served by + [StackPath](https://www.stackpath.com/products/cdn/), a CDN. By linking to + assets on this origin, we get CDN-quality delivery, free! +* **Users might already have the file cached.** If `website-a.com` links to + `https://code.jquery.com/jquery-3.3.1.slim.min.js`, and a user goes from there + to `website-b.com` who also links to + `https://code.jquery.com/jquery-3.3.1.slim.min.js`, then the user will already + have that file in their cache. + +## Risk: Slowdowns and Outages + +I won’t go into too much detail in this post, because I have a [whole +article](/2017/07/performance-and-resilience-stress-testing-third-parties/) +on the subject of third party resilience and the risks associated with slowdowns +and outages. Suffice to say, if you have any critical assets served by third +party providers, and that provider is suffering slowdowns or, heaven forbid, +outages, it’s pretty bleak news for you. You’re going to suffer, too. + +If you have any render-blocking CSS or synchronous JS hosted on third party +domains, go and bring it onto your own infrastructure _right now_. Critical +assets are far too valuable to leave on someone else’s servers. + +### `code.jquery.com` Outage + +

Yikes! It looks like +code.jquery.⁠com is currently suffering an outage. This is going to have +a huge impact across a massive portion of the web. Please please please +SELF-HOST YOUR STATIC ASSETS: https://t.co/YWb7ZLdPxc pic.twitter.com/2UjFNhrCST
— Harry +Roberts (@csswizardry) 27 +April, 2023

+ + + +## Risk: Service Shutdowns + +A far less common occurrence, but what happens if a provider decides they need +to shut down the service? This is exactly what [Rawgit](https://rawgit.com) did +in October 2018, yet (at the time of writing) a crude GitHub code search still +yielded [over a million +references](https://github.com/search?q=rawgit&type=Code) to the now-sunset +service, and almost 20,000 live sites are still linking to it! + +

Many thanks to Paul +Calvano who very kindly queried +the HTTPArchive for me.

+ +## Risk: Security Vulnerabilities + +Another thing to take into consideration is the simple question of trust. If +we’re bringing content from external sources onto our page, we have to hope that +the assets that arrive are the ones we were expecting them to be, and that +they’re doing only what we expected them to do. + +Imagine the damage that would be caused if someone managed to take control of +a provider such as `code.jquery.com` and began serving compromised or malicious +payloads. It doesn’t bear thinking about! + +### Mitigation: Subresource Integrity + +To the credit of all of the providers referenced so far in this article, they do +all make use of [Subresource +Integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) +(SRI). SRI is a mechanism by which the provider supplies a hash (technically, +a hash that is then Base64 encoded) of the exact file that you both expect and +intend to use. The browser can then check that the file you received is indeed +the one you requested. + +{% highlight html %} + +{% endhighlight %} + +Again, if you absolutely must link to an externally hosted static asset, make +sure it’s SRI-enabled. You can add SRI yourself using [this handy +generator](https://www.srihash.org/). + +## Penalty: Network Negotiation + +One of the biggest and most immediate penalties we pay is the cost of opening +new TCP connections. Every new origin we need to visit needs a connection +opening, and that can be very costly: DNS resolution, TCP handshakes, and TLS +negotiation all add up, and the story gets worse the higher the latency of the +connection is. + +I’m going to use an example taken straight from Bootstrap’s own [Getting +Started](https://getbootstrap.com/docs/4.3/getting-started/introduction/). They +instruct users to include these following four files: + +{% highlight html %} + + + + +{% endhighlight %} + +These four files are hosted across three different origins, so we’re going to +need to open three TCP connections. How much does that cost? + +Well, on a reasonably fast connection, hosting these static assets off-site is +311ms, or 1.65×, slower than hosting them ourselves. + +

By linking to three different origins in order to serve static +assets, we cumulatively lose a needless 805ms to network negotiation. Full +test.

+ +Okay, so not exactly terrifying, but Trainline, a client of mine, found that by +reducing latency by 300ms, [customers spent an extra £8m +a year](https://wpostats.com/2016/05/04/trainline-spending.html). This is +a pretty quick way to make eight mill. + +

By simply moving our assets onto the host domain, we completely +remove any extra connection overhead. Full +test.

+ +On a slower, higher-latency connection, the story is much, much worse. Over 3G, +the externally-hosted version comes in at an eye-watering **1.765s slower**. +I thought this was meant to make our site faster?! + +

On a high latency connection, network overhead totals a whopping +5.037s. All completely avoidable. Full +test.

+ +Moving the assets onto our own infrastructure brings load times down from around +5.4s to just 3.6s. + +

By self-hosting our static assets, we don’t need to open any more +connections. Full +test.

+ +If this isn’t already a compelling enough reason to self-host your static +assets, I’m not sure what is! + +### Mitigation: `preconnect` + +Naturally, my whole point here is that you should not host any static assets +off-site if you’re otherwise able to self-host them. However, if your hands are +somehow tied, then you can use [a `preconnect` Resource +Hint](https://speakerdeck.com/csswizardry/more-than-you-ever-wanted-to-know-about-resource-hints?slide=28) +to preemptively open a TCP connection to the specified origin(s): + +{% highlight html %} + + + ... + + + + ... + + +{% endhighlight %} + +For bonus points, deploying these as [HTTP +headers](https://andydavies.me/blog/2019/03/22/improving-perceived-performance-with-a-link-rel-equals-preconnect-http-header/) +will be even faster. + +**N.B.** Even if you do implement `preconnect`, you’re still only going to make +a small dent in your lost time: you still need to open the relevant connections, +and, especially on high latency connections, it’s unlikely that you’re ever +going to fully pay off the overhead upfront. + +## Penalty: Loss of Prioritisation + +The second penalty comes in the form of a protocol-level optimisation that we +miss out on the moment we split content across domains. If you’re running over +HTTP/2—which, by now, you should be—you get access to prioritisation. All +streams (ergo, resources) within the same TCP connection carry a priority, and +the browser and server work in tandem to build a dependency tree of all of these +prioritised streams so that we can return critical assets sooner, and perhaps +delay the delivery of less important ones. + +To fully understand the benefits of prioritisation, [Pat Meenan’s +post](https://calendar.perfplanet.com/2018/http2-prioritization/) on the topic +serves as a good primer. + +**N.B.** Technically, owing to H/2’s [connection +coalescence](https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/), +requests can be prioritised against each other over different domains as long as +they share the same IP address. + +If we split our assets across multiple domains, we have to open up several +unique TCP connections. We cannot cross-reference any of the priorities within +these connections, so we lose the ability to deliver assets in a considered and +well designed manner. + +Compare the two HTTP/2 dependency trees for both the off-site and self-hosted +versions respectively: + +

Notice how we need to build new dependency trees per +origin? Stream IDs 1 and 3 keep reoccurring.

+ +

By hosting all content under the same origin, we can build one, more +complete dependency tree. Every stream has a unique ID as they’re all in the +same tree.

+ +Fun fact: Stream IDs with an odd number were initiated by the client; +those with an even number were initiated by the server. I honestly don’t think +I’ve ever seen an even-numbered ID in the wild. + +If we serve as much content as possible from one domain, we can let H/2 do its +thing and prioritise assets more completely in the hopes of better-timed +responses. + +## Penalty: Caching + +By and large, static asset hosts seem to do pretty well at establishing +long-lived `max-age` directives. This makes sense, as static assets at versioned +URLs (as above) will never change. This makes it very safe and sensible to +enforce a reasonably aggressive cache policy. + +That said, this isn’t always the case, and by self-hosting your assets you can +design [much more bespoke caching +strategies](/2019/03/cache-control-for-civilians/). + +## Myth: Cross-Domain Caching + +A more interesting take is the power of cross-domain caching of assets. That is +to say, if lots and lots of sites link to the same CDN-hosted version of, say, +jQuery, then surely users are likely to already have that exact file on their +machine already? Kinda like peer-to-peer resource sharing. This is one of the +most common arguments I hear in favour of using a third-party static asset +provider. + +Unfortunately, there seems to be no published evidence that backs up these +claims: there is nothing to suggest that this is indeed the case. Conversely, +[recent +research](https://discuss.httparchive.org/t/analyzing-resource-age-by-content-type/1659) +by [Paul Calvano](https://twitter.com/paulcalvano) hints that the opposite might +be the case: + +> There is a significant gap in the 1st vs 3rd party resource age of CSS and web +> fonts. 95% of first party fonts are older than 1 week compared to 50% of 3rd +> party fonts which are less than 1 week old! This makes a strong case for self +> hosting web fonts! + +In general, third party content seems to be less-well cached than first party +content. + +Even more importantly, [Safari has completely disabled this +feature](https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd-party-resources/) +for fear of abuse where privacy is concerned, so the shared cache technique +cannot work for, at the time of writing, [16% of users +worldwide](http://gs.statcounter.com/). + +In short, although nice in theory, there is no evidence that cross-domain +caching is in any way effective. + +### Update: 2025-01-09 + +Chrome 86 (2020) and Firefox 85 (2021) also both enabled cache +partitioning, meaning no major browser stands to gain any performance benefit +from shared assets hosting. Self-host your static assets. + +## Myth: Access to a CDN + +Another commonly touted benefit of using a static asset provider is that they’re +likely to be running beefy infrastructure with CDN capabilities: globally +distributed, scalable, low-latency, high availability. + +While this is absolutely true, if you care about performance, you should be +running your own content from a CDN already. With the price of modern hosting +solutions being what they are (this site is fronted by Cloudflare which is +free), there’s very little excuse for not serving your own assets from one. + +Put another way: if you think you need a CDN for your jQuery, you’ll need a CDN +for everything. Go and get one. + +## Self-Host Your Static Assets + +There really is very little reason to leave your static assets on anyone else’s +infrastructure. The perceived benefits are often a myth, and even if they +weren’t, the trade-offs simply aren’t worth it. Loading assets from multiple +origins is demonstrably slower. Take ten minutes over the next few days to audit +your projects, and fetch any off-site static assets under your own control. diff --git a/_posts/2019-08-08-time-to-first-byte-what-it-is-and-why-it-matters.md b/_posts/2019-08-08-time-to-first-byte-what-it-is-and-why-it-matters.md new file mode 100644 index 00000000..ac6659c3 --- /dev/null +++ b/_posts/2019-08-08-time-to-first-byte-what-it-is-and-why-it-matters.md @@ -0,0 +1,177 @@ +--- +layout: post +title: "Time to First Byte: What It Is and How to Improve It" +date: 2019-08-08 02:06:56 +categories: Web Development +meta: "Just how much does TTFB matter when it comes to front-end performance?" +--- + +I’m working on a client project at the moment and, as they’re an ecommerce site, +there are a lot of facets of performance I’m keen to look into for them: load +times are a good start, start render is key for customers who want to see +information quickly (hint: that’s all of them), and client-specific metrics like +how quickly did the key product image load? can all provide valuable +insights. + +However, one metric I feel that front-end developers overlook all too quickly is +_Time to First Byte_ (TTFB). This is understandable—forgivable, almost—when you +consider that TTFB begins to move into back-end territory, but if I was to sum +up the problem as succinctly as possible, I’d say: + +**While a good TTFB doesn’t necessarily mean you will have a fast website, a bad +TTFB almost certainly guarantees a slow one.** + +Even though, as a front-end developer, you might not be in the position to make +improvements to TTFB yourself, it’s important to know that any problems with +a high TTFB will leave you on the back foot, and any efforts you make to +optimises images, clear the critical path, and asynchronously load your webfonts +will all be made in the spirit of playing catchup. That’s not to say that more +front-end oriented optimisations should be forgone, but there is, unfortunately, +an air of [closing the stable door after the horse has +bolted](https://www.collinsdictionary.com/dictionary/english/to-close-the-stable-door-after-the-horse-has-bolted). +You really want to squish those TTFB bugs as soon as you can. + +## What is TTFB? + +

The TTFB timing entry isn’t particularly insightful. View full +size/quality (375KB)

+ +TTFB is a little opaque to say the least. It comprises so many different things +that I often think we tend to just gloss over it. A lot of people surmise that +TTFB is merely time spent on the server, but that is only a small fraction of +the true extent of things. + +The first—and often most surprising for people to learn—thing that I want to +draw your attention to is that **TTFB counts one whole round trip of latency**. +TTFB isn’t just time spent on the server, it is also the time spent getting from +our device to the sever and back again (carrying, that’s right, the first byte +of data!). + +Armed with this knowledge, we can soon understand why TTFB can often increase so +dramatically on mobile. Surely, you’ve wondered before, the server has no +idea that I’m on a mobile device—how can it be increasing its TTFB?! The +reason is because mobile networks are, as a rule, high latency connections. If +your Round Trip Time (RTT) from your phone to a server and back again is, say, +250ms, you’ll immediately see a corresponding increase in TTFB. + +If there is one key thing I’m keen for your to take from this post, its is that +**TTFB is affected by latency**. + +But what else is TTFB? Strap yourself in; here is a non-exhaustive list +presented in no particular order: + +* **Latency:** As above, we’re counting a trip out to and a return trip from the + server. A trip from a device in London to a server in New York has + a theoretical best-case speed of 28ms over fibre, but this makes lots of very + optimistic assumptions. Expect [closer to + 75ms](https://wondernetwork.com/pings/London/New+York). + * This is why serving your content from a CDN is so important: even in the + internet age, being geographically closer to your customers is advantageous. +* **Routing:** If you are using a CDN—and you should be!—a customer in Leeds + might get routed to the [MAN + datacentre](https://blog.cloudflare.com/manchester-uk-cloudflares-63rd-data-center/) + only to find that the resource they’re requesting isn’t in that + [PoP](https://en.wikipedia.org/wiki/Point_of_presence)’s cache. Accordingly, + they’ll get routed all the way back to your origin server to retrieve it from + there. If your origin is in, say, Virginia, that’s going to be a large and + invisible increase in TTFB. +* **Filesystem reads:** The server simply reading static files such as images or + stylesheets from the filesystem has a cost. It all gets added to your TTFB. +* **Prioritisation:** HTTP/2 has a (re)prioritisation mechanism whereby it may + choose to [stall lower-priority + responses](https://github.com/pmeenan/http2priorities#readme) on the server + while sending higher-priority responses down the wire. H/2 prioritisation + issues aside, even when H/2 is running smoothly, these expected delays will + contribute to your TTFB. +* **Application runtime:** It’s kind of obvious really, but the time it takes to + run your actual application code is going to be a large contributor to your + TTFB. +* **Database queries:** Pages that require data from a database will incur + a cost when searching over it. More TTFB. +* **API calls:** If you need to call any APIs (internal or otherwise) in order + to populate a page, the overhead will be counted in your TTFB. +* **Server-Side Rendering:** The cost of server-rendering a page could be + trivial, but it will still contribute to your TTFB. +* **Cheap hosting:** Hosting that is optimised for cost over performance usually + means you’re sharing a server with any number of other websites, so expect + degraded server performance which could affect your ability to fulfil + requests, or may simply mean underpowered hardware trying to run your + application. +* **DDoS or heavy load:** In a similar vein to the previous point, increased + load with no way of auto-scaling your application will lead to degraded + performance where you begin to probe the limits of your infrastructure. +* **WAFs and load balancers:** Services such as [web application + firewalls](https://en.wikipedia.org/wiki/Web_application_firewall) or load + balancers that sit in front of your application will also contribute to your + TTFB. +* **CDN features:** Although a CDN is a huge net win, in certain scenarios, + their features could lead to additional TTFB. For example, [request + collapsing](https://docs.fastly.com/guides/performance-tuning/request-collapsing), + [edge-side includes](https://en.wikipedia.org/wiki/Edge_Side_Includes), etc.). +* **Last-mile latency:** When we think of a computer in London visiting a server + in New York, we tend to oversimplify that journey quite drastically, almost + imagining that the two were directly connected. The reality is that there’s + a much more complex series of intermediaries from our own router to our ISP; + from a cell tower to an undersea cable. [Last mile + latency](https://en.wikipedia.org/wiki/Last_mile) deals with the + disproportionate complexity toward the terminus of a connection. + +It’s impossible to have a 0ms TTFB, so it’s important to note that the list +above does not represent things that are necessarily bad or slowing your TTFB +down. Rather, your TTFB represents any number of the items present above. My aim +here is not to point fingers at any particular part of the stack, but instead to +help you understand what exactly TTFB can entail. And with so much potentially +taking place in our TTFB phase, it’s almost a miracle that websites load at all! + +So. Much. Stuff! + +## Demystifying TTFB + +Thankfully, it’s not all so unclear anymore! With a little bit of extra work +spent implementing the [Server Timing +API](https://www.w3.org/TR/server-timing/), we can begin to measure and surface +intricate timings to the front-end, allowing web developers to identify and +debug potential bottlenecks previously obscured from view. + +The Server Timing API allows developers to augment their responses with an +additional `Server-Timing` HTTP header which contains timing information that +the application has measured itself. + +This is exactly what we did at BBC iPlayer last year: + +

The newly-available `Server-Timing` header can be added +to any response. View full +size/quality (533KB)

+ +**N.B.** Server Timing doesn’t come for free: you need to actually measure the +aspects listed above yourself and then populate your `Server-Timing` header with +the relevant data. All the browser does is display the data in the relevant +tooling, making it available on the front-end: + +

Now we can see, right there in the browser, how long certain aspects +of our TTFB took. View full +size/quality (419KB)

+ +To help you get started, Christopher Sidebottom wrote up [his implementation of +the Server Timing +API](https://medium.com/bbc-design-engineering/server-timing-in-the-wild-bfb34816322e) +during our time optimising iPlayer. + +It’s vital that we understand just what TTFB can cover, and just how critical it +can be to overall performance. TTFB has knock-on effects, which can be a good +thing or a bad thing depending on whether it’s starting off low or high. + +**If you’re slow out of the gate, you’ll spend the rest of the race playing +catchup.** diff --git a/_posts/2019-08-13-making-cloud-typography-faster.md b/_posts/2019-08-13-making-cloud-typography-faster.md new file mode 100644 index 00000000..a945b06b --- /dev/null +++ b/_posts/2019-08-13-making-cloud-typography-faster.md @@ -0,0 +1,365 @@ +--- +layout: post +title: "Making Cloud.typography Fast(er)" +date: 2019-08-13 09:51:11 +categories: Web Development +meta: "What issues does Hoefler&Co’s Cloud.typography introduce, and how can we mitigate them?" +--- + +**Disclaimers:** + +* I was not approached or hired by + [Hoefler&Co](https://www.typography.com/) or + [Cloud.typography](https://www.typography.com/webfonts) to look into any of + the following issues. +* I disclosed all of the below to Cloud.typography and gave them ample + opportunity to work together to solve the issues at the root of the problem. +There was no appetite from them to do so, so I decided to make it all available +for free anyway—a faster web benefits everyone. +* All of the people I have dealt with seem like really, really nice folk. + Nothing that follows is a reflection on any individuals. Please bear that in +mind as you read. + +It all started, as these things often do, with a waterfall: + +

So much to unpack in only a handful of entries! Can you see +it? View +full size (31KB)

+ +I was doing some cursory research and running a few tests against a potential +client’s site so as to get a good understanding of the shape of things before we +were to work together. Even in just the first 10 entries in the waterfall chart +above, there were so many fascinating clues and tells that were made immediately +apparent. I was struck by some interesting behaviour happening in the very early +stages of the page-load lifecycle. Let’s pick it apart… + +0. Entry (9), for `cloud.typography.com`, has very high connection overhead + (405ms in total), [surprisingly large + TTFB](/2019/08/time-to-first-byte-what-it-is-and-why-it-matters/) + (210ms), and returns a `302` + anyway. What’s going on here? Where are we getting redirected to? + * It turns out that Cloud.typography is redirecting the request to + a client-owned CSS file hosted on `fonts.[client].com`: Note a `Location: + https://fonts.[client].com/[number]/[hash].css` header. +0. Entry (10) lives on a different origin again, so we have more connection + overhead to contend with, and the file seems to take an incredibly long time + to download (as evidenced by the sheer amount of dark green—sending data). + Why does Cloud.typography redirect us to a file we own ourselves? Is there + some kind of ‘release mechanism’ used to authenticate `[client].com` to use + the font service? And why is the file so huge?! + * It turns out that Cloud.typography is a hybrid solution, somewhere between + cloud- and self-hosted. An outgoing request from a whitelisted domain + returns a `302`, forwarding the request to a self-hosted CSS file that is + optimised specifcally for your browser, OS, and UA (Google Fonts do + something similar). The CSS file(s) that we host is provided by + Cloud.typography. + * In case you’re wondering, a non-whitelisted domain returns a `403` + response. + * The file is so big because it actually contains all of our fonts as Base64 + encoded data URIs. +0. Finally, entry (3), a large JS file, doesn’t execute until the moment the CSS + (entry (10)) has completed. From this, I can gather that entry (3) is + a synchronous JS file that was defined in the HTML sometime after the CSS. + * How did I know this? Because synchronous JS defined anywhere after + synchronous CSS will not execute while the CSS in question is in flight. JS + can be blocked on CSSOM construction. The knock-on effects of this long CSS + request chain are huge. + +So, what are the performance implications of all of this? + +First up, even though the request to `cloud.typography.com` returns a `302` +response with a `text/html` MIME type, its outgoing request is for CSS. This +makes complete sense as the request is invoked by a ``. +We can further verify this by noting the presence of an `Accept: +text/css,*/*;q=0.1` request header. Put simply, despite not ‘being’ CSS, this +request sits on our Critical Path and therefore blocks rendering. + +To further exacerbate the problem, the `302` response has [a `Cache-Control: +must-revalidate, private` +header](/2019/03/cache-control-for-civilians/#must-revalidate), +meaning that we will always make an outgoing request for this resource +regardless of whether or not we’re hitting the site from a cold or a warm cache. +Although this response has a 0B filesize, we will always take the latency hit on +every single page view (and this response is basically 100% latency). On mobile +connections, this can amount to whole seconds of delays, all sat on the Critical +Path. + +Next up, we get sent to `fonts.[client].com`, which introduces yet more latency +for the connection setup. (Please note that this phenomenon is specific to the +way this company has implemented their own assets and has nothing at all to do +with Cloud.typography.) Because this response is CSS, our critical request chain +remains unbroken—this is all work taking place on the Critical Path. + +Once we’ve dealt with the connection overhead, we begin downloading a behemoth +CSS file (271.3KB) that is packed with all of the fonts for the project encoded +in Base64 data URIs. [Base64 is absolutely terrible for +performance](/2017/02/base64-encoding-and-performance/), +and, particularly where fonts are concerned, has the following issues: + +* Base64 encoding assets into CSS moves more weight (therefore delays) onto the + Critical Path, holding back our Start Render. +* Base64 compresses terribly, meaning we can’t claw back much of the excessive, + increased filesize. +* Fonts are not usually downloaded until the Render Tree has been constructed + and the browser knows that the current page actually needs them. This + defensive measure by the browser ensures that only the fonts that are actually + needed will ever be downloaded. By encoding the fonts into the CSS, all of the + font data is downloaded regardless of whether the current page needs it or + not: it’s incredibly wasteful. +* By Base64 encoding our fonts, we end up in a situation where, technically, we + don’t have any fonts at all: we just have CSS. The implication here is that + we’ve now rendered any font-loading strategies completely ineffective: + `font-display` can’t work if there are no fonts; the Font Loading API is + useless if there are no fonts. Technically, what we have here is a CSS + problem, not a font problem. + +The practical upshot of the above is that we have 1,363ms of render blocking CSS +on our Critical Path for a first-time visit on a cable connection. A repeat view +still cost us 280ms: + +

Because the Cloud.typography ‘CSS file’ has +a `must-revalidate` header, +we still take the latency hit on repeat views. View +full size (17KB)

+ +The final nail in the coffin is the fact that, because there are no font files, +the browser is unable to employ any kind of decision about how to handle missing +typefaces. Most browsers will display invisible text for three seconds and, if +the webfont doesn’t make it onto the device in that time, will instead display +fallback text. Once the webfont does arrive, we then swap to displaying that. +This means that, once the page has started rendering, the user will go for, at +most, three seconds unable to read any content. + +This all only works if there are actual font files to be negotiated. Because +Cloud.typography’s fonts are actually just more CSS, the browser is unable to +discern the two, and thus cannot offer a three-second grace period. This means +that there’s a theoretically infinite period where we don’t just block the +rendering of text, but we block the rendering of the whole page. + +If you’re interested in seeing a real-world example of this, consider [the +following filmstrip comparison](https://www.webpagetest.org/video/compare.php?tests=190811_VX_b8f581c9bf94c7ce40358174b91e43d5%2C190811_9R_43ce007515d25497c9f86327d6c357c6&thumbSize=200&ival=100&end=visual). + +Post-It is a Cloud.typography customer, and the entire page stays blank until +the Cloud.typography CSS file makes it onto the device. Grid By Example, on the +other hand, uses Google Fonts (without any `font-display` configuration), which +allows the browser to begin rendering the page in the absence of the webfonts. + +**N.B.** The two test cases are very, very different sites, so I’m not +looking to directly compare any timings—that would be unfair—I merely want to +highlight the phenomenon. + +On a 3G connection, Post-It’s Start Render is 16.8s. Removing Cloud.typography +entirely [improves that time by over +48%](https://www.webpagetest.org/video/compare.php?tests=190811_9J_fe8556cdd9c19eecbdc1c35a5cdb49b0%2C190811_9T_98fec8b8ee896f94389a99425561c17f&thumbSize=200&ival=100&end=visual), +bringing it down to 8.7s. + +All the above issues combined mean that, unfortunately, Cloud.typography is slow +by default. While [I am a huge fan of the +foundry](https://twitter.com/csswizardry/status/842088778386812930), and some of +the stunning typefaces they have produced, I cannot in good conscience recommend +Cloud.typography as a credible font provider while this is their implementation. +It is actively harmful for performance. + +## Solving the Problem for the Client + +The solutions I implemented for my client were mitigations at best—the problems +still exist in Cloud.typography, but I was able to do a handful of things to +take the edge off of how the problems were manifesting themselves. + +First up, I wanted to unblock the JS execution: there was no need to hold back +the main `app.js` bundles for the sake of the fonts. The fix? Simple: swap their +`` and ` +{% endhighlight %} + +**After:** + +{% highlight html %} + + +{% endhighlight %} + +Yes. As simple as that. Note now that entry (3) executes before the +`fonts.[client].com` file has even begun downloading. + +

By loading the CSS after our JS, the JS can run much sooner. View full size (29KB)

+ +My second tactic was to pay the connection cost for `fonts.[client].com` +up-front by simply preconnecting to that origin. Early in the ``: + +{% highlight html %} + +{% endhighlight %} + +Note entry (11) in which we’re dealing with a whopping 397ms of connection +overhead off of the Critical Path. + +These two small changes led to a 300ms improvement in Start Render and +a staggering 1,504ms improvement in TTI at the 50th percentile. + +**N.B.** Remember, neither of these changes are solving any of the issues +inherently present in Cloud.typography. All I’m doing here is mitigating the +issues as best I can on the client’s end. + +{% include promo.html %} + +## Solving the Problem for Everyone + +We’re over 1,300 words in and I haven’t even explicitly addressed the crux of +the issue: **Cloud.typography doesn’t give us font performance issues, it gives +us CSS performance issues.** Because the fonts are Base64 encoded, **there are +no fonts**. This means that no amount of `font-display`, Font Loading API, Font +Face Observer, etc. are going to help us. How do we solve this problem at the +source? I got in touch with Cloud.typography. + +### Reaching Out + +Honestly, I started off somewhat confused. With uncacheable, cross-origin +redirects on the Critical Path and Base64 encoded fonts, this seems like a very +slow way of delivering assets. So, naturally, I wanted to check that we weren’t +doing anything wrong. I also wanted to understand the end to end workings of the +solution more thoroughly so I’d be better poised to make recommendations. + +I got the details of a member of the team at Hoefler&Co and asked if I could +send them some questions pertaining to their cloud service. If you’re +interested, you can [read the unedited email in full](https://csswz.it/2Mc8pkt). + +The response I got shed some light on a few things. To summarise: + +* the client was implementing everything correctly; +* the redirect doesn’t ‘release’ the fonts for usage, but actually gathers some + information about your browser and OS and forwards the request to the correct +one of many CSS files that Cloud.typography provide you to [self +host](/2019/05/self-host-your-static-assets/); + * The `Location` of the redirect depends heavily on the User Agent making the + request, so you can’t circumvent the trip to Cloud.typography. + * (Author’s note: But make no mistake, the redirect exists primarily for usage + tracking, otherwise they’d cache it.) +* the cloud service is aimed at developers and agencies who might need access to + a larger library to fulfil many different projects; +* the self-hosted option is aimed at companies who have a limited and + rigidly-defined font palette (think more enterprisey customers); +* anyone concerned about performance is encouraged to upgrade to the self-hosted + plan. + +I’m incredibly grateful for the person’s time and patience—I just popped on +their radar out of nowhere and had quite a barrage of questions and, I’ll admit, +critique for them. Their replies were insightful and timely. + +However, here’s where I end up a little disheartened: despite clearly outlining +the tangible impact that Cloud.typography has on performance, there was no +interest in looking at ways to remedy the problems. There was no appetite for +providing or even documenting the alternative (i.e. not _replacement_—the +current method would remain fully functional and valid) non-blocking loading +strategy. + +I came up with a proof-of-concept alternative loading strategy that didn’t block +rendering, instead opting to load the assets asynchronously in exchange for +a flash of fallback text (FOFT), akin to implementing `font-display: swap;`, +I was told Customers overwhelmingly prefer to not have their pages load +sans-fonts and then “pop” into place with the correct fonts… which, of +course, I, every async font loading strategy, and the entire `font-display`/Font +Loading spec disagree with. + +I ascertained that approximately 13,100 sites in the HTTP Archive currently use +Hoefler&Co’s Cloud.typography service. That’s approximately [$15.5m +a year](https://www.wolframalpha.com/input/?i=$99+*+13100+*+12) worth of +customers currently bound to a slow-by-design, slow-by-default webfont solution +that we could have helped out! + +It’s a real shame, as the solution was trivial and I’d done all the legwork, but +that’s life. + +### The Solution + +To reiterate: **we don’t have a webfont problem, we have a CSS problem**. With +this in mind, the solution to the problem becomes devilishly simple: we just +need to lazy-load our CSS. By lazy-loading our font stylesheet, we move it off +of the Critical Path and unblock rendering. + +Since the advent of Critical CSS, lazy-loading stylesheets has become more and +more commonplace, with [Filament Group’s latest +method](https://www.filamentgroup.com/lab/load-css-simpler/) being by far the +simplest and the most widely supported: + + +{% highlight html %} + +{% endhighlight %} + +The magic lies in the second line. By setting a non-matching media type, the +browser naturally loads the stylesheet with a low priority off of the Critical +Path. Once the file has loaded, the inline `onload` event handler swaps to +a matching media type, and this change then applies the stylesheet to the +document, swapping the fonts in. + +The one caveat to this method is that we do now have a flash of fallback text +(FOFT). This method of loading the stylesheet effectively synthesises +`font-display: swap;`, immediately displaying a fallback typeface and replacing +it with our chosen webfonts as soon as they become available. This means it’s +going to be vital that you design a very robust, accurate fallback style for +users to experience while we’re waiting for the proper fonts to arrive. +Thankfully, [Monica](https://twitter.com/notwaldorf) has made that a lot simpler +by giving us [Font Style Matcher](https://meowni.ca/font-style-matcher/). + +What makes me particularly fond of this method is that **we’ve gone from arguably +the slowest possible method of loading our assets to what might be the least +intrusive**. A complete inversion of the paradigm. + +Here’s a before and after over a 3G connection. The original implementation is +on the left; my fixed version is on the right: + +

+ + +Yes, we do have a FOFT, but we are getting text in front of the reader much, +much sooner—this is an enormous improvement. + +## Closing Thoughts + +I was genuinely disheartened by Cloud.typography’s indifference to the problems, +especially considering the ‘fix’ would only require an update to the +documentation. They wouldn’t have had to make any platform or infrastructure +changes on their side. Further, they would still have been able to retain the +same levels of control and fully track font usage, but completely +asynchronously. It would have also been a great press-piece for them, announcing +the release of a much faster method of including the same beautiful typefaces. + +That said, if you are a Cloud.typography customer, don’t panic. I would +recommend exploring the asynchronous method I’ve outlined above. Implementation +itself should be trivial, but you will need to invest some time in designing +a suitable fallback style while your CSS is loading. + +Specific webfont providers aside, I think this entire situation makes for +a fascinating case study of how things can begin to slide if enough small +mistakes are allowed to consolidate. For me, it was kinda fun to peel back each +layer and see how it impacted the next part of the problem, and I hope my +detailing it has taught people a thing or two in the process. + +If I was to summarise this entire piece with one takeaway, it’s that **CSS +performance is absolutely critical**, and with the current trend of overlooking +and dismissing CSS as its own discipline, cases like this are becoming all too +common. + +**CSS matters. A lot.** diff --git a/_posts/2019-08-15-lazy-pre-browsing-with-prefetch.md b/_posts/2019-08-15-lazy-pre-browsing-with-prefetch.md new file mode 100644 index 00000000..90d56bf2 --- /dev/null +++ b/_posts/2019-08-15-lazy-pre-browsing-with-prefetch.md @@ -0,0 +1,56 @@ +--- +layout: post +title: "Lazy Pre-Browsing with Prefetch" +date: 2019-08-15 14:47:28 +categories: Web Development +meta: "Using prefetch for fun and profit" +toc: false +--- + +I’m working with a client at the moment who, unfortunately, has a blocking third +party stylesheet that’s needed to successfully render one of their site’s key +pages. Until we can design a more long-term solution (and that’s assuming we can +at all) that can asynchronously load the file, I wanted to work out a way to +minimise its impact. + +This is a regular `` that is, necessarily, defined in the +``. This means that from a cold-cache, if a user were to land on this page +for the first time, they’re absolutely going to take a performance hit—there’s +just no way around it. The file needs to make it across the network successfully +before the page can even begin to render. + +The thing is, although this is a key page, it’s not necessarily the first or +only page that a user will visit in a session. In fact, it’s highly likely that +they’ll visit a few other types of page before they encounter this one. This +means that we can take advantage of the fact that users will most likely visit +a different page before this one, and pay the network overhead up-front using +`prefetch`. We might not be able to load the file asynchronously, but until +then, let’s at least attempt to load it from HTTP cache rather than from the +network. + +Defined as: + +> The prefetch link relation type is used to identify a resource that might be +> required by the next navigation, and that the user agent SHOULD fetch, such +> that the user agent can deliver a faster response once the resource is +> requested in the future. + +…this is exactly what `prefetch` is designed for. So nothing groundbreaking +here. But what I wanted to do is very tersely ensure that on pages that _do_ +require the file, we get a Highest priority CSS request, and on pages that _do +not_ need it, we get a Lowest priority request completely off of the Critical +Path. This means we never get slower than the baseline, but hopefully will stand +to get much faster simply by paying off our network overhead early: + +```php + +``` + +Now, the same line of HTML can cover both scenarios without the need for more +intricate workflows. This snippet can remain unchanged in the `` of every +template. + +With this simple addition, I can either take the hit of a fully-blocking, +cross-origin resource when I really need to, or I can lazily load the file and +have it sat waiting in HTTP cache for use when it ultimately gets called up. diff --git a/_posts/2020-01-08-performance-budgets-pragmatically.md b/_posts/2020-01-08-performance-budgets-pragmatically.md new file mode 100644 index 00000000..f1003fde --- /dev/null +++ b/_posts/2020-01-08-performance-budgets-pragmatically.md @@ -0,0 +1,125 @@ +--- +layout: post +title: "Performance Budgets, Pragmatically" +date: 2020-01-08 18:19:10 +categories: Web Development +meta: "If you’ve ever struggled to define performance budgets, this off-the-shelf trick is what you’re looking for." +--- + +One of the key tools that performance engineers have at their disposal is the +Performance Budget: it helps us—or, more importantly, our clients—ensure that +any performance-focused work is monitored and maintained after we’ve gone. + +By establishing an acceptable threshold, be that based on RUM data, bundle +analysis, image weight, milestone timings, or any other suitable metric, we can +be sure that new or unrelated bodies of work do not have a detrimental impact on +the performance of our site. + +The difficulty, however, lies in actually defining those thresholds. This post +is for anyone who has struggled with the question, **But what should our +budgets actually be?!** + +## Targets vs. Safeguards + +When faced with the task of setting a brand new budget, it can feel +daunting—almost paralysing—trying to find a value that is both attainable but +effective. Is it too ambitious? Is it not ambitious enough? Is it going to be +really difficult to hit? Or do we risk making it so easy to achieve that it’s +almost pointless? How do we know? How long will it take to find out? + +Here’s the thing: **most organisations aren’t ready for challenges, they’re in +need of safety nets.** Performance budgets should not be things to work toward, +they should be things that stop us slipping past a certain point. They shouldn’t +be aspirational, they should be preventative. + +Time and again I hear clients discussing their performance budgets in terms of +goals: We’re aiming toward a budget of 250KB uncompressed JavaScript; +we hope to be interactive in 2.75s. While it’s absolutely vital that +these goals exist and are actively worked toward, this is not part of your +budgeting. Your budgeting is actually far, far simpler: + +Our budget for [metric] is never-worse-than-it-is-right-now. + +## The Last Two Weeks + +Whatever monitoring you use (I adore [SpeedCurve](https://speedcurve.com) and +[Treo](https://treo.sh/)), my suggestion for setting a budget for any trackable +metric is to take the worst data point in the past two weeks and use that as +your limit. Load times were 7.2s? You’re not allowed to get any slower than +that. JS size was 478KB? You can’t introduce any more without refactoring what’s +already there. 68 third party requests? You can’t add any more. + +Then, every two weeks, you revisit your monitoring and one of three things can +happen: + +1. **Your new worst-point is better than the last one:** This is the best + outcome! Let’s say you went from a 7.2s load time and now your worst value is + 6.8s—well done! Now your budget gets updated to 6.8s and your job is to not + regress beyond that. +2. **Your new worst-point is the same as the last one:** This is still good + news—we haven’t regressed! But we haven’t improved, either. In this scenario, + we don’t need to do anything. Instead, we just leave the budget as it was and + hope we can continue on the same path. +3. **Your new worst-point is worse than the last one:** Uh oh. This is bad news. + Things have slipped. In this scenario, we do not alter the budget. We can’t + increase budgets unless there is a very valid and agreed reason to do so. + Instead, we double down on solving the problem and getting back on track. + +By constantly revisiting and redefining budgets in two-weekly snapshots, we’re +able to make slow, steady, and incremental improvements. But the key thing to +remember is that we can’t ever increase a performance budget; we can’t change +the test just to make it passable. We can maintain or decrease one, but we can’t +increase it, because that would completely undermine them. + +## Example Performance Budgets + +The following SpeedCurve charts respectively show the Visually Complete, Start +Render, and Fully Loaded budgets for CSS Wizardry over a 3G Galaxy S4 from the +UK. + +### Under Budget + +

Well under budget for Visually Complete every single day. (View full size.)

+ +I’ve set a Visually Complete budget of 3s, but I’m doing far better than that +every single day across the last fortnight. The slowest Start Render in that +period was 2.4s, so I need to update my budget accordingly and maintain the new +maximum for the next two weeks before revisiting once more. + +### On Budget + +

Hitting the Start Render threshold four days out of 14. (View full size.)

+ +With an allotted budget of 2s for Start Render, I find that on most days I am +actually quite nicely under budget, which is great news. That said, on four +occasions I am just nudging the line. This means that I need to be mindful over +the next two weeks, but do not need to update anything. This budget is probably +quite sensibly set as it’s clearly attainable, but is on the verge of needing +some proactive input to keep within the bounds. + +### Over Budget + +

Completely overshooting the Fully Loaded budget every day. (View full size.)

+ +Uh oh. I’m completely overshooting my Fully Loaded time every single day, and +sometimes by up to four seconds. I can’t reset the budget (unless it’s decided +that for some reason 6s was completely incorrect in the first place) but I do +have some work to do. Clearly I have decided that load times are important +enough to be monitored, so I need to roll up my sleeves and get to work fixing +things. + +## Your Turn + +Setting performance budgets doesn’t need to be complex or confusing, you simply +need some existing data, some monitoring, and to remember that budgets and +targets are two different things. Don’t make life difficult by treating +performance budgets as aspirations. diff --git a/_posts/2020-04-22-real-world-effectiveness-of-brotli.md b/_posts/2020-04-22-real-world-effectiveness-of-brotli.md new file mode 100644 index 00000000..9c94796a --- /dev/null +++ b/_posts/2020-04-22-real-world-effectiveness-of-brotli.md @@ -0,0 +1,367 @@ +--- +layout: post +title: "Real-World Effectiveness of Brotli" +date: 2020-04-22 10:28:20 +categories: Web Development +meta: "How effective is Brotli, really?" +--- + +One of the more fundamental rules of building fast websites is to optimise your +assets, and where text content such as HTML, CSS, and JS are concerned, we’re +talking about _compression_. + +The de facto text-compression of the web is Gzip, with around 80% of compressed +responses favouring that algorithm, and the remaining 20% use the much newer +_Brotli_. + +Of course, this total of 100% only measures compressible responses that +actually were compressed—there are still many millions of resources that could +or should have been compressed but were not. For a more detailed breakdown of +the numbers, see the +[_Compression_](https://almanac.httparchive.org/en/2019/compression) section of +the Web Almanac. + +Gzip is tremendously effective. The entire works of Shakespeare weigh in at +5.3MB in plain-text format; after Gzip (compression level 6), that number comes +down to 1.9MB. That’s a 2.8× decrease in file-size with zero loss of data. Nice! + +Even better for us, Gzip favours repetition—the more repeated strings found in +a text file, the more effective Gzip can be. This spells great news for the web, +where HTML, CSS, and JS have a very consistent and repetitive syntax. + +But, while Gzip is highly effective, it’s old; it was released in 1992 (which +certainly helps explain its ubiquity). 21 years later, in 2013, Google launched +Brotli, a new algorithm that claims even greater improvement than Gzip! That +same 5.2MB Shakespeare compilation comes down to 1.7MB when compressed with +Brotli (compression level 6), giving a 3.1× decrease in file-size. Nicer! + +Using Paul Calvano’s [_Gzip and Brotli Compression Level +Estimator!_](https://tools.paulcalvano.com/compression.php), you’re likely to +find that certain files can earn staggering savings by using Brotli over Gzip. +ReactDOM, for example, ends up 27% smaller when compressed with maximum-level +Brotli compression (11) as opposed to with maximum-level Gzip (9). + +

At all compression levels, Brotli always outperforms Gzip when +compressing ReactDom. At Brotli’s maximum setting, it is 27% more effective than +Gzip.

+ +And speaking purely anecdotally, moving a client of mine from Gzip to Brotli led +to a median file-size saving of 31%. + +So, for the last several years, I, along with other performance engineers like +me, have been recommending that our clients move over from Gzip and to Brotli +instead. + +**Browser Support:** A brief interlude. While Gzip is so widely +supported that Can I Use doesn’t even list tables for it (This HTTP header is +supported in effectively all browsers (since IE6+, Firefox 2+, Chrome 1+ +etc)), Brotli currently [enjoys 93.17% worldwide +support](https://caniuse.com/#feat=brotli) at the time of writing, which is +huge! That said, if you’re a site of any reasonable size, serving uncompressed +resources to over 6% of your customers might not sit too well with you. Well, +you’re in luck. The way clients advertise their support for a particular +algorithm works in a completely progressive manner, so users who can’t accept +Brotli will simply fall back to Gzip. More on this later. + +For the most part, particularly if you’re using a CDN, enabling Brotli should +just be the flick of a switch. It’s certainly that simple in Cloudflare, who +I run CSS Wizardry through. However, a number of clients of mine in the past +couple of years haven’t been quite so lucky. They were either running their own +infrastructure and installing and deploying Brotli everywhere proved +non-trivial, or they were using a CDN who didn’t have readily available support +for the new algorithm. + +In instances where we were unable to enable Brotli, we were always left +wondering What if… So, finally, I’ve decided to attempt to quantify the +question: **how important is it that we move over to Brotli?** + +## Smaller Doesn’t Necessarily Mean Faster + +Usually, sure! Making a file smaller will make it arrive sooner, generally +speaking. But making a file, say, 20% smaller will not make it arrive 20% +earlier. This is because file-size is only one aspect of web performance, and +whatever the file-size is, the resource is still sat on top of a lot of other +factors and constants—latency, packet loss, etc. Put another way, file-size +savings help you to cram data into lower bandwidth, but if you’re latency-bound, +the speed at which those admittedly fewer chunks of data arrive will not change. + +### TCP, Packets, and Round Trips + +Taking a very reductive and simplistic view of how files are transmitted from +server to client, we need to look at TCP. When we receive a file from a sever, +we don’t get the whole file in one go. TCP, upon which HTTP sits, breaks the +file up into segments, or _packets_. Those packets are sent, in batches, in +order, to the client. They are each acknowledged before the next series of +packets is transferred until the client has all of them, none are left on the +server, and the client can reassemble them into what we might recognise as +a file. Each batch of packets gets sent in a round trip. + +Each new TCP connection has no way of knowing what bandwidth it currently has +available to it, nor how reliable the connection is (i.e. packet loss). If the +server tried to send a megabyte’s worth of packets over a connection that only +has capacity for one megabit, it’s going to flood that connection and cause +congestion. Conversely, if it was to try and send one megabit of data over +a connection that had one megabyte available to it, it’s not gaining full +utilisation and lots of capacity is going to waste. + +To tackle this little conundrum, TCP utilises a mechanism known as _slow start_. +Each new TCP connection limits itself to sending just 10 packets of data in its +first round trip. Ten TCP segments equates to roughly 14KB of data. If those ten +segments arrive successfully, the next round trip will carry 20 packets, then +40, 80, 160, and so on. This exponential growth continues until one of two +things happens: + +1. we suffer packet loss, at which point the server will halve whatever the last + number of attempted packets were and retry, or; +2. we max out our bandwidth and can run at full capacity. + +This simple, elegant strategy manages to balance caution with optimism, and +applies to every new TCP connection that your web application makes. + +Put simply: your initial bandwidth capacity on a new TCP connection is only +about 14KB. Or roughly 11.8% of uncompressed ReactDom; 36.94% of Gzipped +ReactDom; or 42.38% of Brotlied ReactDom (both set to maximum compression). + +Wait. The leap from 11.8% to 36.94% is pretty notable! But the change from +36.94% to 42.38% is much less impressive. What’s going on? + +| Round Trips | TCP Capacity (KB) | Cumulative Transfer (KB) | ReactDom Transferred By… | +|------------:|------------------:|-------------------------:|------------------------------------| +| 1 | 14 | 14 | | +| 2 | 28 | 42 | Gzip (37.904KB), Brotli (33.036KB) | +| 3 | 56 | 98 | | +| 4 | 112 | 210 | Uncompressed (118.656KB) | +| 5 | 224 | 434 | | + +Both the Gzipped and Brotlied versions of ReactDom fit into the same round-trip +bucket: just two round trips to get the full file transferred. If all round trip +times (RTT) are fairly uniform, this means there’s no difference in transfer +time between Gzip and Brotli here. + +The uncompressed version, on the other hand, takes a full two round trips more +to be fully transferred, which—particularly on a high latency connection—could +be quite noticeable. + +The point I’m driving at here is that it’s not just about file-size, it’s about +TCP, packets, and round trips. **We don’t just want to make files smaller, we +want to make them meaningfully smaller, nudging them into lower round trip +buckets.** + +This means that, in theory, for Brotli to be notably more effective than Gzip, +it will need to be able to compress files quite a lot more aggressively so as to +move it beneath round trip thresholds. I’m not sure how well it’s going to stack +up… + +It’s worth noting that this model is quite aggressively simplified, and +there are myriad more factors to take into account: is the TCP connection new or +not, is it being used for anything else, is server-side prioritisation +stop-starting transfer, do H/2 streams have exclusive access to bandwidth? This +section is a more academic assessment and should be seen as a good jump-off +point, but consider analysing the data properly in something like Wireshark, and +also read [Barry Pollard](https://twitter.com/tunetheweb)’s far more forensic +analysis of the magic 14KB in his [_Critical Resources and the First 14 KB +– A Review_](https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/). + +This rule also only applies to brand new TCP connections, and any files fetched +over primed TCP connections will not be subject to slow start. This brings forth +two important points: + +1. Not that it should need repeating: you need to [**self-host your static + assets**](/2019/05/self-host-your-static-assets/). + This is a great way to avoid a slow start penalty, as using your own + already-warmed up origin means your packets have access to greater bandwidth, + which brings me to point two; +2. With exponential growth, you can see just how quickly we reach relatively + massive bandwidths. The more we use or reuse connections, the further we can + increase capacity until we top out. Let’s look at a continuation of the above + table… + +| Round Trips | TCP Capacity (KB) | Cumulative Transfer (KB) | +|------------:|------------------:|-------------------------:| +| 1 | 14 | 14 | +| 2 | 28 | 42 | +| 3 | 56 | 98 | +| 4 | 112 | 210 | +| 5 | 224 | 434 | +| 6 | 448 | 882 | +| 7 | 896 | 1,778 | +| 8 | 1,792 | 3,570 | +| 9 | 3,584 | 7,154 | +| 10 | 7,168 | 14,322 | +| … | … | … | +| 20 | 7,340,032 | 14,680,050 | + +By the end of 10 round trips, we have a TCP capacity of 7,168KB and have already +transferred a cumulative 14,322KB. This is more than adequate for casual web +browsing (i.e. not ~~torrenting~~ streaming Game of Thrones). In actual fact, +what usually happens here is that we end up loading the entire web page and all +of its subresources before we even reach the limit of our bandwidth. Put another +way, your 1Gbps[^1] fibre line won’t make your day-to-day browsing feel much +faster because most of it isn’t even getting used. + +By 20 round trips, we’re theoretically hitting a capacity of 7.34GB. + +## What About the Real World? + +Okay, yeah. That all got a little theoretical and academic. I started off this +whole train of thought because I wanted to see, realistically, what impact +Brotli might have for real websites. + +The numbers so far show that the difference between no compression and Gzip are +vast, whereas the difference between Gzip and Brotli are far more modest. This +suggests that while the _nothing to Gzip_ gains will be noticeable, the upgrade +from Gzip to Brotli might perhaps be less impressive. + +I took a handful of example sites in which I tried to cover sites that were +a good cross section of: + +* relatively well known (it’s better to use demos that people can + contextualise), and/or; +* relevant and suitable for the test (i.e. of a reasonable size (compression is + more relevant) and not formed predominantly of non-compressible content + (like, for example YouTube)), and/or; +* not all multi-billion dollar corporations (let’s use some normal case studies, + too). + +With those requirements in place, I grabbed [a selection of +origins](https://twitter.com/csswizardry/status/1252174092180037633) and began +testing: + +* m.facebook.com +* www.linkedin.com +* www.insider.com +* yandex.com +* www.esedirect.co.uk +* www.story.one +* www.cdm-bedrijfskleding.nl +* www.everlane.com + +I wanted to keep the test simple, so I grabbed only: + +* data transferred, and; +* First contentful paint (FCP) times; +* without compression; +* with Gzip, and; +* with Brotli. + +FCP feels like a real-world and universal enough metric to apply to any site, +because that’s what people are there for—content. Also because [Paul +Calvano](https://twitter.com/paulcalvano) said so, and he’s smart: Brotli +tends to make FCP faster in my experience, especially when the critical CSS/JS +is large. + +### Running the Tests + +Here’s a bit of a dirty secret. A lot of web performance case studies—not all, +but a lot—aren’t based on improvements, but are often extrapolated and inferred +from the opposite: slowdowns. For example, it’s much simpler for the BBC to say +that they lose an [additional 10% of +users](https://wpostats.com/2017/03/03/bbc-load-abandonment.html) for every +additional second it takes for their site to load than it is to work out +what happens for a 1s speed-up. It’s much easier to make a site slower, which is +why so many people seem to be so good at it. + +With that in mind, I didn’t want to find Gzipped sites and then try and somehow +Brotli them offline. Instead, I took Brotlied websites and turned off Brotli. +I worked back from Brotli to Gzip, then Gzip to to nothing, and measured the +impact that each option had. + +Although I can’t exactly hop onto LinkedIn’s servers and disable Brotli, I can +instead choose to request the site from a browser that doesn’t support Brotli. +And although I can’t exactly disable Brotli in Chrome, I can hide from the +server the fact that Brotli is supported. The way a browser advertises its +accepted compression algorithm(s) is via the `content-encoding` request header, +and using WebPageTest, I can define my own. Easy! + +

WebPageTest’s advanced feature allows us to set custom request +headers.

+ +* To disable compression entirely: `accept-encoding: randomstring`. +* To disable Brotli but use Gzip instead: `accept-encoding: gzip`. +* To use Brotli if it’s available (and the browser supports it): leave blank. + +I can then verify that things worked as planned by checking for the +corresponding (or lack of) `content-encoding` header in the response. + +## Findings + +As expected, going from nothing to Gzip has massive reward, but going from Gzip +to Brotli was far less impressive. The raw data is available in [this Google +Sheet](https://docs.google.com/spreadsheets/d/18A_dP1DuavmMjmFnHXf4gdw6ThTne5e6UyzUUgxKI5s/edit?usp=sharing), +but the things we mainly care about are: + +* Gzip size reduction vs. nothing: 73% decrease +* Gzip FCP improvement vs. nothing: 23.305% decrease +* Brotli size reduction vs. Gzip: 5.767% decrease +* Brotli FCP improvement vs. Gzip: 3.462% decrease + +All values are median; ‘Size’ refers to HTML, CSS, and JS only. + +Gzip made files 72% smaller than not compressing them at all, but Brotli only +saved us an additional 5.7% over that. In terms of FCP, Gzip gave us a 23% +improvement when compared to using nothing at all, but Brotli only gained us an +extra 3.5% on top of that. + +While the results to seem to back up the theory, there are a few ways in which +I could have improved the tests. The first would be to use a much larger sample +size, and the other two I shall outline more fully below. + +## First-Party vs. Third-Party + +In my tests, I disabled Brotli across the board and not just for the first party +origin. This means that I wasn’t measuring solely the target’s benefits of using +Brotli, but potentially all of their third parties as well. This only really +becomes of interest to us if a target site has a third party on their critical +path, but it is worth bearing in mind. + +## Compression Levels + +When we talk about compression, we often discuss it in terms of best-case +scenarios: level-9 Gzip and level-11 Brotli. However, it’s unlikely that your +web server is configured in the most optimal way. Apache’s default Gzip +compression level is 6, but Nginx is set to just 1. + +Disabling Brotli means we fall back to Gzip, and given how I am testing the +sites, I can’t alter or influence any configurations or fallbacks’ +configurations. I mention this because two sites in the test actually got larger +when we enabled Brotli. To me this suggests that their Gzip compression level +was set to a higher value than their Brotli level, making Gzip more effective. + +Compression levels are a trade-off. Ideally you’d like to set everything to the +highest setting and be done, but that’s not really practical—the time taken on +the server to do that dynamically would likely nullify the benefits of +compression in the first place. To combat this, we have two options: + +1. **use a pragmatic compression level** that balances speed and effectiveness + when dynamically compressing assets, or; +2. **upload precompressed static assets** with a much higher compression level, + and use the first option for dynamic responses. + +## So What? + +It would seem that, realistically, the benefits of Brotli over Gzip are slight. + +If enabling Brotli is as simple as flicking a checkbox in the admin panel of +your CDN, please go ahead and do it right now: support is wide enough, fallbacks +are simple, and even minimal improvements are better than none at all. + +Where possible, upload precompressed static assets to your web server with the +highest possible compression setting, and use something more middle-ground for +anything dynamic. If you’re running on Nginx, please ensure you aren’t still on +their pitiful default compression level of 1. + +However, if you’re faced with the prospect of weeks of engineering, test, and +deployment efforts to get Brotli live, don’t panic too much—just make sure you +have Gzip on everything that you can compress (that includes your `.ico` and +`.ttf` files, if you have any). + +I guess the short version of the story is that if you haven’t or can’t enable +Brotli, you’re not missing out on much. + +[^1]: That 1Gbps you’re getting sold actually equates to 0.125GBps. ISPs hide their false advertising in plain sight. diff --git a/_posts/2020-05-19-the-fastest-google-fonts.md b/_posts/2020-05-19-the-fastest-google-fonts.md new file mode 100644 index 00000000..b064ff5f --- /dev/null +++ b/_posts/2020-05-19-the-fastest-google-fonts.md @@ -0,0 +1,650 @@ +--- +layout: post +title: "Speed Up Google Fonts" +date: 2020-05-19 17:35:04 +categories: Web Development +main: "https://csswizardry.com/wp-content/uploads/2020/05/filmstrip-foit.png" +meta: "Google Fonts is fast. Now it’s faster. Much faster." +--- + +

+ +

Ten-Second Version: If you really can’t +be bothered going to all of the effort outlined in this post, there is a super +rough-and-ready, ten-second, alternative approach—place your Google +Fonts stylesheet at the closing </body> tag. This +means we don’t block rendering of the entire page just for the sake of web +fonts. Instead, we apply them after we’ve styled everything else.

+ +

Please note that this may have side-effects. If you want to be very +thorough, keep reading…

+ +

+ +_Third parties getting you down? [Read +more](/2018/05/identifying-auditing-discussing-third-parties/) or [hire +me](/consultancy/)._ + +For the most part, web fonts nowadays are faster than ever. With more +standardised FOUT/FOIT behaviour from browser vendors, to the newer +`font-display` specification, performance—and therefore the user—seems to have +been finally been put front-and-centre. + +It’s widely accepted that self-hosted fonts are the fastest option: same origin +means reduced network negotiation, predictable URLs mean we can `preload`, +self-hosted means we can set our own [`cache-control` +directives](/2019/03/cache-control-for-civilians/), and +full ownership mitigates [the risks that come with leaving static assets on +third-party +origins](/2019/05/self-host-your-static-assets/). + +That said, the convenience of a service like Google Fonts cannot be overstated. +Their ability to serve the tiniest possible font files tailored to specific user +agents and platforms is amazing, and with such a huge, freely-available library +served from Google-grade CDNs… I definitely see why people continue to turn to +it. + +On this site, in which performance is the only name of the game, I forgo web +fonts entirely, opting instead to make use of the visitor’s system font. This is +fast, incredibly well suited to the device in question, and has almost zero +engineering overhead. But, on [harry.is](https://harry.is), I really wanted to +throw caution to the wind. To hell with it! Let’s have a web font! + +However, I still needed it to be fast. + +While prototyping, I turned to Google Fonts, and with their recent ability to +support `font-display` via a URL parameter (`&display=swap`), I knew that things +would stay pretty speedy. Then I had an idea. + +It started with [a tweet](https://twitter.com/csswizardry/status/1259790019067351045): + +> TIP: If you’re going to use `font-display` for your Google Fonts then it makes +> sense to asynchronously load the whole request chain. +> — [@csswizardry](https://twitter.com/csswizardry/status/1259790019067351045) + +While `font-display: swap;` is a huge win, there are still a lot of things +leaving me feeling uneasy. What else could I do to make Google Fonts _fast_? + +Suffice to say, I ended up going down a little rabbit hole… + +## Testing + +{% include promo.html %} + +I ran the same suite of tests against the [harry.is](https://harry.is) and +[csswizardry.com](/) homepages. I started out with +harry.is because that’s where I was using Google Fonts, but I felt it was a page +too simple to be realistic. So, I cloned the CSS Wizardry homepage a bunch of +times and implemented the various different methods there. For each section of +this post, I will list the results for both sites. My variants are: + +* **Legacy:** Google Fonts with no `font-display`. +* **`font-display: swap;`:** Using Google Fonts’ new default. +* **Async CSS:** Loading the Google Fonts File asynchronously. +* **`preload`:** `preload`ing the CSS file to increase its priority. +* **[`preconnect`](/2023/12/correctly-configure-preconnections/):** Warming up + the `fonts.gstatic.com` origin myself. + +Further, each variant is additive—it includes the previous variant as well as +its own additions. I didn’t try _just_ `preload` or _just_ async, because it +would be pointless—we know that a combination will fare better than any on their +own. + +For each test, I captured the following metrics: + +* **First Paint (FP):** To what extent is the critical path affected? +* **First Contentful Paint (FCP):** How soon can we actually read something, + whether it’s a web font or not? +* **First Web Font (FWF):** At what point has the first web font loaded? +* **Visually Complete (VC):** When has everything settled down (a proxy, but not + equivalent to, Last Web Font)? +* **Lighthouse Score:** Does it even count if it wasn’t on Lighthouse? + +**N.B.** All tests were conducted using a private WebPageTest instance +(WebPageTest is down right now so I was unable to use the public instance, which +means I can’t share any URLs—apologies). The specific profile was a Samsung +Galaxy S4 over 3G. + +To make the snippets easier to read, I’m going to replace all instances of +`https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,400;0,700;1,400;1,700` +with `$CSS`. + +## Default/Legacy + +Google Fonts played a really great move in the last year or so. By default, any +newly created Google Font snippet comes with the `&display=swap` parameter that +injects `font-display: swap;` into all of the `@font-face` at-rules. The value +of the parameter can be any of `swap`, `optional`, `fallback`, or `block`. You +can [read more on +MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display). + +For my baseline, however, I was going to trim the `font-display` back off. This +is the legacy format that a lot of sites will likely still use, and it makes for +a more suitable baseline to compare against. + +**Snippet:** + +{% highlight html %} + +{% endhighlight %} + +There are two key issues here: + +1. A synchronous, ergo render-blocking, CSS file on a third-party origin. +2. A file containing `@font-face` at-rules with no `font-display` descriptors. + +It’s synchronous on top of synchronous—not good. + +**Results (s) – harry.is:** + +| FP | FCP | FWF | VC | Lighthouse | +|----:|----:|----:|----:|-----------:| +| 3.4 | 4.6 | 4.9 | 5.0 | 98 | + +**Results (s) – CSS Wizardry:** + +| FP | FCP | FWF | VC | Lighthouse | +|----:|----:|----:|----:|-----------:| +| 3.4 | 4.3 | 4.4 | 4.4 | 96 | + +Alright. Here’s our baseline. The Google Fonts file is the only render-blocking +external resource either of the two tests has, and we can see they both have the +exact same first paint. One thing I was happily surprised by during these +experiments was the consistency of Google Fonts. + +At this point, Lighthouse is giving one error and one warning: + +* (Error) Ensure text remains visible during webfont load +* (Warning) Eliminate render-blocking resources + +The first is a result of not having a web font loading solution (e.g. +`font-display`); the second is a result of the synchronous Google Fonts CSS +file. + +Now, let’s start adding some progressive changes and, hopefully, improvements. + +## `font-display: swap;` + +For this test, I added the `&display=swap` back in. In effect, this makes the +font files themselves asynchronous—the browser immediately displays our fallback +text before `swap`ping to the web font whenever it arrives. This means we’re not +going to leave users looking at any invisible text (FOIT), which makes for both +a faster and more pleasant experience. + +**N.B.** It’s only more pleasant if you make the effort to define a suitable +fallback to display in the interim—flashing a page full of Times New Roman +before settling on Open Sans would likely be a net worse experience. Thankfully, +[Monica](https://twitter.com/notwaldorf) has made this process not only easy, +but surprisingly fun. I wouldn’t be able to do this bit without her [_Font Style +Matcher_](https://meowni.ca/font-style-matcher/). + +**Snippet:** + +{% highlight html %} + +{% endhighlight %} + +**Results – harry.is:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|----:|-----:|-----:|-----:|-----------:| +| | 3.4 | 3.4 | 4.5 | 5.2 | 99 | +| Change from Baseline: | 0 | −1.2 | −0.4 | +0.2 | +1 | + +**Results – CSS Wizardry:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|-----:|-----:|-----:|-----:|-----------:| +| | 3.6 | 3.6 | 4.6 | 4.6 | 95 | +| Change from Baseline: | +0.2 | −0.7 | +0.2 | +0.2 | −1 | + +We haven’t removed any +[render-blocking](/2024/08/blocking-render-why-whould-you-do-that/) resources +from the critical path, so I wasn’t expecting to see any improvements in first +paint. In fact, while harry.is remained identical, CSS Wizardry got 200ms +slower. What we do see, however, is **a dramatic improvement in first contentful +paint**—over a second on harry.is! **First web font improved on harry.is**, but +not on csswizardry.com. Visually complete was 200ms slower. + +I’m happy to say, for the metrics that matter the most, **we are 700–1,200ms +faster**. + +While this does massively improve the time it takes the web font to render, it’s +still defined inside a synchronous CSS file—we can only expect so much +improvement from this move. + +Predictably, Lighthouse now only gives one warning: + +* (Warning) Eliminate render-blocking resources + +Therefore, the next step is to solve the synchronous CSS file. + +To quote, err, myself: If you’re going to use `font-display` for your Google +Fonts then it makes sense to asynchronously load the whole request chain. It +was this initial thought that led to my tweet in the first place—if I’ve +effectively made the contents of the CSS file asynchronous, then it kinda sucks +to leave the CSS file itself fully synchronous. + +**`font-display: swap;` is a good idea.** + +## Async CSS + +Making your CSS asynchronous is one of the key techniques involved in employing +Critical CSS. While there are a number of ways to achieve this, I’d dare say the +simplest and most ubiquitous is [Filament Group’s print media type +trick](https://www.filamentgroup.com/lab/load-css-simpler/). + +This will implicitly tell the browser to load the CSS file in a non-blocking +fashion, applying the styles only to the `print` context. However, the moment the +file arrives, we tell the browser to apply it to `all` contexts, thus styling +the rest of the page. + +**Snippet:** + +{% highlight html %} + +{% endhighlight %} + +While the trick is devilishly simple—which is what makes it so cool—**I’ve long +had my reservations**. Y’see, a regular, synchronous stylesheet blocks +rendering, so a browser will assign it _Highest_ priority. A print stylesheet +(or any stylesheet that doesn’t match the current context) is assigned the +priority at the complete opposite end of the spectrum: _Idle_. + +This means that as browsers begin making requests, the asynchronous CSS file +often gets grossly under-prioritised (or rather, it’s prioritised correctly, but +probably way less than you expect). Take for example Vitamix, a client for whom +I implemented asynchronous CSS for their own font provider(s): + +

While Chrome can do asynchronous DNS/TCP/TLS, it will serialise and +stall non-critical requests on slower connections.

+ +The browser is doing exactly what we told it: request these CSS files with +a print-stylesheet’s worth of priority. Thus, on a 3G connection, it takes over +nine seconds to download each file. The browser puts almost everything else, +including in-`body` resources, ahead of our print stylesheets. This means that +the page in question didn’t render its custom font until an eyewatering 12.8s on +3G. + +Thankfully, while dealing with web fonts, this isn’t the end of the world: + +* they should always be considered an enhancement anyway, so we need to be able + to cope without them; +* we can and should design decent fallbacks for use during their absence, and; +* if we expect delays of such severity, we should use `font-display: optional;`. + +For below the fold CSS, however, delays of almost 10 seconds are +unacceptable—it’s almost 100% certain that a user will have scrolled within that +timeframe. + +Still! What happens to Google Fonts if we load it asynchronously? + +**Results – harry.is:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|-----:|-----:|-----:|-----:|-----------:| +| | 1.8 | 1.8 | 4.5 | 5.1 | 100 | +| Change from Baseline: | −1.6 | −2.8 | −0.4 | +0.1 | +2 | +| Change from Previous: | −1.6 | −1.6 | 0 | −0.1 | +1 | + +**Results – CSS Wizardry:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|-----:|-----:|-----:|-----:|-----------:| +| | 1.7 | 2.2 | 4.9 | 5.0 | 99 | +| Change from Baseline: | −1.7 | −2.1 | +0.5 | +0.6 | +3 | +| Change from Previous: | −1.9 | −1.4 | +0.3 | +0.4 | +4 | + +**These results are tremendous.** + +I’m really happy with these outcomes. **First paint was a staggering 1.6–1.7s +improvement** on our baseline, and **up to a 1.9s improvement on the previous +variant** in the case of CSS Wizardry. **First contentful paint was improved as +much as 2.8s** against our baseline, and **Lighthouse scores hit 100** for the +first time. + +As far as the critical path is concerned, this was a huge win. + +However—and this is a big _however_—as a result of lowering the priority of the +CSS file, our **first web font is up to 500ms slower** in the case of CSS +Wizardry against our baseline. This is the danger of the print media hack. + +Asynchronously loading Google Fonts is a net good idea, but reducing the +priority of the CSS file has actually slowed down the rendering of our custom +font. + +**I’m going to say that asynchronous CSS is an overall good idea but I need to +somehow mitigate the priority issue.** + +## `preload` + +Okay, so if print CSS is _too_ low priority, what we need is a high priority +asynchronous fetch. Enter `preload`. + +Complementing our media-trick stylesheet with a `preload` ensures we get the +best of all worlds: + +1. an asynchronous high priority fetch that will work in almost all modern + browsers, and; +2. a very widely supported method for reapplying CSS that we loaded + asynchronously. + +**N.B.** We can’t go full `preload` as it isn’t widely enough supported. In +fact, at the time of writing, about 20% of this site’s visitors would be unable +to make use of it. Consider the print stylesheet a fallback. + +**Snippet:** + +{% highlight html %} + + + +{% endhighlight %} + +**N.B.** In future, we should be able to use Priority Hints to solve this issue. + +**Results – harry.is:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|-----:|-----:|-----:|-----:|-----------:| +| | 1.8 | 1 .8 | 4.5 | 5.3 | 100 | +| Change from Baseline: | −1.6 | −2.8 | −0.4 | +0.3 | +2 | +| Change from Previous: | 0 | 0 | 0 | +0.2 | 0 | + +**Results – CSS Wizardry:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|-----:|-----:|-----:|-----:|-----------:| +| | 2.0 | 2.0 | 4.3 | 4.3 | 98 | +| Change from Baseline | −1.4 | −2.3 | −0.1 | −0.1 | +2 | +| Change from Previous | +0.3 | −0.2 | −0.6 | −0.7 | −1 | + +While first paint either remained the same or got slower, **first contentful +paint either remained the same or got faster**, and in the case of CSS Wizardry, +**first web font was a staggering 600ms faster** than the previous iteration. + +In the case of harry.is, almost nothing changed since our previous variant. +**Visually complete was 200ms faster**, but any first- metrics were untouched. +It was seeing these results that actually spurred me to also test against CSS +Wizardry. Because harry.is is such a small and simple page, there wasn’t much +network contention for a print stylesheet to yield to—changing its priority +didn’t really help it out much at all. + +In the case of CSS Wizardry, we see first paint 300ms slower, which is +unexpected but unrelated (there is no render blocking CSS, so changing the +priority of an asynchronous CSS file can have no bearing here—I’m going to chalk +it up to an anomaly in testing). Happily, **first contentful paint improved by +200ms**, **first web font was 600ms faster**, and **visually complete was 700ms +faster**. + +**`preload`ing Google Fonts is a good idea.** + +## `preconnect` + +The last piece of the puzzle I wanted to solve the trip to yet-another origin. +While we link out to `fonts.googleapis.com` for our CSS, the font files +themselves are hosted on `fonts.gstatic.com`. On a high-latency connection, this +spells bad news. + +Google Fonts are good to us—they `preconnect` the `fonts.gstatic.com` origin +preemptively via an HTTP header attached to the `fonts.googleapis.com` response: + +

While not all that effective in these demos, I wish more third-party +providers would do things like this.

+ +However, the execution of this header is bound by the response’s TTFB, which on +high-latency networks can be very, very high. The median TTFB (including request +queueing, DNS, TCP, TLS, and server time) for the Google Fonts CSS file across +all tests was 1406ms. Conversely, the median download time for the CSS file was +just 9.5ms—it took 148× longer to get to the headers of the file than it did to +download the file itself. + +Put another way: even though Google are `preconnect`ing the `fonts.gstatic.com` +origin for us, they’re only gaining about a 10ms head-start. Put another-other +way, this file is [latency-bound, not +bandwidth-bound](/2019/01/bandwidth-or-latency-when-to-optimise-which/). + +If we implement a first-party `preconnect`, we should stand to make some pretty +huge gains. Let’s see what happens. + +**Snippet:** + +{% highlight html %} + + + + + +{% endhighlight %} + +We can visualise the benefits well in WebPageTest: + +

See just how much we can bring connection overhead forward with +`preconnect`.

+ +**Results – harry.is:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|-----:|-----:|-----:|-----:|-----------:| +| | 1.8 | 1.8 | 3.8 | 4.4 | 100 | +| Change from Baseline | −1.6 | −2.8 | −1.1 | −0.6 | +2 | +| Change from Previous | 0 | 0 | −0.7 | −0.9 | 0 | + +**Results – CSS Wizardry:** + +| | FP | FCP | FWF | VC | Lighthouse | +|-----------------------|-----:|-----:|-----:|-----:|-----------:| +| | 1.9 | 1.9 | 3.5 | 3.6 | 99 | +| Change from Baseline | −1.5 | −2.4 | −0.9 | −0.8 | +3 | +| Change from Previous | −0.1 | −0.1 | −0.8 | −0.7 | +1 | + +Here we go! First (contentful) paint is realistically untouched. Any changes +here are unrelated to our `preconnect` as the `preconnect` only impacts +resources after the critical path. Our focus is on first web font and visually +complete, both of which show tremendous improvement. **700–1,200ms improvement +on first web font** and **700–900ms improvement on visually complete** against +our previous variant, and **600–900ms and 600–800ms respective improvements** +against our baseline. **Lighthouse scores are sitting pretty at 100 and 99.** + +**`preconnect`ing `fonts.gstatic.com` is a good idea.** + +## Bonus: `font-display: optional;` + +Using asynchronous CSS and `font-display` leaves us susceptible to FOUT (or, +hopefully, FOFT if we’ve designed our Fallbacks properly). To try and +mitigate this, I decided to run a test using `font-display: optional;`. + +This variation tells the browser that web fonts are considered optional, and if +we can’t get hold of the font files during our extremely small block +period then we offer no swap period. The practical upshot of which is +that in the event that the web fonts takes too long to load, that pageview won’t +utilise it at all. This helps to prevent the FOUT which will in turn lead to +a more stable experience for your user—they won’t see text restyle part-way +through their pageview—and a better Cumulative Layout Shift score. + +However, this proved consistently troublesome when using asynchronous CSS. When +the `print` stylesheet gets turned into an `all` stylesheet, the browser updates +the CSSOM then applies it against the DOM. In this moment, the page is told it +needs some web fonts, and the extremely small block period kicks in, +showing a FOIT midway through the page load lifecycle. To make things worse, the +browser will replace the FOIT with the same fallback it started with, so the +user doesn’t even get the benefit of a new font. It basically looks like a bug. + +It’s much easier to visualise it than it is to explain, so here’s a screenshot +of the filmstrip: + +

Screenshot
+showing missing text midway through two separate page loads. — Note the FOIT at 3.4–3.5s and 3.2s respectively.

+ +And a video showing the issue in DevTools: + +

+Can’t see the +video? Click here. +

+ + +**I would not recommend using `font-disply: optional;` alongside asynchronous +CSS**; I would recommend using asynchronous CSS. Ergo, I would not recommend +`font-display: optional;`. It’s better overall to have non-blocking CSS with +a FOUT than it is to have the needless FOIT. + +## Comparisons and Visualisations + +In these slow-motion videos, you can see the differences quite clearly. + +**harry.is** + +

Can’t see +the video? Click here.

+ + +* Async, `preload`, and `preconnect` all start rendering at 1.8s. + * This also represents their first contentful paints—useful information in the + first render. +* Legacy and `swap` both start rendering at 3.4s. + * Though legacy is missing any text—FOIT. +* `preconnect` loads its web font at 3.8s. + * It’s deemed visually complete at 4.4s. +* Legacy makes its first contentful and first web font paint at 4.5s. + * They’re one and the same as everything is synchronous. +* Legacy’s visually complete is at 5s. +* Async’s visually complete comes in at 5.1s. +* `swap` is deemed complete at 5.2s. +* `preload` is deemed visually complete at 5.3s. + +**CSS Wizardry** + +

+Can’t +see the video? Click here. +

+ + +* Async starts rendering at 1.7s. +* `preconnect` starts rendering at 1.9s. + * Its first contentful paint is also 1.9s—useful information in the first + render. +* `preload` starts rendering at 2s. + * Its first contentful paint is also at 2s. +* Async renders content at 2.2s. +* Legacy starts rendering at 3.4s. +* `swap` makes it first- and first contentful paint at 3.6s. +* `preconnect` is deemed visually complete at 3.6s. +* Legacy makes its first contentful paint at 4.3s. +* `preload` is visually complete at 4.3s. +* Legacy is considered visually complete at 4.4s. +* `swap` completes at 4.6s. +* Async comes in last at 5s. + +**`preconnect` is fastest across all metrics** + +## Findings + +While self-hosting your web fonts is likely to be the overall best solution to +performance and availability problems, we’re able to design some fairly +resilient measures to help mitigate a lot of these issues when using Google +Fonts. + +A combination of asynchronously loading CSS, asynchronously loading font files, +opting into FOFT, fast-fetching asynchronous CSS files, and warming up external +domains makes for an experience several seconds faster than the baseline. + +**This is something that I strongly recommend adopting if you are a Google Fonts +user.** + +If Google Fonts isn’t your only render-blocking resource, and if you’re +violating any of the other [principles for fast +CSS](/2018/11/css-and-network-performance/) (e.g. if +you’re `@import`ing your Google Fonts CSS file), then your mileage will vary. +These optimisations are most beneficial on project where Google Fonts is posing +one of your biggest performance bottlenecks. + +## Google Fonts Async Snippet + +There a lot of techniques combined here, but the resulting code is still slim +and maintainable enough that it should’t pose a problem. The snippet doesn’t +need breaking apart and can all be kept together in the `` of your +document. + +Here is the optimum snippet to use for fast Google Fonts: + +{% highlight html %} + + + + + + + + + + + + + +{% endhighlight %} diff --git a/_posts/2020-11-03-site-speed-topography.md b/_posts/2020-11-03-site-speed-topography.md new file mode 100644 index 00000000..5112dd14 --- /dev/null +++ b/_posts/2020-11-03-site-speed-topography.md @@ -0,0 +1,258 @@ +--- +layout: post +title: "Site-Speed Topography" +date: 2020-11-03 23:04:10 +categories: Web Development +main: "https://res.cloudinary.com/csswizardry/image/fetch/f_auto,q_auto/https://csswizardry.com/wp-content/uploads/2020/10/milestones-chart.png" +meta: "Learning the lay of the land" +--- + +

N.B. On 6 June, 2023, I published an +updated version of this article. I would encourage you to read Site-Speed Topography +Remapped after this.

+ +A couple of years ago, my first few days on a new web performance project were +always slow going. So many false starts, tedious workflows, and a complete lack +of efficiency really made it difficult for me to find momentum. All through no +fault of the client or the project, but through huge flaws in my own approach. +In a bid to address this, I introduced a new tool into my arsenal so that +I could hit the ground running much faster, and get answers to my clients much +sooner. + +When first working on a new site-speed engagement, you need to work out quickly +where the slowdowns, blindspots, and inefficiencies lie. Unless a client hires +you to specifically improve the performance of one page, you’ll need a broad +view of the whole site or application. Historically, I’d maybe look at Google +Analytics—or a RUM solution if the client had one already—but this is only +useful for showing me particular outliers, and not necessarily any patterns +across the whole project. + +

See entry 6. Google Analytics can show us individual slow pages, but +doesn’t necessarily help us build a bigger picture of the site as a whole.

+ +Not only that, but Google Analytics, by default, only reports load times, which +are now almost entirely redundant in the field of performance optimisation. + +I needed a more holistic way to visualise performance across an entire site, +and—ideally—something more useful than load times. + +## Identify Page Types + +Visualising a whole site is a little overkill, especially considering +many sites may run to the tens of thousands of pages. Instead, what we can do +for almost every site in the world is split the project into page types. These +page types would also typically correspond to different templates in the +codebase. For example, my site has a homepage, content pages (e.g. my [about +page](/about/)), and article pages, like this one you’re reading right now; an +ecommerce site would have a homepage, a product listings page (PLP), a product +details page (PDP), and a search results page (SRP). + +By capturing and comparing the behaviour of these pages alone, we can +immediately begin to build up a representative picture of the state of the whole +site. And while we may not capture outliers this way, we can still audit those +in isolation as a separate body of work if required. + +For the sake of the rest of the post, I’ll be auditing an anonymised ecommerce +client of mine, but you’ll be able to swap out my page types for your own with +ease. + +## Gathering Data + +If a picture is worth a thousand words, a waterfall is worth a thousand +pictures. Let’s start with the gold standard: +[WebPageTest](https://www.webpagetest.org/). + +Any time you run a test with WebPageTest, you’ll get this table of different +milestones and metrics. We’re interested in the first seven technical timings, +_First Byte_ through _Total Blocking Time_: + +

WebPageTest offers a wealth of insight, but right now we don’t need +to go any deeper than this.

+ +All we need to do now is grab this information for each of our pages and paste +it into a spreadsheet. If you’d like a copy of the exact spreadsheet I use, you +can [get hold of it here](https://gumroad.com/l/site-speed-topography). + +

Note the bottom row shows me the Standard Deviation of the tests’ +results. Higher variance means a less stable metric across pages.

+ +With this suite of numbers, I can now begin to make assessments. + +I can see from the screenshot above that TTFB is my most stable metric—no one +page appears to have particularly expensive database queries or API calls on the +back-end. Conversely, LCP is far more erratic, meaning that we are likely to +have highly different content page to page (the metric isn’t _bad_, per se, it’s +highly variable), and that it’s potentially not equally optimised or delivered. +Everything else is a shade in between, and at this stage offers no real +insights. It’s when we begin to graph the data that useful patterns emerge. + +## Visualising the Data + +In a separate sheet—available at the [same link as +before](https://gumroad.com/l/site-speed-topography)—I’ve simply graphed the +data by page type. + +

**N.B.** CLS is the only metric not captured in +seconds, thus appears plotted separately against the right Y-axis.

+ +It might be a good idea to [open the above graph image]({{ site.cloudinary +}}/wp-content/uploads/2020/10/milestones-chart.png) up in a new tab and keep it +handy during the rest of this post. + +The whole point of the exercise that follows is to allow me to move quickly, +spotting patterns from afar, and not having to do any slow or meticulous work +_yet_. I want to be able to form hypotheses and draw conclusions without viewing +a single URL or a line of source code. That work is what comes next. + +For now, I’m usually sat with a coffee, some tunes on, and an old-school pen and +paper making notes. What I’m hoping to ascertain is where I need to look first +when I get into the audit proper. I want to rule out any dead ends or false +starts. **I want to maximise the work not done.** + +Let’s dig in! + +### Building the Map + +Firstly, I want to **compare whole pages** at a time. Immediately, I can see +that the PLP is by far the worst offender. Almost all of its bars are higher +than other pages. This means that I will likely end up giving it a little more +attention than the others. Next, the other three pages are pretty similar with +the homepage being marginally worse. + +Next, I’ll **look for any individual outliers or extremities**. Right away I can +see that we have an outlying _Largest Contentful Paint_ on the homepage and an +outlying _Cumulative Layout Shift_ on the search results page. With my pen and +paper, I’ll make a note of investigating these specifically in my testing. + +After extremities, I’d like to actually **find consistencies**. Once again +noting that TTFB is very consistent—as seen in the table view—I can draw the +conclusion that back-end time (and [whatever else might be happening in +there](/2019/08/time-to-first-byte-what-it-is-and-why-it-matters/)) +is uniformly consistent across each page type. This means that I likely don’t +need to do any specific work on any individual pages, but also suggests that any +general back-end improvements I make in area _A_ will also be felt in locations +_B_ and _C_, too. But perhaps most importantly, the stability of TTFB means that +all subsequent milestones are measured from a very reliable baseline—I don’t +need to make any on the fly adjustments to other metrics in order to cross +reference them. Put another way, if one page’s TTFB was an entire second later, +I’d need to account for that second when comparing deltas between any of the +bars. + +Which brings me onto the next bit: deltas. This is where you’ll find some really +fascinating insights that can run surprisingly deep. + +**Gaps between _TTFB_ and _First Paint_** can, by and large, be considered your +critical path. This is basically how many render blocking resources each page +has. Of course, it’s a little more complex than that, but for this exercise it’s +an incredibly reliable proxy. Now here’s where it gets really interesting: + +If all of our TTFBs are pretty identical, then **any erroneous FPs** are +indicative of a different amount of render blocking resources. Given that render +blocking resources reside in the `head` of the document, this implies differing +`head` tags on that page. Note that the PDP’s FP is almost a second slower than +other pages? I think the PDP has something different about it. Is it simply an +additional render-blocking resource or two? Or, perhaps a more extreme scenario +is that it has entirely different `head` tags? Maybe this is an entirely +different application? It’s not unheard of. + +The next thing I want to focus on is **deltas between _First Paint_ and _First +Contentful Paint_**. FP is defined as the first pixel, no matter what it is, +being put on the screen. FCP, on the other hand, is the first image- or +text-pixel rendered to the screen. Note that most pages share near-identical FP +and FCP? This is a strong suggestion that a page is either: + +* embedding its logo in the HTML or CSS rather than using an external image, + or; +* making use of `font-display` for its web fonts, or; +* not using web fonts at all. + +Basically, the first- and first-contentful paints being identical tells us that +some text or imagery was rendered in the very first pass. This also means that +if we manage to improve FP, we’re likely to improve FCP for free! + +The PLP, however, does show a difference between the two. I’ll make a note in my +pad to investigate font-loading strategies on this page (font-based issues are, +in my experience, more common than image-based one, though I won’t rule it out +completely). + +Now, let’s move on to **gaps between _First Contentful Paint_ and _Speed +Index_**. SI is a measure of the visual completeness of above the fold content +over time. It’s [a little more complex than +that](https://developer.mozilla.org/en-US/docs/Glossary/Speed_index), but it’s +basically dealing with visual progress. The larger the gap between FCP and SI, +the longer the tail of visual completeness is. That is to say, you may have many +different regions of content in the viewport that all render at different times, +opposed to all popping in at once. This may or may not be desirable depending on +how you’ve designed the ATF experience: you shouldn’t lazy-load anything ATF, +but skeleton screens might negatively impact your SI despite being an ultimately +better experience. Generally all I’m looking our for here are any long tails +that suggest I’m under prioritising above the fold content. + +More interestingly, let’s take a look at **_Speed Index_ vs. _Largest Contentful +Paint_**. This is a little harder to explain, but for the most part, a large gap +between SI and LCP suggests that your largest contentful paint was one of the +_last_ above the fold paints—there was a large region missing for a long while, +and its late arrival is apparent in the large gap. On the other hand, a small +gap suggests that your largest contentful paint was relatively early, but +a smaller ATF paint is pushing your SI out—e.g. a late-loaded chat client, or +a small cookie banner, etc. Ultimately, this gap might be telling me about how +the nature of the ATF content came together: was it a single large region that +painted late, or was it a long tail of smaller regions pushing metrics the other +way? + +This means we can infer from the graph that a large but late-rendered region on +the PLP is pulling out our Speed Index, but a high SI and low LCP on the SRP +means we’re likely dealing with a long-tail rendering problem which is less +associated with a large region. + +Next up, let’s look at **_Cumulative Layout Shift_ and other milestones**. While +CLS is a Core Web Vital, it’s not a milestone measured in timings. Instead, it +focuses on layout stability, which is actually not much at all about speed. That +said, we can still join some dots. It’s quite obvious to me that huge LCP on the +PLP is pushing out our CLS—whatever content is late to render doesn’t have any +placeholder or skeleton. However, and slightly more obscure, the high CLS on the +SRP is not joined by a high LCP. This suggests two possible scenarios: + +1. Perhaps the search results page is loading its individual images without + `width` or `height` attributes, meaning that while they aren’t part of one + LCP, lots of small images are nudging the layout around. This confirms the + long-tail rendering suspicion we came up with before, and is certainly a + behaviour that would contribute to a high CLS. +2. Less likely, but remember that SI is only measuring above the fold + completeness, so there’s a chance that a huge initial CLS pushed a lot of + render-regions off-screen, improving the SI score in the process. However, + I would expect to see this also reflected in a more severe LCP, too. + +Finally, **_Total Blocking Time_ cannot be reliably or meaningfully compared** +against many other metrics as other milestones (except CLS) are network-bound +and TBT is CPU-bound. The only correlation one might draw would be between +a large TTFB–First Paint delta and a heightened TBT metric. Remember, a large +gap between TTFB and FP is indicative of more synchronous assets in the +`head`—if TBT goes up as well, it’s more likely that those assets are JS and not +CSS. More often than not, I would simply view TBT in isolation. + +## Final Word + +All of this information gleaned without having to visit a single page or view +a single line of source code. I didn’t need to pick through a single bit of +DevTools! This is the approach I take on every new audit project so that I can +quickly identify what issues might need investigation first, what liabilities +might be where, and more importantly, what work I can avoid doing. + +Being able to gather this many clues so quickly sets me up incredibly well ahead +of digging into the project fully; it tells me exactly where to look first. This +entire exercise is a great way of knowing where to start, which was always one +of the most tricky parts of the process for me. diff --git a/_posts/2021-02-26-measuring-network-performance-in-mobile-safari.md b/_posts/2021-02-26-measuring-network-performance-in-mobile-safari.md new file mode 100644 index 00000000..3d131074 --- /dev/null +++ b/_posts/2021-02-26-measuring-network-performance-in-mobile-safari.md @@ -0,0 +1,238 @@ +--- +layout: post +title: "Measuring Web Performance in Mobile Safari" +date: 2021-02-26 01:41:12 +categories: Web Development +main: "https://res.cloudinary.com/csswizardry/image/fetch/f_auto,q_auto/https://csswizardry.com/wp-content/uploads/2021/02/inspecting-safari-02.png" +meta: "How often do you test your site in iOS Safari? Do you even know how?!" +--- + +

N.B. This article is no longer accurate, +and changes in both iOS/MacOS and WebPageTest are no longer properly reflected. +Let me update this article when I get chance. In the meantime, the particularly +determined among you can probably fill the gaps yourselves—good luck!

+ +So far this year, all but one of my clients have been concerned about [Google’s +upcoming Web Vitals +update](https://developers.google.com/search/blog/2020/11/timing-for-page-experience). +The client who’s bucking the trend is great, not least because it’s given me +something a little different to focus on—they’re more interested in how their +site fares on iOS. What makes this particularly fun for me is that iOS Safari is +a completely different ballgame to Chrome, and not something many people tend to +focus on. So, I’m going to share with you a handful of tips to make it a little +easier should you need to do the same—and you should do the same. + +## Why iOS Gets Overlooked + +Google has a pretty tight grip on the tech industry: it makes by far the most +popular browser with the best DevTools, and the most popular search engine, +which means that web developers spend most of their time in Chrome, most of +their visitors are in Chrome, and a lot of their search traffic will be coming +from Google. Everything is very Google centric. + +This, of course, is exacerbated by the new Vitals announcement, whereby data +from the _Chrome_ User eXperience Report will be used to aid and influence +rankings. + +In short, it’s easy to see why Safari gets left out in the cold. + +## Why This Is a Problem + +The moment you don’t consider Safari, you’re turning your back on all of your +iOS traffic. All of it. Every browser available on iOS is simply a wrapper +around Safari. Chrome for iOS? It’s Safari with your Chrome bookmarks. Every bit +of iOS traffic is Safari traffic. + +In short, it’s difficult to see why Safari gets left out in the cold. + +This isn’t Google’s fault, and I’ve long wished that Apple would let other +browsers on their platform, but that doesn’t seem likely to happen any time +soon. So, we’re stuck only with Safari. That we probably aren’t testing. + +### Why This Isn’t a Huge Problem + +It’s worth noting that, by and large, the same page will perform better in iOS +Safari than it would on Android Chrome—[iPhones are generally far more +powerful](https://browser.geekbench.com/mobile-benchmarks) than their Android +counterparts. Further, and by chance, [iOS +usage](https://gs.statcounter.com/vendor-market-share/mobile/worldwide) is +strongly correlated with [regions we generally find to have better +infrastructure](https://www.webworldwide.io/). This means that iOS devices tend +to be faster and are found in ‘faster regions’. + +

Same page, same connection speed, same locale, same release year, different devices.

+ +## But, Can’t I Just Emulate? + +No. + +## You Will Need… + +For better or worse, I’m an iPhone and Mac user, so I’m pretty well set up out +of the gate. If you don’t have an iPhone, well, you’ll struggle to test an +iPhone. But the additional need for a Mac will be a barrier to entry for many +I’m afraid. + +But! Fear not! It’s not the end of the line for non-Mac users. Read on. + +## Testing with WebPageTest + +[WebPageTest](http://webpagetest.org/) is easily, by far, without a shadow of +a doubt, the single most important tool when it comes to web performance. +I could not do my job without it. I cannot overstate its importance. It’s vital. + +So imagine how happy I am to report that it has first-class, genuine iOS device +support! + +

+ +This will give you [a fantastically detailed +waterfall](https://www.webpagetest.org/result/210225_DiPE_eaab5afc3f7f8bcd6ab043a72a315984/3/details/#waterfall_view_step1)—among +plenty more—that you can go back and refer to time and again. + +However, there are two key caveats: + +1. **The devices are in the US** which doesn’t help if your typical customer is + based in, say, the Balkans. +2. **The data is static** which isn’t necessarily a drawback until it + is—DevTools allows us to work far more quickly and interactively, responding + to changes and tweaks as we make them. + +Still, this is an amazing starting point for anyone wanting to begin profiling +web performance on iOS. In fact, this is something that WebPageTest has improved +upon and [written +about](https://www.catchpoint.com/blog/m1-mac-mini-mobile-device-testing) +only a month prior to this article you’re reading right now. + +## Testing in Safari’s DevTools + +What we really want to do, alongside capturing good benchmark- and more +permanent data with WebPageTest, is interact with and inspect a site slightly +more realtime. Thankfully, if you have a Mac and an iPhone, this is remarkably +straighforward! + +### Set Your iPhone up as a Development Device + +**N.B.** This step and its sub-step are optional, but highly recommended. + +Plug your iPhone into your Mac and fire up Xcode. Once its opened, go to +_Window_ » _Devices and Simulators_ and look for your device in the resulting +window. + +

+ +Make sure that any option or alert that pertains to running your iPhone as +a development device is enabled. Truthfully, I’ve never really had to do +anything more in this view than unlock my phone and maybe restart it once or +twice. As long as I see this much, I can guarantee the next step will work… + +#### Network Link Conditioner + +I honestly can’t even believe I’m telling you this… this is so cool. Now, in +iOS’ _Settings_ app, you should find a new _Developer_ option. + +

+ +In there, you should find a tool called _Network Link Conditioner_. This +provides us with very accurate network throttling via a number of handy presets, +or you can configure your own. This means that, even if you’re connected to the +office wifi, you can still simulate slower (and very realistic) connection +speeds. + +### Enable Web Inspector + +Next, in Safari’s settings on iOS, head to _Advanced_ and enable _Web +Inspector_. That’s it! You’re good to go. + +

+ +This will allow your desktop version of Safari to inspect the current tab of +your iPhone’s Safari instance. + +### Inspect Your Phone From Your Mac + +Now open Safari. I know, you haven’t opened it in a while, so hit +⌘⎵ and type _Safari_. Head to _Develop_ and look out for your +device in the dropdown menu. + +

+ +…and that’s it. That’s really it. You’re now inspecting your phone from Safari’s +desktop DevTools: + +

+ +As long as your phone stays unlocked and with the webpage in question active, +you can inspect the iOS device as you would desktop. Neat! + +Of course, the whole point of this article is performance profiling, so let’s +move over to the _Network_ tab. If you’re used to Chrome’s _Network_ tab then, +well, I’m sorry. + +

Regrettably, this far into the article and its screenshots, +I learned that there is no longer a way to disable ServiceWorkers in Safari. +This means none of the data in the screenshots is particularly interesting, but +thankfully we aren’t here to profile my site.

+ +Here is how my actual iPhone on a throttled connection deals with my website. +There are some truly fascinating differences between how Chrome and Safari work, +visible even on a scale as small as this. It really helps drive home the +importance of testing each platform in its own right, and explains why you can’t +simply emulate an iPhone in Chrome’s DevTools. + +But! That said. Chrome’s DevTools are far, far better than Safari’s, so we might +as well use that to our advantage, right? + +Export the HAR (Http ARchive) file from Safari’s _Network_ panel and save it +~~on your desktop where it will remain until you buy a new machine~~ +somewhere sensible. Next, open Chrome and its own _Network_ DevTools panel. +Import the HAR file here. + +

Viewing Safari’s Network data in Chrome’s superior DevTools.

+ +This is key: Safari captures less data than Chrome, which is a problem. Simply +opening this file in Chrome’s DevTools doesn’t make the data itself better, but +it does allow us to interrogate it far better. It’s basically just a far nicer +workflow onto the data provided by Safari. + +If you want to know more about how best to use DevTools for performance +testing, I’m running a workshop with Smashing Magazine real soon, and that will +make you DevTools experts. You can still [grab +tickets](https://smashingconf.com/online-workshops/workshops/harry-roberts). + +## Why Bother? + +With iOS generally being faster, and Vitals being entirely Chrome centric, and +most emerging economies being Android-led, it might seem redundant to test +performance at all on iOS. In fact, it’s a relatively safe assumption that if +you’re fast on, say, a Moto G4, you’ll be blazing fast on an iPhone. But still, +given the sheer prevalence of iOS, it’s wise to be aware of what might currently +be a total blind-spot. + +While it’s unlikely to become your default process, it’s important to know how +to do it. And now you do. + +Still worried about Vitals? [Drop me a line!](/contact/) There’s still a little +while before the May update. diff --git a/_posts/2022-03-28-optimising-largest-contentful-paint.md b/_posts/2022-03-28-optimising-largest-contentful-paint.md new file mode 100644 index 00000000..eb87cce6 --- /dev/null +++ b/_posts/2022-03-28-optimising-largest-contentful-paint.md @@ -0,0 +1,495 @@ +--- +layout: post +title: "Optimising Largest Contentful Paint" +date: 2022-03-28 23:02:11 +categories: Web Development +main: "https://res.cloudinary.com/csswizardry/image/fetch/f_auto,q_auto/https://csswizardry.com/wp-content/uploads/2022/03/chart-full.png" +meta: "Let’s look at some more technical and non-obvious aspects of optimising Largest Contentful Paint" +--- + + + +[Largest Contentful Paint](https://web.dev/lcp/) (LCP) is my favourite Core Web +Vital. It’s the easiest to optimise, and it’s the only one of the three that +works the exact same in the lab as it does in the field (don’t even get me +started on this…). Yet, surprisingly, it’s the least optimised CWV in CrUX—at +the time of writing, [**only half of origins in the dataset had a Good +LCP**](https://twitter.com/ChromeUXReport/status/1501325517634490376)! + +{% include promo.html %} + +This genuinely surprises me, because LCP is the simplest metric to improve. So, +in this post, I want to go deep and show you some interesting tricks and +optimisations, as well as some pitfalls and bugs, starting with some very simple +tips. + +Let’s go. + +## Solve Everything Beforehand + +_**Struggling to hit 2.5s?** [Work with me one-to-one and deliver a faster +LCP](/consultancy/)._ + +Let’s start with the easy stuff. LCP is a milestone timing—it measures… + +> …the render time of the largest image or text block visible within the +> viewport, relative to when the page first started loading. + +The important thing to note here is that Google doesn’t care how you get to LCP, +as long as you get there fast. There are a lot of other things that could happen +between the start of the page load lifecycle and its LCP. These include (but are +not limited to): + +* DNS, TCP, TLS negotiation +* Redirects +* TTFB +* First Paint +* First Contentful Paint + +{% include cross-sell.html %} + +If any of these are slow, you’re already on the back foot, and they’re going to +have a knock-on effect on your LCP. The metrics above don’t matter in and of +themselves, but it’s going to help your LCP if you can get them as low as +possible. + +

+ Treo + is an incredible tool for getting timings data from CrUX. +

+ +An analogy I use with non-technical stakeholders goes a little like this: + +You need to get the kids to school for 08:30. That’s all the school cares +about—that the kids are there on time. You can do plenty to help make this +happen: prepare their clothes the night before; prepare their lunches the night +before (do the same for yourself). Set appropriate alarms. Have a morning +routine that everyone follows. Leave the house with plenty of time to spare. +Plan in suitable buffer time for traffic issues, etc. + +The school doesn’t care if you laid out uniforms the night before. You are being +judged on your ability to get the kids to school on time; it’s just common sense +to do as much as you can to make that happen. + +Same with your LCP. Google doesn’t (currently) care about your TTFB, but a good +TTFB is going to help get closer to a good LCP. + +Optimise the entire chain. Make sure you get everything beforehand as fast as +possible so that you’re set up for success. + +## Optimise Your LCP Candidate + +A tip that hopefully doesn’t need me to go into any real detail: if you have an +image-based LCP, make sure it is well optimised—suitable format, appropriately +sized, sensibly compressed, etc. Don’t have a 3MB TIFF as your LCP candidate. + +## Avoid Image-Based LCPs + +This isn’t going to work for a lot, if not most, sites. But the best way to get +a fast LCP is to ensure that your LCP is text-based. This, in effect, makes your +FCP and LCP synonymous[^1][^2]. That’s it. As simple as that. If possible, avoid +image-based LCP candidates and opt instead for textual LCPs. + +The chances are, however, that won’t work for you. Let’s look at our other +options. + +## Use the Best Candidate + +Okay. Now we’re getting into the fun stuff. Let’s look at which LCP candidates +we have, and whether there are any relative merits to each. + +There are several potential candidates for your LCP. Taken straight from +web.dev’s [Largest Contentful Paint (LCP)](https://web.dev/lcp/) page, these +are: + +* `` elements +* `` elements inside an `` JavaScript file in order to: + +1. exaggerate the waterfalls, and; +2. stall the parser to see if or how each LCP type is impacted by the preload + scanner. + +It’s also worth noting that each demo is very stripped back, and doesn’t +_necessarily_ represent realistic conditions in which many responses would be +in-flight at the same time. Once we run into resource contention, LCP +candidates’ discovery may work differently to what is exhibited in these reduced +test cases. In cases like these, we might look to [Priority +Hints](https://web.dev/priority-hints/) or +[Preload](https://web.dev/preload-critical-assets/) to lend a hand. All I’m +interested in right now is inherent differences in how browsers treat certain +resources. + +The initial demos can be found at: + +* [🔗 ``](https://csswizardry.dev/lcp/img.html) + ```html +

+ ``` +* [🔗 `` in `

...

+ ``` + +{% include cross-sell.html %} + +[The WebPageTest +comparison](https://webpagetest.org/video/compare.php?tests=%2C220320_BiDc0C_6AJ%2C220320_BiDcJT_6AP%2C220320_BiDcN0_6AM%2C220320_BiDc56_6AK&thumbSize=200&ival=100&end=full) +is available for you to look through, though we’ll pick apart individual +waterfalls later in the article. That all comes out looking like this: + +

+Note a bug in reported LCP with `<image>` in +`<svg>`: more on this later. (View full size.) +

+ +**`` and `poster` are identical in LCP**; **`` in `

A bug in Chrome ≤101 mistakenly reports a text node as the LCP +element. This is fixed in version 102.

+ + +As we can see, **not all candidates are born equal.** Let’s look at each in +more detail. + +### `` Elements + +

+ +Of the image-based LCPs, this is probably our favourite. `` elements, as +long as we don’t mess things up, are quick to be discovered by [the preload +scanner](https://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/), +and as such, can be requested in parallel to preceding—even blocking—resources. + +#### `

Compression	Bundling	`css_time` (ms)
None	One file	4,204
Many files	3,663
Gzip	One file	1,190
Many files	1,485
Brotli	One file	1,094
Many files	1,524

Site	LCP	INP	CLS
www.foo.com	0.4s	8ms	0.00
www.bar.com	2.5s	200ms	0.10
Difference	+2.1s	+192ms	+0.10

Site	LCP	INP	CLS
www.bar.com	2.5s	200ms	0.10
www.baz.com	2.6s	201ms	0.11
Difference	+0.1s	+1ms	+0.01

This is a nonsense table
	ID	Age	Height	Occupation	Hobbies
Data accurate as of August 2010
Harry Roberts	001	20	6′4″	Web Developer	Trials
Joe Whitley	002	20	6′1″	Sports Journalist	Golf
Laura Jones	003	22	5′5″	Florist	Pub darts
José Edwards	004	19	6′	Candlestick Maker	Singing
Sally Rodgers	005	35	5′7″	Copywriter	Bodybuilding
Herbert Smythe	006	12	4′11″	Student	Cage fighting
John Smith	007	28	5′11″	Fishmonger	Cross-stitch

This is a nonsense table
	ID	Age	Height	Occupation	Hobbies
Data accurate as of August 2010
Harry Roberts	001	20	6′4″	Web Developer	Trials
Joe Whitley	002	20	6′1″	Sports Journalist	Golf
Laura Jones	003	22	5′5″	Florist	Pub darts
José Edwards	004	19	6′	Candlestick Maker	Singing
Sally Rodgers	005	35	5′7″	Copywriter	Bodybuilding
Herbert Smythe	006	12	4′11″	Student	Cage fighting
John Smith	007	28	5′11″	Fishmonger	Cross-stitch

This is a nonsense table
	ID	Age	Height	Occupation	Hobbies
Data accurate as of August 2010
Harry Roberts	001	20	6′4″	Web Developer	Trials
Joe Whitley	002	20	6′1″	Sports Journalist	Golf
Laura Jones	003	22	5′5″	Florist	Pub darts
José Edwards	004	19	6′	Candlestick Maker	Singing
Sally Rodgers	005	35	5′7″	Copywriter	Bodybuilding
Herbert Smythe	006	12	4′11″	Student	Cage fighting
John Smith	007	28	5′11″	Fishmonger	Cross-stitch

This is a nonsense table
	ID	Age	Height	Occupation	Hobbies
Data accurate as of August 2010
Harry Roberts	001	20	6′4″	Web Developer	Trials
Joe Whitley	002	20	6′1″	Sports Journalist	Golf
Laura Jones	003	22	5′5″	Florist	Pub darts
José Edwards	004	19	6′	Candlestick Maker	Singing
Sally Rodgers	005	35	5′7″	Copywriter	Bodybuilding
Herbert Smythe	006	12	4′11″	Student	Cage fighting
John Smith	007	28	5′11″	Fishmonger	Cross-stitch

This is a nonsense table
	ID	Age	Height	Occupation	Hobbies
Data accurate as of August 2010
Harry Roberts	001	20	6′4″	Web Developer	Trials
Joe Whitley	002	20	6′1″	Sports Journalist	Golf
Laura Jones	003	22	5′5″	Florist	Pub darts
José Edwards	004	19	6′	Candlestick Maker	Singing
Sally Rodgers	005	35	5′7″	Copywriter	Bodybuilding
Herbert Smythe	006	12	4′11″	Student	Cage fighting
John Smith	007	28	5′11″	Fishmonger	Cross-stitch

This is a nonsense table
	ID	Age	Height	Occupation	Hobbies
Data accurate as of August 2010
Harry Roberts	001	20	6′4″	Web Developer	Trials
Joe Whitley	002	20	6′1″	Sports Journalist	Golf
Laura Jones	003	22	5′5″	Florist	Pub darts
José Edwards	004	19	6′	Candlestick Maker	Singing
Sally Rodgers	005	35	5′7″	Copywriter	Bodybuilding
Herbert Smythe	006	12	4′11″	Student	Cage fighting
John Smith	007	28	5′11″	Fishmonger	Cross-stitch

Trusted by:

Trusted by:

Trusted by:

Learn:

Need some of the same?

Talk

Connect

Projects

Events

Next Appearance

Talk

{{ page.title }}

{{ page.title }}

{{ page.title }}

{{ page.title }}

{{ page.title }}

{{ page.title }}

Let it snow!

` with a pink background, pulls the `

` needs to become a `

`? What if we need to add another, non-titling `

` as a child of `.widget`? We’ve made ourselves a very rigid and unportable selector here. Instead we should have: /* Base widget styling */ -.widget{} +.widget {} /* Style up widget titles */ -.widget-title{} +.widget-title {} Now we can apply `.widget-title` to _any_ element—let’s say a `

`—and can now also have any number of unclassed `

Retina images

Welcome to Foo Corp

...

...

...

Podcast

Podcast

Podcast

Interview

{{ currentDate }}

{{ currentDate }}

{{ currentDate }}

- Ocado - Workshop -

- NHS - Development, Product, Performance -

- Better Collective - Workshop, Consultancy -

- Madgex - Workshop, Consultancy -

- BBC - Workshop, Consultancy -

- BSkyB - Development, Product, Workshop -

- CSS Wizardry - Development, Product -

+ {{ case_study.title }} + {{ case_study.description }} +

- Financial Times - Workshop, Consultancy -

Test

Multiple Scripts

Done

Long-Running JS Before <title>

Third-Party Outage Before <title>

Timeout Before Title

Done!

Page Rendered

Page Rendered

Pure CSS(3) accordion—view in Webkit for best experience

Slide one

Slide two

Slide three

Slide four

Slide five

Slide one

Slide two

Slide three

Slide four

Slide five

Pure CSS(3) accordion—view in Webkit for best experience

Slide one

Slide two

Slide three

Slide four

Slide five

Slide one

Slide two

Slide three

Slide four

Slide five

Create a vertically centred horizontal navigation

Create a vertically centred horizontal navigation

Create a vertically centred horizontal navigation

And here is some dummy content, to show how you can hover over other things on the page

And here is some dummy content, to show how you can hover over other things on the page

` as a child of `.widget`? We’ve made ourselves a very rigid and unportable selector here. Instead we should have:
`/* Base widget styling / -.widget{} +.widget {} / Style up widget titles */ -.widget-title{}`
+.widget-title {} Now we can apply `.widget-title` to _any_ element—let’s say a `

Long-Running JS Before `<title>`

Third-Party Outage Before `<title>`

+ Masterclasses ^New + Bite-sized courses for your whole team +