Last week, the Safari team formally expressed their opposition to the WebMCP API. In Safari’s explanation of why they oppose WebMCP, they captured something I’ve been trying to articulate.

In the comment explaining the Safari team position, Mike Wyrzykowski writes:

When a site’s actions are hard for an agent to use, that is a gap in the page’s own semantics, and the fix, in our opinion, is to close it in the platform’s shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit. 

Amen.

In fact, this sentiment should guide any efforts to change the web to support AI agents better. It’s possible that not every enhancement for AI can be structured in a way that supports all of the web’s shared layers, but we should strive to do so first before reaching for solutions that only benefit AI and not the humans the web is supposed to serve.

The Safari teams continues:

Our deeper concern is architectural. An agent acting on a user’s behalf is, in effect, assistive technology: it should operate a site as the user would, and the site should not single it out for different treatment. 

And on accessibility:

The proposal says WebMCP “is not designed for ingestion by accessibility technology”, the same fork: richer, actionable semantics reach agents while screen-reader and keyboard users get less.

All of this reminds me of a recent discussion on the Web Incubator Community Group (WICG) mailing list about a proposed standard to help AI understand domain authority. The proposed standard is designed to solve the following problem:

AI assistants often misidentify or misrepresent domains because there is no consistent, machine-readable, domain-controlled source of identity data. Today, models rely on scraped pages, inconsistent metadata, third-party aggregators, or outdated indexes. There is no canonical place where a domain can declare who they are, what they represent, or which resources are authoritative.

The proposed solution suggests adding a JSON-LD document to every website to solve the problem.

Humans struggle with domain authority as well. People have trouble telling what websites are legitimate and which aren’t. If we’re solving this problem for AI, perhaps we can find a solution that works for end users too.

And let’s set aside for the moment the irony that AI is supposed to replace all of our jobs and become a super intelligence and at the same time we also need to add special AI training wheels for it to use the web.

I’d like to see the Safari team’s response to the Web MCP API canonized as a W3C Design Principle. Maybe a slight rewrite like this:

When a site’s actions are hard for an AI agent to use, that is a gap in the page’s own semantics, and we should first seek to close it in the platform’s shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit. 

We can put it right next to the W3C’s Priority of Constituencies:

If a trade-off needs to be made, always put user needs above all…

User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

You’ll notice AI agents aren’t in that priority of constituencies, but assuming agents stick around, it might be worth considering where we’d put them.

I hope we can all agree that user needs come before agent needs. We should keep this in mind as we consider proposals to modify the web to support AI.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Mat Marquis, former Responsive Images Working Group (RICG) chair and amateur boxer, isn’t known for pulling his punches. And yet, Marquis stopped short when he declared The End of Responsive Images. Mat left responsive images on the ropes. I hope to finish them.

Or rather, finish most responsive images. The ones below the fold. Let me explain.

The responsive images race condition

In the beginning of our search for a responsive images solution, the challenge seemed simple: the img element only supported one source file, and we needed multiple sources to support responsive designs. However, if we supply multiple image sources, how will the browser know which source to choose?

Therein lies the rub. Browsers download images before they’ve calculated the layout of the page. And if the browser doesn’t know the page layout, it doesn’t know the size of the image in the page. As I put it back in 2012:

How do we reconcile a pre-parser that wants to know what size image to download ahead of time with an image technique that wants to respond to its environment once the page layout has been calculated?

Solving this problem is how we ended up with srcset and sizes. One tells the browser what source options it can choose from and the other provides the browser with the information it needs to calculate the size of the image in the page based on a measurement the browser always knows—the viewport size.

Lazy loading changes everything

In the years since, lazy-loading images has become a common practice. We can safely defer loading images outside the initial view (aka, below the fold) in order to ensure that the browser’s resources are focused on the assets that are immediately visible.

So many developers adopted this practice that it is now a web standard. Adding loading="lazy" to any image will tell the browser to delay downloading the image until it will be visible in the viewport.

Because lazy-loaded images won’t download until they are visible, the race condition described earlier no longer exists. When lazy-loaded images are downloaded, the browser knows their size.

Lazy-loaded images now allow us to simplify the markup for sizes as Mat Marquis explained:

A few weeks ago, two patches landed in Gecko and WebKit — championed by Simon Pieters and Yoav Weiss, respectively, two of the RICG’s finest. These patches landed to little fanfare, quietly aligning Gecko and WebKit with Blink in supporting a relatively recent addition to the HTML specification: support for an auto value in sizes attributes. Automatic sizes — the potential sizes of the rendered image, left up to the browser to determine alongside all those other factors. Fully automatic responsive images. Supply the browser with a list of candidates using srcset, bolt on sizes="auto", and let the browser do the rest.

So long as an image has loading="lazy" you can use sizes="auto". Here is the sample Mat provided (with a few cat-related tweaks on my part):

<img 
  loading="lazy"
  src="cat.jpeg" 
  srcset="cat-650.jpeg 650w, cat-960.jpeg 960w, cat-1400.jpeg 1400w"
  sizes="auto, (min-width: 1040px) 650px, calc(94.44vw - 15px)"
  width="650"
  height="400"
  alt="My cat Boyle is super cute.">

You’ll notice that Mat includes fallback sizes values to support older browsers. But with Safari and Firefox now supporting sizes="auto" we likely won’t need the fallback for long.

Caution: Images above the fold shouldn’t be lazy-loaded. In fact, hero images are likely your Largest Content Paint (LCP) image in Web Core Vitals and should be loaded as early as possible. Therefore, images in the initial viewport will likely always require responsive images syntax.

Removing srcset

Simplifying sizes is a good start, but I believe we can go further and radically simplify the markup for lazy-loaded images using Responsive Image Client Hints. Responsive Image Client Hints is a draft specification being stewarded by Eric Portis also of RICG fame.

Responsive Image Client Hints builds on the existing Client Hints standard that has been implemented by Blink and thus supported by Chrome, Edge, and other browsers built on the Blink engine. Web page authors can declare support for Client Hints and ask for specific hints like the size of a requested image. The browser then sends this information in HTTP headers.

For example, a server might send the following HTTP headers along with an HTML document:

Accept-CH: Sec-CH-Width
Permissions-Policy: ch-width=(self "https://images.cloudfour.com")

The first line says that the server will accept client hints and is looking for Secure Client Hints Width (Sec-CH-Width). The permissions policy line helps reduce the potential for passive fingerprinting by restricting access to the specified domains. A similar declaration can be made via a meta tag:

