Better cross-linking

Author: csswizardry

_posts/2011-09-17-writing-efficient-css-selectors.md

@@ -5,6 +5,7 @@ layout: post
 slug: writing-efficient-css-selectors
 title: Writing efficient CSS selectors
 wordpress_id: 3144_
+meta: "CSS selectors, and their combinations, can be fast or slow! And while hopefully imperceptible, it’s definitely worth knowing about."
 categories:
 - Web Development
 tag:

_posts/2013-01-23-your-logo-is-still-an-image-and-so-is-mine.md

@@ -1,6 +1,7 @@
 ---
 comments: true
 date: 2013-01-23 18:33:00
+last_modified_at: 2025-06-10
 layout: post
 slug: your-logo-is-still-an-image-and-so-is-mine
 title: Your logo is still an image… and so is mine!
@@ -198,6 +199,7 @@ and also take even more advantage of sprites! A machine sees an `img` labelled
 ‘CSS Wizardry’ (perfect) and a user sees my logo (awesome)! Everyone is happy,
 everything is correct.
 
-**Edit:** As many people have suggested, you could – if your stats allow it –
-use a Base64 data-URI instead of a gif and save the HTTP request. This obviously
-isn’t cachable in the same way as an image is, but it is gzippable!
+**Edit:** As many people have suggested, you could use a [Base64
+data](/2017/02/base64-encoding-and-performance/)-URI instead of a gif and save
+the additional HTTP request. This obviously isn’t cachable in the same way as an
+image is, and also does bring certain other downsides you ought to be aware of!

_posts/2020-05-19-the-fastest-google-fonts.md

@@ -82,7 +82,8 @@ this post, I will list the results for both sites. My variants are:
 * **`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`:** Warming up the `fonts.gstatic.com` origin myself.
+* **[`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
@@ -199,12 +200,13 @@ Matcher_](https://meowni.ca/font-style-matcher/).
 |                       |  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 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.
+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**.

_posts/2022-08-24-measure-what-you-impact-not-what-you-influence.md

@@ -57,11 +57,12 @@ we measure and benchmark ourselves as we work. Not about the ultimate outcome,
 LCP, which is a UX metric, but about the technical metrics that we are impacting
 directly.
 
-We might hypothesise that reducing the amount of render-blocking CSS should help
-improve LCP—and that’s a sensible hypothesis!—but this is where my first point
-about atomicity comes in. Trying to proxy the impact of reducing our CSS from
-our LCP time leaves us open to a lot of variance and nondeterminism. When we
-refreshed, perhaps we hit an outlying, huge first-byte time? What if another
+We might hypothesise that reducing the amount of
+[render-blocking](/2024/08/blocking-render-why-whould-you-do-that/) CSS should
+help improve LCP—and that’s a sensible hypothesis!—but this is where my first
+point about atomicity comes in. Trying to proxy the impact of reducing our CSS
+from our LCP time leaves us open to a lot of variance and nondeterminism. When
+we refreshed, perhaps we hit an outlying, huge first-byte time? What if another
 file on the critical path had dropped out of cache and needed fetching from the
 network? What if we incurred a DNS lookup this time that we hadn’t the previous
 time? Working in this manner requires that all things remain equal, and that