Block HTTP requests to cut flake and lock down Happo workers

We just shipped a new option in the happo npm package that lets you allow- or block-list which hostnames your snapshots are permitted to talk to during a snap request. If a page or a component tries to fetch a font, an image, an analytics pixel, or an ad from a hostname you haven't allowed, the request never leaves the worker. Better performance, better security, and less flake.

It's off by default today. The recommendation is to set it as restrictively as you can get away with. A future major version bump in the happo npm package will flip the default so it's maximally restrictive out of the box, so you may as well get ahead of it.

Case study: from about 2,000 flaky examples to about 20

One Happo customer rolled this out and watched the number of flaky Happo variants go from roughly 2,000 to roughly 20. Most of their flake was driven by image compression artifacts from images served through their CDN which re-compresses assets from time to time. That's enough to move some pixels and create some irrelevant diffs for review.

Every request that leaves the worker is a piece of your snapshot that you don't control and can't reproduce, and this new feature helps you lock that down today.

How to roll it out

Turn it on in the most restrictive way possible (i.e. allowedHostnames: []) and see what diffs show up:

// happo.config.ts
import { defineConfig } from 'happo';

export default defineConfig({
  // ...

  targets: {
    'chrome-desktop': {
      type: 'chrome',
      viewport: '1024x768',
      allowedHostnames: [], // <--- This is the new config to add to each target
    },

    // ...
  },
});

Every asset that was quietly coming from somewhere else will announce itself as a visual change: a font falls back, an image goes blank, a tracking pixel that was rendering a 1px artifact disappears.

If those diffs are acceptable, you're done. Accept them and move on.

If they're not, go look at the worker logs for the snap request that rendered that snapshot. At the bottom of the logs you'll find a list of the hostnames that were allowed and the hostnames that were blocked during that run. Then you can use that list to decide if you want to refactor your Happo suite to avoid those hostnames or add them to the allowedHostnames list.

One specific note: if you're using the pages integration, you'll at least need to allow the hostnames of the pages URLs you're testing. Otherwise you're taking a screenshot of nothing, which is a fast way to discover the feature works. For instance:

// happo.config.ts
import { defineConfig } from 'happo';

export default defineConfig({
  // ...

  integration: {
    type: 'pages',
    pages: [
      { url: 'https://www.google.com/', title: 'Google' },
      { url: 'https://www.airbnb.com/', title: 'Airbnb' },
    ],
  },

  targets: {
    'chrome-desktop': {
      type: 'chrome',
      viewport: '1024x768',
      allowedHostnames: [
        'www.google.com',
        'www.airbnb.com',
      ],
    },
  },
});

Read more in the docs: https://docs.happo.io/docs/configuration#target-allowedhostnames

Go turn it on

If you're already running Happo, this is a config change you can make this afternoon. Start maximally restrictive, read the comparison on the PR that flips the setting, then use the blocked-hostname list at the end of the worker logs to allow back exactly what you need and nothing more.

We think this is the right move for everyone and love good defaults, so we plan to block all external requests by default in a future major version release. Enabling this option now means you get to choose the moment you review those diffs, instead of finding them bundled into an upgrade.

And if you get stuck on the rollout or the blocked list surprises you, email support@happo.io and we'll help you get back on track.