<meta http-equiv="delegate-ch" 
      content="sec-ch-width https://images.cloudfour.com;">

And then when an image on the page is requested by the browser, it will supply the requested Client Hints—in this case, the width of the image in the page:

GET cat.jpg
Accept: image/webp,image/*,*/*;q=0.8
Sec-CH-Width: 650

Sec-CH-Width value will contain the pixel width of the image in the page multipled by the display density. So if the image is 400 pixels wide on a 2x display, the value sent to the server will be Sec-CH Width: 800.

If both the browser and server support client hints, and the image is lazy-loaded, we can greatly simplify our markup:

<img 
  loading="lazy"
  src="cat.jpeg"
  width="650"
  height="400"
  sizes="auto"
  alt="My cat Boyle is super cute.">

We no longer need srcset because the server knows what image sizes are available or can resize the image as needed based on the image size supplied by Client Hints.

Because the image is lazy-loaded, we also know the size of the image in the page which means we shouldn’t need sizes at all. Unfortunately, the Client Hints standard expects the sizes attribute so we still need to supply sizes="auto". Perhaps this can change in the future and we can remove the sizes attribute as well.

How is an image source selected?

If we’re not supplying a list of image sources in srcset to the browser, how will one be selected? For this to work, you need an image resizing service on the server to respond to the image request. If you don’t have one, you can continue to use srcset and sizes.

If this approach takes off, image resizing services may want to change the way they select what image size to return. Instead of working from a list of image sizes that the web page author thinks might be needed, the server can monitor what sizes are requested the most and make sure those sizes are cached. The server can optimize the cached image sizes based on real world usage.

What about browsers that don’t support Client Hints?

Client Hints aren’t new. Chrome shipped them in v46 back in 2015. I wrote about their possible uses in 2016. But developers haven’t widely adopted Client Hints because Firefox and Safari don’t support them.

Because of this reality, I gave up on Clients Hints for many years. Three developments have caused me to revisit them:

1. The proliferation of lazy-loading images and the standard to support them means we have a large body of images for which the speculative downloader’s race condition doesn’t apply.
2. In my review of ImageEngine, I was impressed with how simple it is to use. Some of this simplicity is due to leveraging Client Hints when they are available.
3. Eric Portis has created a small JavaScript library that provides similar functionality for Cloudinary users in browsers that don’t support Client Hints.

Eric’s script works like this:

• If the browser supports Responsive Image Client Hints, the script does nothing.
• If Client Hints aren’t supported, the script looks for images with the loading="lazy" attribute.
• It also checks for some specific Cloudinary parameters in image’s src URL which tell the script that this image is one that it should modify.
• The script then updates the width value in the Cloudinary URL to send along the actual size of the image in the page.

I’ve modified the sample markup from above to show how it would look using Cloudinary and supporting Eric’s script:

<img 
  loading="lazy"
  src="[…]/upload/c_limit,w_auto:breakpoints:650/v1716911991/catbeans_zbh3iu.jpg"
  width="650"
  height="366"
  sizes="auto"
  alt="My cat Boyle is super cute.">

The key section in the image URL is w_auto:breakpoints:650:

• w_auto — This tells Cloudinary that the image is responsive and should be dynamically resized to fit the size of the image in the page.
• breakpoints — This tells Cloudinary to pick image sizes using a performance budget—a feature they created based on one of my articles. If performance budgets aren’t your speed, you can set a value for how many pixels before a new image is created on the server.
• 650 — this is the fallback width that should be used if the browser doesn’t send additional information via Client Hints.

If the image in the page was actually 900 pixels wide at 2x display density, the script would update the src to be:

  src="[…]/upload/c_limit,w_auto:breakpoints:1800/v1716911991/catbeans_zbh3iu.jpg"

For browsers that don’t support Client Hints, the actual size of the image in the page is added to the URL. This technique could be modified to work with other image resizing servers.

There are a few caveats with this script:

• It must be placed in the <head>
• It has to be a blocking script. You can’t async, defer, or use type="module".

Eric explains:

This script needs to see <img>s as soon as they are parsed, so that it can prepare to re-write their URLs as soon as they’re laid out. If the script executes after an <img> has been parsed, it won’t get a chance to do any of that; it’ll do nothing.

Luckily, it’s only ~950 bytes (~600B compressed).

Eric has created a couple of CodePen examples that show the script in action. One uses placeholder images and the other real images from WikiPedia.

I normally wouldn’t advocate for a blocking script, but this seems lightweight and the tradeoff is worth evaluating. Make sure to measure the performance impact on your site.

A JavaScript Solution? Really?

During the halcyon days of the RICG, not a month went by without someone proposing a way to solve responsive images using JavaScript. We repeatedly and patiently explained why JavaScript couldn’t be used because images are downloaded before JavaScript is processed.

Lazy-loading images outside the initial viewport changes this equation. We now have a small window of opportunity to modify lazy-loaded images so we can add the equivalent of Client Hints to their URLs when their size is known.

The End of Most Responsive Images

Responsive images syntax will always have a role to play. Not every web page will have a image resizing server and images visible in the initial viewport will still face the race condition that gave the RICG fits. Any images in the initial viewport shouldn’t be lazy-loaded.

Fortunately, most images on the web live below the fold and thus can be lazy-loaded. If they can be lazy-loaded, then we no longer face the intractable race condition that forced us to place presentation information in the sizes attribute where it doesn’t belong.

Moving to simpler responsive images will require some work. According to CanIUse.com, 78% of users have access to Client Hints. That’s a great start, but ideally we’d get other browsers on board. Firefox and Safari expressed privacy concerns with client hints which is why they didn’t implement them. I’m hopeful that some combination a mandatory permissions policy (e.g., primary domain and subdomains only would be ideal) and a more limited set of hints (image width and dpr only?), that we might be able to get other browser makers on board.

But even without these changes, it is possible now to remove srcset and simplify sizes using a combination of lazy-loading, Client Hints, and the techniques that Eric Portis has pioneered.

Mat concluded his article by saying:

I won’t miss all those hand-hewn sizes attributes; I never had any love for them to begin with. I will never experience a shred of nostalgia for a thing that I helped make real and inexorably bound to my name. A syntax was never the goal; the goal was always a mechanism. At the time, the web platform lacked a way for browsers to make smarter decisions about what image asset to request and when, and no amount of clever scripting or markup trickery would ever result in an asset request as fast or efficient as one the browser itself could make.

