Skip to content

Stripping Static Resources

Deleting transactions one at a time is fine for a handful of ad-servers. But there's a much larger category of requests you'll often want gone in a single stroke, for a reason that catches almost everyone off guard the first time. Load Tester has a dedicated tool for it: Configure → Strip Static Resources. To understand when to reach for it, it helps to know what a "static resource" actually is, and why recorded ones tend to rot.

What a static resource is

Every web page is really two different kinds of thing arriving together.

The first kind is built by the server on the spot, just for this request: the HTML of your account page with your name on it, the JSON an API returns when you add an item to your cart, the list of search results for what you just typed. The server has to run code and probably hit a database to produce these. They are different for every user and every action.

The second kind is the same for everyone and never changes based on who is asking: the stylesheet that makes the page look right, the JavaScript that runs in the browser, the company logo, the fonts, the product photos. These are static resources. "Static" because the file's contents are fixed. The server doesn't compute them per request. It just hands back the identical file every single time, to everyone.

A modern web page pulls in a lot of the second kind. It is completely normal for one page load to fetch a single HTML document and then eighty or a hundred separate files of CSS, JavaScript, images, and fonts. When you record a test case, Load Tester faithfully captures all of them, because that is what your browser actually requested.

Why recorded static resources turn into 404s

Here is the part that surprises people. Those static files usually don't have plain, stable names like style.css or app.js anymore. Modern web frameworks rename them with a string of random-looking characters baked right into the URL:

/assets/index-4a8f9c2e.js
/static/css/main-8f3a2b1c.css

That 4a8f9c2e is not random. It is a fingerprint calculated from the file's contents, and the framework recalculates it automatically every time the site is built. This is a deliberate technique called cache busting. It exists to solve a real problem: browsers aggressively save (cache) static files so they don't re-download the same stylesheet on every page. That's a good thing, right up until you ship a fix and visitors keep seeing the old broken version out of their cache. By stamping the contents into the filename, the framework guarantees that the instant a file changes, its URL changes too, which forces every browser to fetch the new one. Same file, new name, every release.

Nearly every popular framework does this, and it's on by default:

  • Webpack names bundles main.[contenthash].js, for example main.8f3a2b1c.js.
  • Vite (the default build tool for new Vue and React projects) emits assets/index-[hash].js and assets/index-[hash].css.
  • Next.js stamps a fresh 21-character build ID into every asset path under /_next/static/ on every single deploy.
  • Angular CLI outputs main.[hash].js, with output hashing turned on by default.
  • Create React App ships files like static/js/main.073c9b0a.chunk.js.
  • Ruby on Rails (Sprockets) and Django (ManifestStaticFilesStorage) do the same thing on the server side, appending a content digest such as application-908e25f4bf641868d8683022a5b62f54.css.

Now the problem is obvious. Your recorded test case holds the exact URLs from the day you recorded it, fingerprints and all. The next time the site is deployed, even for a one-line CSS tweak, every one of those fingerprints changes. The file your test case asks for, index-4a8f9c2e.js, no longer exists on the server. It's now index-7b1e0d93.js. So the server answers your test case's request with 404 Not Found, over and over, for dozens of resources, on every page. The test case didn't break because your application broke. It broke because the version numbers moved, which they do on every release by design.

Why this usually doesn't matter for the load test

A wall of 404s sounds alarming. For most load tests it isn't, for one simple reason: you are almost certainly not the one serving those files.

Static resources are typically handed off to a CDN (Content Delivery Network), a separate, globally distributed service such as Cloudflare, Fastly, Akamai, or Amazon CloudFront, whose entire job is to serve unchanging files quickly from a location near each user. Your application servers, the ones running the business logic you actually care about (login, checkout, search, the database queries), never see those requests at all. The CDN absorbs them.

So during a load test, the static resources measure the wrong thing. A CDN serving a cached JavaScript file to a thousand virtual users tells you nothing about whether your checkout service can handle a thousand real shoppers. The static requests just add noise, slow the test down, and (thanks to the version-number problem) flood your results with 404s that have nothing to do with your application's health.

That is exactly what Strip Static Resources cleans up. It removes all the static files in one action and leaves the requests that genuinely exercise your servers: the HTML pages and the API calls.

How to strip them

  1. Right-click your test case in the Navigator
  2. Select Configure → Strip Static Resources

Load Tester removes the static content and keeps the rest.

What gets removed:

  • Stylesheets (.css)
  • JavaScript files (.js)
  • Images (.png, .jpg, .gif, .svg, .webp, .ico)
  • Fonts (.woff, .woff2, .ttf)

What stays:

  • HTML pages
  • REST and API calls with their JSON responses
  • AJAX and fetch requests
  • GraphQL queries
  • SOAP and XML web service calls

Before and after

Suppose you recorded a single product-page load on a store built with Vite. The recorded test case looks like this:

GET  /products/42                          (the page, built by your server)
GET  /assets/index-4a8f9c2e.js             static
GET  /assets/vendor-9c2e4a8f.js            static
GET  /assets/index-8f3a2b1c.css            static
GET  /assets/logo-1a2b3c4d.svg             static
GET  /assets/inter-roman-7b1e0d93.woff2    static
GET  /images/product-42-hero-0d4f8a91.jpg  static
   ... 40 more .js, .css, image, and font requests ...
GET  /api/products/42                       API call (your server)
GET  /api/products/42/reviews               API call (your server)
GET  /api/cart                              API call (your server)

Out of fifty-odd transactions, only four touch your application. Every other line is a file the CDN serves, and each one carries a fingerprint that will become a 404 on your next release.

After Configure → Strip Static Resources:

GET  /products/42              (the page)
GET  /api/products/42           API call
GET  /api/products/42/reviews   API call
GET  /api/cart                  API call

Four transactions, all served by the servers you actually want to test. The test case is smaller, faster to configure, and it won't start failing the day your front-end team ships a new build.

When NOT to strip

Strip Static Resources changes what you are measuring. If your goal is the end-user experience, the full page-load time a real visitor feels including every image and script, then leave the static resources in. Stripping is for testing server and API capacity, where the CDN-served files are just noise. Decide which question you're answering before you strip.

For the full API-only testing workflow that builds on this, see Testing REST and Other APIs.