None of us working in the RICG were ever enamored with our solutions. We wanted something simpler, but srcset and sizes was the best we could do with the constraints we were given. Now that lazy-loading has removed one of the constraints, I believe we can do better.

Special thanks to Eric Portis, Mat Marquis, and Scott Vandehey for their feedback and to Tyler Sticka for the grim reaper illustration.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

When I first heard the term continuous integration (CI), I was intimidated. As a former art major, I struggle with imposter syndrome when other devs rattle off terms I assume they picked up in computer science classes.

In this case, I was relieved to learn that CI is a complicated label for a basic concept: Developers should merge (integrate) their code back to the main branch as often as possible (continuously). This stands in contrast to a common scenario where devs work on a feature in isolation for so long that it drifts out of sync with the main code branch. When the time comes to merge, it creates a confusing mess.

CI is typically paired with another term, continuous deployment (CD), which says your main branch should be deployed automatically as changes are made. The idea is to avoid issues that arise from infrequent releases. When you have unreleased (or unreleasable) code in your main branch, it’s very difficult to make emergency bug fixes or urgent change requests.

So, CI means that devs regularly merge their code into the main branch, and CD means those merges automatically trigger a deployment. That’s CI/CD workflow in a nutshell. Sounds great, right?

How Do You Ensure Code is Safe to Deploy?

You may have noticed a potential problem. If every commit is automatically deployed, then any bugs that are merged get deployed, too! By necessity, adopting a CI/CD workflow brings with it an expectation that your team should only merge code that’s safe to deploy.

The best way to address this concern is to require all code be carefully reviewed. Of course, those reviews take time, so teams typically invest in tooling to run automated quality control checks, like: Does the code compile without errors? Is it formatted to match the style guide? Do the tests pass? If any check fails, the changes are blocked until the issues are addressed. When most people talk about CI, they’re referring not only to the workflow, but also the tools that run those automated checks.

Note that automated checks are not a substitute for human review! Even if all the checks pass, there could be bugs that aren’t covered by tests or are difficult to automate, such as accessibility issues. The goal is to increase confidence by checking for obvious problems before a developer spends time reviewing it.

Our Standard CI Setup

We work on a lot of projects, and have a fairly standard setup we use to keep things consistent for devs switching between them. It all starts in package.json, where we define a standard set of scripts to run our tests, linters, and type checkers. Here’s an example from a Vue project:

// package.json
{
  "scripts": {
    "test": "vitest run",
    "test:watch": "vitest watch",
    "lint": "npm run lint:js && npm run lint:css && npm run lint:prettier",
    "lint:check": "npm run lint:js:check && npm run lint:css:check && npm run lint:prettier:check",
    "lint:js": "eslint . --fix",
    "lint:js:check": "eslint .",
    "lint:css": "stylelint --fix '**/*.{css,vue}'",
    "lint:css:check": "stylelint '**/*.{css,vue}'",
    "lint:prettier": "prettier . --write",
    "lint:prettier:check": "prettier . --check",
    "type-check": "nuxt typecheck"
  }
}

What those scripts actually do might vary. In a WordPress project, the type-check script could run PHPStan. In a project that uses Sass, the lint:css script would target *.scss files. The important part is the naming convention for the scripts. In any of our projects, a dev can confidently run npm run lint and trust that all the linters in the project will run. This sort of consistency makes life easier for devs, and makes them more likely to use these tools before putting code up for review.

The next step is to run those scripts automatically on every pull request. The CI tool we use most often is GitHub Actions.¹ By creating a single file in the repository, we can ensure that every time a PR is opened, GitHub automatically runs a series of actions. Here’s an example of a GitHub Actions CI script from one of our projects:

# .github/workflows/ci.yml
name: CI

on:
  pull_request:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          persist-credentials: false
      - name: Use Node.js 24
        uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: 'npm'
      - name: Install Dependencies
        run: npm ci
      - name: Run Tests
        run: npm test
      - name: Run Lint
        run: npm run lint:check
      - name: Run Typing
        run: npm run type-check
      - name: Run Build
        run: npm run build

This script runs every time a PR is opened, and every time code is pushed to the main branch. It’s set to cancel any in-progress CI task if a new one is triggered. It checks out the code, installs the dependencies, and runs our npm scripts. We have all our repos configured to require that all status checks pass before merging. If any of the steps in our CI check fail, the PR is blocked and can’t be merged until the issues are addressed.

CI Tooling is More Valuable in the AI Age

I’m a big believer in automated code checking. I can’t count the number of times it’s saved us. Imagine a senior dev who doesn’t think their tiny change warrants a full review, but is accidentally passing the wrong property type. (Perhaps, in this entirely fictional example, the dev’s name was Scott.) Or a designer who just wants to update the brand color, but unintentionally changes the CSS file from tabs to spaces. By running automated checks against every change, we’ve greatly increased our confidence. I love it.

And as more developers start experimenting with AI coding agents, these CI tools are becoming even more valuable. AI is improving, but it’s still mostly operating at the level of an enthusiastic junior developer. Someone who knows how to code, but lacks real-world experience, and is perhaps a touch too eager to make clever changes to critical systems.

I enjoy working with Claude, but I’ve watched it confidently make sweeping changes without running the tests. It will create new functions that are very useful, but don’t follow our house style. So far, we’ve used Claude in an extremely hands-on way, like a pair programming session. The human dev has a good understanding of what’s changed, and can redirect.

But increasingly, I’m seeing my peers discuss using AI in a more hands-off fashion. They give it a directive, and allow it to run wild. They’re thrilled when the AI delivers, in an afternoon, more code than they could write in a week. But now they discover the real bottleneck is reviewing all that code.

In short, automating your code checks ensures every contribution meets your enforcable standards, reduces the burden of code review on other devs, and can help increase your confidence in AI-generated code.

1. GitHub Actions is the tool we use most often, not because it’s the best, but because it’s integrated into GitHub, where our code already lives, and is easy to configure via a single file in the repo. In the past we’ve used Jenkins, Travis CI, Circle CI, GitLab CI, and Bitbucket Pipelines. They’re all fine. Pick the one that works best for your team and your stack. ↩︎

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

As I’ve had more opportunities to work with cookie consent managers, I’ve come to the surprising realization that most of them (all of them?) fail to track if websites are in compliance with various privacy laws.

One client we’ve been working with pays a lot of money for an enterprise-level cookie consent solution. Their cookie process is similar to what I’ve seen for other consent managers:

• The consent manager runs a scan across the client’s website to identify any cookies or other trackers.
• The consent manager may provide a suggested category for any trackers that it recognizes.
• The client has to verify that the suggested categorization is correct and categorize any cookies that the consent manager didn’t recognize.
• There may be some additional work to make sure these categorizations are replicated in tag managers.
• Once the categorization is complete, then the cookies should only be set when users provide the appropriate consent.
• Periodically, the consent manager will scan the site to look for any new cookies or trackers. If any are found, this process is repeated.

The realization I’ve had is that the subsequent scans aren’t checking to verify that the cookies are being set correctly or not. Their primary purpose is to look for new cookies. That’s valuable, but it doesn’t ensure compliance.

Our client needed to be certain that non-required cookies weren’t getting set before consent was granted. I created a script that checks what trackers are set before and after consent. But in order to get this information from their enterprise solution, they had to request a special scan.

Even after requesting the special scan, our client only knew what had been set before consent. Not whether cookies were getting set correctly based on the categories users have consented to.

I wonder how many organizations think they’re in clear when it comes to CCPA or GPDR because they’ve implemented a cookie consent solution, but don’t realize that their solutions are never checking to make sure they are truly in compliance.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Of all the talks I’ve given, none scared me more than my presentation at the 2024 performance.now() conference. The talk was ostensibly about third-party scripts and web performance, but it also touched on a topic embarrassing to me—my weight—and equated it to what I was observing on the web.

Two recent events reminded me of this talk, how much has changed for me since then because of GLP-1, and how the same can’t be said for the web.

Struggling to get healthier

I was in a strange place in Fall of 2024. We had spent three and a half years taking care of my father before he passed in October 2023. He had suffered a stroke right before COVID that left him bedridden with a tracheostomy. A respiratory pandemic is difficult enough to survive without a direct path to your lungs.

To keep him safe, we took him into our home and became his nurses, respiratory therapists, PTs—anything necessary to keep him alive. 

Taking care of him was all-consuming. As a result, our own health suffered. I gained a lot of weight and had a couple of health scares that sent me to the ER. I was pre-diabetic and while my bloodwork wasn’t dangerous yet, it was heading the wrong direction.

After my father passed, I was determined to lose weight and get into shape. I didn’t want to put the same burden on our kids that my father had on us.

So I set up a home gym in the space that had previously been his hospital room. I started rowing and lifting weights daily for the first time in my life. I purchased an underdesk treadmill so I could exercise while working.

I saw some improvements. I was stronger than I had ever been and had lost some weight, but I had plateaued. I wasn’t losing weight any more. I felt stuck.

Our clients were stuck too

Around this same time, I was conducting performance audits for some of our clients. I love helping organizations make their websites run faster so working on performance audits is usually one of my favorite tasks. But in these cases, the audits were frustrating.

Like the vast majority of websites we see in the wild, the biggest performance problems for our clients were due to third-party scripts. The good news was that I could identify which scripts caused the most issues. I could even show how much faster their site would be if they removed the scripts.

The bad news was that even if they wanted to, our clients couldn’t remove the scripts. In one case, the client was using Bolt for their cart and checkout. Bolt was a massive React app that weighed in at nearly 1MB. It slowed down the most critical parts of an ecommerce funnel. But they couldn’t remove it without breaking core functionality.

Ozempic and other GLP-1s

It didn’t seem to matter how much I worked out. I wasn’t losing weight. So I started researching Ozempic and other GLP-1s.

I was intrigued by the way Chris Coyier and Paul Ford described their own experiences. Paul Ford wrote:

Where before my brain had been screaming, screaming, at air-raid volume—there was sudden silence. It was confusing. Would it last?

I went alone that night to a Chinese restaurant, the old-school kind with tables, and ordered General Tso’s. I ate the broccoli, a few pieces of chicken, and thought: too gloopy. I left it unfinished, went home in confusion, a different kind of sleepwalker. I passed bodegas and shrugged. At an office I observed the stack of candies and treats with no particular interest.

Decades of struggle—poof. 

Before I started using GLP-1, it had already changed me. The success of these drugs made me reassess my relationship to weight loss. If the food noise in my head could be tamed with medication, then perhaps my weight wasn’t a personal failing. 

I wasn’t weak. I was just wired in a way that caused my brain to think I was hungry when I wasn’t. And I could be rewired.

What about a GLP-1 for the web?

As preparation for my talk heated up, I found myself researching third-party scripts during the day and GLP-1s at night. It’s no surprise I started to see parallels between them.

Most website owners know how important performance is for user experience and how it impacts conversions and revenue. They want a fast site. 

And yet websites continue to grow in size. Even ecommerce sites which have a strong financial motivation to fix performance issues get larger every year on average.

I knew I needed help to get unstuck. Maybe my clients did too?

I started looking for something akin to a GLP-1 for the web. I knew it wouldn’t solve every problem, but maybe a little boost would help. Was there some way we could rewire the web like I hoped GLP-1 would rewire my brain?

This became a focal point of my research. I looked into Partytown which tries to move third-party scripts off the main thread and onto a web worker where they will have less impact on the user. I explored Cloudflare’s Zaraz product which attempts something similar using Edge Workers. I revisited server-side Google Tag Manager for the umpteenth time hoping that this time it seemed more likely to work for our clients.

But every one of these solutions had significant drawbacks. They are all difficult to implement. I wasn’t certain how I could tell if third-party scripts were still working, especially when we don’t usually have access to the dashboards for these services.

That’s not to say that some people aren’t having success with them. Julian Jandl shared how they’ve been using Partytown successfully at performance.sync() 2025. I think it is easier for internal teams to experiment with solutions like this than it is for our clients to sign up for something unproven.

If I was working on the talk today, I’m sure someone in the audience would ask if AI could help. If AI will cure cancer, surely it can solve web site bloat.

Unfortunately, most AI-generated websites seem to have performance problems. Tim Kadlec points out that JavaScript bytes on the web have exploded since May 2025—the month when Claude Code, Github Copilot Coding Agent, and Cursor AI agents launched.

I suppose it doesn’t have to be that way. In theory, you can add enough context or constraints to get a performant experience out of AI, but that would require people to prioritize it. It doesn’t happen by default. So I don’t see AI solving the web’s performance problems (or cancer) any time soon.

Video of my presentation

While I didn’t find a GLP-1 for the web, I’m still proud of the talk. There are many practical suggestions on how to analyze and manage third-party scripts. 

I recommend watching the talk, but I’ll admit I have a hard time doing so. I was going to send it to a client last week and was shocked at how big I look in the video.

My Tirzepatide journey

I nearly started GLP-1 before the performance.now() conference, but I was worried about potential side effects before the trip. I didn’t want indigestion during the conference or after it when my family was meeting me for a vacation.

After we returned home, the holidays took precedence. In early 2025, I read about the FDA removing some GLP-1s from the shortage list which meant compounding pharmacies could no longer make it. Compounding pharmacies were providing affordable alternatives. I knew I couldn’t afford the full price, and my insurance wasn’t going to cover it.

So I gave up for a bit until a friend who I hadn’t seen in a few months visited. I was stunned by his transformation. He was on Tirzepatide (a different GLP-1) and looked like an entirely different person.

His experience inspired me to give it another try. I took my first shot of Tirzepatide on June 27, 2025. I still have more to go, but I’ve lost 50 pounds so far. I’m at the lowest weight since college. I can now see the evidence of my daily workouts. And most importantly, my blood work is trending in the right direction.

The 49MB Web Page

Unfortunately, the story for the web over the same period hasn’t been great. One of the triggers for revisiting my presentation was this excellent article by Shubham Bose examining a 49MB New York Times article.

Bose points out all of the privacy and user hostile code being used on the web these days. Most of this code comes from third-party scripts.

And maybe it’s a bit of silly numerology, but I couldn’t help but feel some kinship to this random NYT article. The page weighs 49MB. I’ve lost 50 pounds.

I wish I could share some of my Tirzepatide with these pages.

Open for discussion

I like helping people build faster websites, but I can only help so many clients at a time. It’s a drop in the bucket compared to the direction the web is headed. It feels as futile as dieting.

The main purpose for my talk was to spur discussion in the web performance community because I believe only collective action on third-party scripts can make a difference. I don’t know if we will be able to find some miracle GLP-1-like solution for third-parties. But maybe we can make it easier for people to learn which third-party scripts are better from a performance standpoint. That would be a good start.

In a similar vein, I’d like this article to be the starting point for discussion. If you want to brainstorm ways to handle third-parties and make the web faster, I’d love to hear about it—particularly if you’ve successfully used PartyTown, Zaraz, or server-side GTM. 

I’m also open to talking about weight loss and my experience with Tirzepatide. I’m keenly aware of how difficult it can be to talk about these things. I’ve been too embarrassed to do so for years. But Tirzepatide has made a huge difference for me so I’m happy to share what I’ve learned.

So I’m open for discussion. You can ask me anything. You can reach out publicly or privately. I’m happy to talk about either topic or anything else that may be on your mind. We’re all in this together.

P.S. We’re looking for projects. Please spread the word.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

I’ll cut to the chase: Our calendar is light, and we need more projects. Especially projects with a UX design, UI design or hybrid creative/development focus.

Small projects? No prob, we’ve got individual high-velocity contributors to spare, ready to slot in at any project stage.

Large projects? Bring it on: Our unique approach scales well to big problems, like modernizing legacy applications or building up multi-brand design systems. (Once you’ve made Walmart’s cart and checkout responsive, you can do anything!)

(Already know us? Skip to ways you can help)

Why Cloud Four?

• Your audience deserves better than just another sluggish, inaccessible, generic web experience.
• Our fast-paced, collaborative process keeps your team engaged and your goals in focus.
• Interactive, browser-based deliverables remove guesswork from the review process while streamlining implementation.
• You’ll support a small, independent company that’s served customers for almost 20 years while sharing more than 25 talks, 80 code repositories and 500 (!!) articles for free with their community.

What clients say

Cloud Four really dug in to understand what our customers needed and how our business worked. We chose Cloud Four for their web expertise, but what they delivered would be world-class on any platform. I’m so proud of what we accomplished together.

Cloud Four’s process stands out for being so transparent, iterative and collaborative. They listened carefully to our goals, asked tough but important questions, and encouraged contributions from everyone. I’m amazed by how much our web experiences transformed with their guidance.

Cloud Four not only massively simplified our purchasing flow but also prototyped a foundation for our future plans. On top of that, they were also an absolute pleasure to work with. Professional, thoughtful, and most importantly fun.

The API Explorer demo has been a big help in explaining our APIs to developers. It increased engagement over 400% and improved the quality of our conversions.

How to help

If you have (or may have) a project, get in touch via our contact form, email or phone.

If you have a boss or hiring manager in charge of contracting design resources, recommend us to them, share this post, or reach out to make that connection directly.

Share this post (or any article you find more relevant) with friends, family, forums, work chats, or social connections who might benefit from (or amplify) our services.

It’s thanks to our amazing clients we’ve been able to ship so many exceptional experiences over the past 19 years, continually sharing what we learn along the way. I hope you’ll be part of that journey soon!

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Starting on January 1, the California Consumer Privacy Act (CCPA) requires that websites provide confirmation that they have honored a user’s Global Privacy Control (GPC) opt out. Unfortunately, many cookie consent banners are doing this in the most confusing way possible and making me wonder if they are doing it intentionally or not.

What is Global Privacy Control?

Global Privacy Control is a web standard that allows users to tell websites that they wish to opt out of having their information tracked or sold. In theory, if you have set Global Privacy Control, you shouldn’t see any cookie consent banners.

Global Privacy Control works behind the scenes by setting two values. One is an HTTP Header, Sec-GPC: 1, that is sent by the browser with every request to a server. The second value makes sure GPC is available to JavaScript by setting navigator.globalPrivacyControl property to true.

Some browsers—Firefox, DuckDuckGo, and Brave among them—implement GPC support by default. For other browsers, you can install extensions like the Electronic Freedom Foundation’s Privacy Badger. If you want to test to see if your browser is sending GPC correctly, you can test it on the Global Privacy Control informational site.

What happened to Do Not Track?

Some of you may be wondering how Global Privacy Controls differ from an earlier solution called Do Not Track. While Do Not Track also used HTTP Headers to opt out of tracking, it wasn’t an official standard, and never gained traction with website owners. In 2019, the working group behind Do Not Track disbanded, and browsers started removing support for it.

The biggest difference between Do Not Track and GPC is that GPC has been codified in law. Eleven states require businesses to honor GPC opt outs. The EU’s General Data Protection Regulation (GDPR) was written before GPC was created, but it likely that GPC still applies under GDPR. According to CookieScript, “While not explicitly mentioned in the GDPR regulation, the principles of ‘Privacy by Design’ and ‘Ease of Withdrawal’ make GPC signal a requirement to honor user opt-out choices.”

UX fails or malicious compliance?

All of this brings me back to California’s new GPC confirmation rule and the odd way that cookie consent solutions have implemented it. Digital compliance vendor Clym describes the new rule thusly:

Starting in 2026, it is no longer sufficient to simply process an opt-out silently. If you receive an opt-out signal (like the Global Privacy Control), you must explicitly display a confirmation to the user.

• Requirement: You may need to display a message like “Opt-Out Request Honored” or show a toggle in the user’s privacy settings indicating they have opted out.
• This allows consumers to know that their automated browser signals are working.

Because I have GPC turned on in my browser, I began to see these confirmations. Unfortunately, it is often not clear what I should do with the information. For example, this is what I saw on a recent website using OneTrust for cookie management:

It’s nice to see confirmation that my opt out preference has been honored, but what am I supposed to do now?

There is a big button that says, “Accept All Cookies” that appears to be my main option. If I click on it, will the site still honor my opt out? Or will clicking on the button override GPC?

I decided to give it try, and as expected, clicking the only button available to me overrode my opt out.

I find this preferences panel hilarious. It says it has honored my opt out, but every bit of tracking has been turned on. I tested a few other cookie consent options and found similar interfaces where you’re informed that your opt-out has been honored, but you’re still forced to make a choice about what cookies you will allow.

I know that for any of these banners, I can click on the cookies settings link to adjust my preferences, but isn’t the whole point of the GPC opt out to streamline the process so users don’t have to manually opt out?

By contrast, the best implementation I’ve seen was a small notification that my opt-out had been honored. That’s it. No further action required. I believe this is what California was hoping for when it added this new requirement.

It seems the new rule has surprised cookie consent managers. In my testing, many of them do not yet honor the notification requirement even if they honor GPC behind the scenes. So perhaps these broken and confusing user experiences are because notifications are being quickly grafted onto existing applications.

However, when I see that the service is aware that I’ve opted out, and the only button it provides is one to accept all cookies, I find myself wondering if it is intentional. I know Hanlon’s Razor says we shouldn’t immediately ascribe situations like this to malice so I’m hopeful that over time cookie consent banners will do a better job of honoring GPC opt outs.

If you’re interested in learning more about privacy and cookies, check out my recent two-part series on cookie consent management in 2026.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

In part one of this series, I shared some high-level thoughts on why organizations are increasingly focused on cookie consent and some things I’ve learned about how to pick a good solution and roll it out in your organization.

In this article, I want to focus on the more technical aspects of identifying what source is setting a cookie so that you can ensure that your cookie consent solution is handling it properly.

Turn off content blockers

In order to test what cookies could be set, you have to turn off any features that may block cookies. For me, that meant turning down browser privacy setting and turning off extensions like Privacy Badger and uBlock Origin. My home network runs on Eero Plus which also features ad blocking. Everything had to be turned off.

Don’t use default Incognito mode

Chrome in Incognito mode is my default testing environment. Incognito mode provides a clean slate when I’m troubleshooting performance issues.

However, I wasn’t seeing some of the cookies I expected in my tests. Turns out that when Chrome is in Incognito mode, it blocks third-party cookies by default. You can bypass this behavior by clicking on the eye icon in the toolbar.

I used Incognito almost exclusively for my testing which means I’ve have been doing this wrong for years.

Lazy-loading and dynamic cookies

As I ran my tests, I started to see cookies that only showed up occasionally. I finally figured out that these cookies were set by scripts that were lower on the page and were only loaded when someone scrolled down.

In addition, ad networks can include different scripts which in turn set different cookies based on a user’s geography, etc. These dynamic insertions are hard to predict. Thankfully, these changing cookies seem primarily limited to ad networks so if you categorize the parent script correctly, then any additional cookies added later will also be categorized correctly.

Finding the cookie culprit

Figuring out what asset set a cookie can be challenging. When you look at the list of cookies in Dev Tools, you can get some hints about what might be setting the cookie from the cookie’s name and domain. If you’re lucky, there is only one asset coming from the domain, and you’ve found your culprit. Most of the time, you won’t be that lucky.

Unfortunately, the cookie panel doesn’t contain the equivalent of the initiator column in Chrome’s network panel. When I’m conducting performance audits, I rely on the initiator section to help me track down the chain of requests that led to an asset getting downloaded. I’d love to have something similar for cookies.

Instead, you either need to make some intelligent guesses or create some tooling. Absent tooling, my investigation steps look something like this.

First, I look at the domain name and tracker name to try to determine what service I think might be setting a cookie. For example, a cookie with the domain set to .linkedin.com with the name __cf_bm likely was set by a LinkedIn script and the cf name suggests that the cookie is related to Cloudflare.

I’ll then look up the cookie using a service like Cookiesearch.org. In this example, the search will tell me that __cf_bm is set by Cloudflare and “is used to support Cloudflare Bot Management.”

Once I have a domain for the cookie, I turn to the network panel to see if I can find the culprit. I’ll filter the network panel to only show assets coming from suspect domain.

Cookies can be set by HTTP Headers or JavaScript. HTTP Headers are easier to look for, so I always start there. In the network panel, I look at the response headers for each asset that comes from the suspect domain. The response headers are the headers sent by back the server when the browser requested the asset. The server can ask the browser to create cookies using Set-Cookie headers. There can be more than one Set-Cookie header for a given asset.

If the cookie isn’t set using HTTP Headers, it can be more difficult to isolate which bit of JavaScript is setting the cookie. I often use request blocking in the network panel as a blunt tool to isolate which script sets the cookies.

First, I’ll block the entire request domain, clear all cookies, and then check to see if the cookie is still getting set. If it is, I’m looking at the wrong source. If the cookie is no longer being set, I now know that one of the assets I blocked is responsible.

Often I’m able to make an educated guess about which asset is likely to set the cookie based on the description of the cookie and the asset names. If I have a hunch, I’ll try blocking that asset alone and see if the cookie is still set.

If I don’t have a guess or I guessed wrong, I’ll narrow it down by blocking half the requests from the suspect domain to see if that blocks the cookie. If it does, I know where to continue looking. If not, the cookie must be set in the other half. Repeat this a few more times and you can quickly winnow down even a long list of assets.

Cookies blocked by the browser

Cookies that were blocked by the browser may still show up in cookie list to help with troubleshooting. Their row will be distinguished in a different color and if you hover over the associated request, you will see information about why the cookie was rejected.

Testing using a headless browser

Manual testing can only get you so far. I had to audit hundreds of cookies for a client, so I looked for ways to automate the process. I couldn’t find anything that did exactly what I needed so with Claude Code’s help, I wrote a command line tool that used Puppeteer to see which cookies were set before and after consent was granted.

Puppeteer helped me find cookies that my manual testing had missed. Every time Puppeteer launches, it has a clean slate. Therefore, any cookies that my script finds must have been set by the test page. This helped capture third-party cookies that were only showing up on the first page load.

I also added logic to intercept cookies being set to create my own version of the the initiator chain. Eventually, I expanded the tests to look for local storage, session storage, and IndexDB. Puppeteer also scrolls the page to make sure it captures any lazy loading cookies.

If you need to do any significant amount of testing, I recommend using Puppeteer, or its alternative Playwright, so you have a clean testing environment and can automate the process.

Cookie consent can be fun?

When our clients first asked for help with their cookie consent management, I wasn’t looking forward to it. I like designing and building solutions for users not dealing with legal requirements. Plus, cookie consent banners are annoying.

But by the end of these projects, I found myself enjoying the work. The cookie consent tools do a good job of recognizing most cookies, but there are always a few mysteries in the box. I love a good mystery. And sometimes you find truly surprising things like a site manifest file setting multiple cookies.

Plus, there is satisfaction in knowing that people will have their privacy preferences honored. Not to mention the fact that we’re able to significantly reduce the legal risk for our customers.

Cookie consent management can seem daunting at first, but it is important for your organization and its users. And maybe I’m just a sicko, but I found it to be a lot of fun.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

I’ve noticed a trend. Over the last few months, multiple customers have asked us to help with cookie consent compliance. Either it is a mighty coincidence or something has caused companies to start taking privacy compliance more seriously.

I think the renewed interest is because ambitious lawyers have started sending threatening letters to companies that aren’t in compliance with the California Consumer Privacy Act (CCPA) and the EU’s General Data Protection Regulation (GDPR) provisions. I know of at least one company with over $100k in related legal fees.

Last month, California won a $2.75M settlement with Disney over CCPA violations. CCPA fines can add up quickly. They start at $2,663 per incident. The fines increases to $7,988 per incident for willful violations or violations involving people under 16.

It’s not limited to CCPA and GPDR. Enterprising lawyers have dusted off the 1967 California Invasion of Privacy Act (CIPA) and applied it to web technology. The law firm Varnum explains:

Plaintiffs’ attorneys are using CIPA to challenge common website technologies, including cookies, analytics tools, session replay software, and chat features. Many companies are caught off guard when they receive a demand letter alleging unlawful website tracking, followed by the threat of litigation.

Thousands of CIPA website tracking claims have been asserted, and filings continue to rise.

So it’s not surprising that companies are trying to get their cookie house in order. I may be a glutton for punishment, but I’ve enjoyed working on these cookie consent projects, and thought I’d share some of the things I’ve learned. In part one, I’ll share some high-level thoughts. In part 2, I’ll dig into some technical details.

Organizational resistance

When an organization implements cookie consent management for the first time, the impact on their analytics and marketing initiatives can be dramatic. If people can opt out of being tracked, a significant percentage will choose to do so. If your marketing relies on tracking, it will suffer.

I know of an organization that backtracked on cookie compliance because of the impact on marketing. Doing so creates legal exposure, but it’s understandable how a company that sees their sales drop might panic.

So my first piece of advice is to talk to marketing ahead of time to understand what tools are being used. Determine which are most likely to be impacted by cookie banners, and see what you can do to mitigate them. Sign up now for a GPDR-compliant, cookie-less analytics service like Plausible or Umami so you have a baseline of analytics information. You can use these services track trends before and after you implement a consent banner.

Unfortunately, in a lot situations, there isn’t much you can do to alleviate the data loss. If someone doesn’t want to be tracked and your marketing tools depend on tracking data, then the tools are going to be less effective. But helping your marketing colleagues anticipate where cookie consent will impact them will not only help mitigate data loss, but it will also prepare the team for their new reality.

Hire a good lawyer

I’m not a lawyer. If you’re reading this, you’re probably not either. You need knowledgable legal counsel to help you decide how cookies should be categorized. Only a lawyer can help an organization make sure they are in compliance and understand the risks of various choices.

Plus, if you’re the person leading the privacy charge, then the people are going to resist you. Instead, if a lawyer tells your organization what they need to do, then you don’t have to argue with co-workers about whether their favorite service’s cookies should be defined as essential or not. You get to be the hero helping the organization while the lawyer plays the bad cop.

Find a good cookie consent solution

I find cookie consent banners annoying. As a user, I didn’t care what solution a website used so long as I could dismiss it quickly.

But after working with a few different cookie consent solutions for our clients, I now have a list of features I consider critical:

• GPDR compliant: You may only care about CCPA right now, but CCPA is evolving towards GPDR. In fact, even though one of our clients is based in California and doesn’t sell in Europe, their lawyers advised them to use a GPDR-style cookie consent banner where you can select specific categories of cookies instead of a CCPA-compliant one where you either accept or reject cookies.
• Regular scanning of your site: What cookies are being used on your site may change over time without you knowing about it either because a new third-party service is added to the site or an existing one adds a new cookie. You need regular scans to tell you if a cookie has been discovered so you can categorize it.
• Identifies local storage, session storage, and IndexDB in addition to cookies: Even though everyone talks about cookies, the privacy laws don’t care what technical mechanism is used to track people. You need a tool that looks at all of the ways people can be tracked.
• Intuitive web-based reports: We’ve worked with one cookie consent manager where account managers send periodic spreadsheets that appear to be manually generated. By contrast, my favorite provider has an easy-to-use web report that shows what cookies their scans have discovered and how to take action on them.
• A solution that is lightweight and fast: Cookie consent banners have to load early on the page and block other scripts. Therefore, any performance issues they have are magnified.

On that last point, I asked the web performance Slack community if anyone had recommendations for a performant cookie solution. The kind folks at RUMVision shared data from across their customer base:

Because I have a performance hammer and everything is a nail, I started my explorations with CookieYes (That’s an affiliate link. If you sign up, we get a tiny kickback.) It is almost twice as fast as the nearest competitor in the RumVision data.

I’ve been quite happy with CookieYes. It is reasonably priced. The administrative dashboard is easy to work with. The scans surface cookies we need to address. Most importantly, their support has been fast and knowledgeable.

Monitor your compliance

Complying with privacy laws requires some form of ongoing vigilance. Unless you are not using any third-party services, the cookies being used on your site may change without your knowledge. Therefore, you need regular scans and people who are responsible for addressing any new issues that arise.

In larger organizations, you have to keep an eye out for other teams creating new websites. These websites need to be integrated with your main cookie consent solution. If someone opts out on one of your websites, their decision should carry over to others. This may require all company websites to use subdomains so cookie consent decisions can be more easily shared between them.

The privacy laws themselves change. As of January this year, CCPA not only requires websites to honor a user’s Global Privacy Control (GPC) setting, but also explicitly notify them that it has been honored.

The good news is that while you do need to monitor cookies and privacy laws to make sure you remain in compliance, the ongoing work is minimal once you tackle the initial audit, categorization, and implementation of a cookie consent banner.

In part 2 of this series, I’ll share some technical tips and tricks I learned for identifying the source of cookies.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work

Eleventy Build Awesome is great for rapid prototyping! Tyler shows off a few of his favorite shortcodes, filters and other techniques to quickly populate interactive mockups and wireframes with “dummy” or FPO (for placement only) content.

You can watch the presentation here:

Example Helpers

These are the main code samples from my slides, consolidated below for easy reference.

Each helper is written in ESM syntax (but should work in CommonJS with a few small changes), and each assumes it lives in its own file (imported by the config).

Text, Numbers, etc.

With the Chance dependency:

import Chance from "chance";
let chance;

export default function (method, ...args) {
  // Support JSON string for first argument
  if (typeof args[0] === "string") {
    args[0] = JSON.parse(args[0]);
  }

  // Instantiate Chance the first time
  if (!chance) {
    chance = new Chance();
  }

  // If the method exists, return its output
  if (typeof chance[method] === "function") {
    return chance[method](...args);
  }

  // Otherwise, log an error but proceed
  console.error(`[chance] No method named ${methodName}`);
  return "";
}

import chanceHelper from "./helpers/chance.js";

export default function (eleventyConfig) {
  eleventyConfig.addShortcode("chance", chanceHelper);
  eleventyConfig.addFilter("chance", chanceHelper);
}

Images

With our Simple SVG Placeholder dependency:

import simpleSvgPlaceholder from "@cloudfour/simple-svg-placeholder";

/**
 * Modify these to suit the project!
 * @see https://github.com/cloudfour/simple-svg-placeholder#option-reference
 */
const defaults = {
  bgColor: "rgb(0 0 0 / 0.8)",
  textColor: "white",
};

export default function (width, height, options = {}) {
  // Support JSON string for argument
  if (typeof options === "string") {
    options = JSON.parse(options);
  }

  return simpleSvgPlaceholder({...defaults, width, height, ...options});
}

import fpoImageHelper from "./helpers/fpo-image.js";

export default function (eleventyConfig) {
  eleventyConfig.addShortcode("fpoImage", fpoImageHelper);
}

Icons

This example uses the Iconify API via Eleventy Fetch.

I’ve made a small enhancement since the presentation, adding the entities package to escape attribute values on the inline SVG based on a recommendation from Zach Leatherman:

import EleventyFetch from "@11ty/eleventy-fetch";
import { escapeAttribute } from "entities/escape";

const apiUrl = "https://api.iconify.design";

const fetchOptions = {
  duration: "1y",
  type: "json",
};

const defaultAttr = {
  xmlns: "http://www.w3.org/2000/svg",
  class: "icon",
};

// Get a specific set:name icon string
async function getSpecificIcon(icon) {
  // If already specific, do nothing
  if (icon.includes(":")) {
    return icon;
  }

  const searchUrl = `${apiUrl}/search?query=${icon}&limit=1`;
  const searchData = await EleventyFetch(searchUrl, fetchOptions);
  const results = searchData.icons || [];

  if (results.length === 0) {
    throw new Error(`No icon found for ${icon}`);
  }

  return results[0];
}

// { class: "icon", width: 120 }
// => 'class="icon" width="120"'
function objectToAttributeString(obj) {
  return Object.entries(obj)
    .map(([key, value]) => {
      value = escapeAttribute(`${value}`);
      return `${key}="${value}"`;
    })
    .join(" ");
}

export default async function (icon, attr = {}) {
  // Support JSON strings for attributes
  if (typeof attr === "string") {
    attr = JSON.parse(attr);
  }

  try {
    icon = await getSpecificIcon(icon);
    const [setName, iconName] = icon.split(":");
    const iconDataUrl = `${apiUrl}/${setName}.json?icons=${iconName}`;
    const iconData = await EleventyFetch(iconDataUrl, fetchOptions);

    if (typeof iconData !== "object") {
      throw new Error(`Request for ${icon} returned ${iconData}`);
    }

    const { width, height } = iconData;
    const { body } = iconData.icons[iconName];
    const attrString = objectToAttributeString({
      ...defaultAttr,
      "data-icon": icon,
      viewBox: `0 0 ${width} ${height}`,
      width,
      height,
      ...attr
    });

    return `<svg ${attrString}>${body}</svg>`;
  } catch(err) {
    console.error(`[iconify] ${err.message}`);
    return "";
  }
}

import iconifyHelper from "./helpers/iconify.js";

export default function (eleventyConfig) {
  eleventyConfig.addShortcode("iconify", iconifyHelper);
}

Resources

More references from the talk (other than dependencies in the previous section):

• For more about Cloud Four’s process, check out Responsive Design Process That Works and one of our case studies
• Why I Like Designing in the Browser and five tips for beginners
• Build Awesome provides helpful docs for Shortcodes and Filters
• If you already have an icon library, check out uncenter’s awesome plugin
• Flow and Redacted are fonts intended for stubbing out text sections in wireframes
• Performance chart from the Page Weight section of the 2025 Web Almanac
• Accessibility chart from The WebAIM Million’s WCAG Conformance section
• XKCD’s Website Task Flowchart cartoon

Some Questions Answered

Two questions stood out to me during a live Q&A following my presentation:

Acknowledgements

Big thanks to Sia Karamalegos for having me, Zach Leatherman for creating Build Awesome (new Kickstarter launching soon) and encouraging my unique possum interpretations, and especially everyone who attended the meetup!

If you want to see Cloud Four’s process in action, get in touch! We’re always looking for our next web app design challenge.

We’re Cloud Four

We solve complex responsive web design and development challenges for ecommerce, healthcare, fashion, B2B, SaaS, and nonprofit organizations.

See our work