# ct.css: a stylesheet that turns your document head into a warning system

> ct.css is a single diagnostic stylesheet that paints render-blocking declarations in your head red, orange or green, and tells you whether the file at fault is the one outlined or another. Useful for audits, limited by what CSS can see.

**csswizardry/ct** — Let’s take a look inside your <head>…

- Repository: https://github.com/csswizardry/ct
- Website: https://csswizardry.com/ct/
- Stars: 1,884 · Forks: 50
- Language: CSS
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/csswizardry-ct

## A diagnostic stylesheet, not a build step

The premise is that your head is the single biggest render-blocking part of a page, and that most of it is fine. A modern head contains a small amount of genuinely blocking CSS and a long tail of resources that do not need to block anything. The hard part is telling them apart by eye.

ct.css answers that with the oldest trick in CSS: a stylesheet that changes how elements look based on their attributes. Add it to a page and the head stops being a list of tags and becomes a diagram. The name comes from computed tomography, the X-ray metaphor in the project description, and the homepage at csswizardry.com/ct/ hosts a demo image with the colours applied.

There is nothing to configure and nothing to build. It is one file, ct.css, at the repository root, and the project has no releases, so you are always looking at master. The last push was on 2026-08-26 and the repository is not archived.

This is a diagnostic in the strict sense. It tells you what is render blocking. It does not measure anything, and the README never claims a score.

## Two colours and two border styles carry the whole reading

The demo image is decoded by a short legend in the README, and it is worth internalising because every use of the tool depends on it.

Red is an error and should be addressed. Orange could be problematic in certain scenarios. Green is fine and purely informational.

The second axis is the border. A solid border means this file is the problem. A dashed border means another file or files are causing problems with this file.

That second axis is the part that makes the tool interesting rather than merely loud. Most render-blocking warnings point at the offending tag. This one separates the resource that declares the blocking behaviour from the resource that is suffering because of it, which is the distinction that decides whether you fix one line or chase a cascade across three templates.

The colour scheme has one honest gap. Green is described as purely informational, so a green tag is not a certificate of correctness. It means the stylesheet found nothing it objects to, which is a weaker statement.

## Pasting one link tag, or injecting it from DevTools

The simplest usage is a single tag anywhere in your HTML:

```html
<link rel="stylesheet" href="https://csswizardry.com/ct/ct.css" class="ct" />
```

The class attribute is what identifies the diagnostic stylesheet to itself, and the file is loaded from the author's domain rather than from your asset pipeline.

For a page you do not control, or one you would rather not commit a debug tag to, the README ships a Chrome DevTools snippet that injects the stylesheet at runtime:

```js
(function(){
  var ct = document.createElement('link');
  ct.rel = 'stylesheet';
  ct.href = 'https://csswizardry.com/ct/ct.css';
  ct.classList.add('ct');
  document.head.appendChild(ct);
}());
```

That snippet is linked to Google's documentation on running JavaScript snippets on any page, which tells you where to paste it. Running it this way gives you the picture without touching the source, which is the sane way to audit a third-party template or a staging deployment you do not own.

For repeated use, self-hosting is the better answer, for two reasons: it removes a network dependency on someone else's domain during your audit, and it avoids the Content Security Policy problem described below.

## CSS sees the DOM, so injected scripts are a permanent false positive

The limitations section is the most useful part of the README, and the first entry under it sets the ceiling on everything else. ct.css only takes print stylesheets into account when it evaluates non-matching media types. Any other non-blocking stylesheet, a stylesheet with a media attribute your CSS logic does not recognise as print, may be reported as a false positive.

The second limitation is structural and cannot be configured away. CSS acts against the DOM and not the HTML, so a script element that was injected by JavaScript will be flagged as blocking even though the server never sent it in that position. Conversely, any script element that is removed from the DOM before the stylesheet evaluates will not be flagged at all.

Both directions of error come from the same fact. The tool reasons about what the browser built, not what the server sent. That is a sensible design for a stylesheet, and it is also why a single run is evidence rather than proof. A page that hydrates differently depending on the user agent can produce a different diagram for the same template.

The third-party detection is described bluntly: the check for whether something is a third party is naive at best. Expect misclassification there, and read the result as a prompt to look rather than a verdict.

## A Content Security Policy will block the diagnostic itself

The fourth limitation is the practical one that stops this working on a hardened application. If your app blocks CSS from the csswizardry.com origin, ct.css will never load and you will see nothing at all, with no error to tell you why.

Two documented workarounds exist. Self-host the ct.css file so the stylesheet comes from your own origin, subject to your policy. Or paste its contents directly into a style element in your page, keeping the class="ct" attribute on it.

The class attribute still has to be there, since the tool identifies itself by it.

Self-hosting is the better of the two for anything you plan to repeat. The repository root holds ct.css, index.html and a test/ directory, so the file is small enough to vendor, and vendoring also removes the question of what happens when the upstream file changes under an audit you are still running.

The licence on the repository is recorded as unknown, which is its own small argument for reading the file's terms before vendoring it into a commercial codebase rather than assuming it is permissive.

## Where this fits in an audit, and where it does not

The realistic use is a short review pass on a page whose head has grown organically. You paste the link, you look at the colours and the border styles, you fix what is solid and red, and you take the tag back out. The value is that it is a whole-page view of a problem that is otherwise invisible, since a render-blocking preload in a nested layout component produces no error anywhere.

It is not a substitute for measurement. Nothing here reports a timing, a byte count or a score, so it cannot tell you whether the page you just fixed is fast. The README's own framing, the ordered head diagram in optimal-head-order.jpg, is a target rather than a measurement.

It is also not a linter. There is no build integration, no CI mode and no exit code, and the project has no releases and no configuration surface. If you need something repeatable across a repository, this is not that tool and no amount of configuration will make it so.

What it is, precisely, is the fastest way to make an invisible property visible on one page at a time, with the caveat that it is looking at the rendered DOM and admits to being naive about third-party detection.

## Conclusion

Adopt ct.css as a review pass on a staging page or inside a DevTools snippet, where seeing every render-blocking tag at once is the whole point, and where you can afford the false positives the README warns about. Do not ship it to production, do not rely on its colour as a pass or fail signal, and do not treat a clean result as proof of a fast page. If your Content Security Policy blocks the csswizardry.com origin, self host the file or paste its contents into a style element with class="ct", and remember that the only accurate statement the tool makes is about what it can observe through CSS, which is the rendered DOM rather than the source HTML.

## FAQ

### How do I add ct.css to a page?

Paste a single link tag with the class attribute ct anywhere in your HTML, loading the file from https://csswizardry.com/ct/ct.css. For pages you do not control, the README also ships a Chrome DevTools snippet that injects the same stylesheet at runtime.

### What do the colours and border styles in ct.css mean?

Red is an error to address, orange could be problematic in certain scenarios, and green is fine and informational. A solid border marks the file that is the problem, while a dashed border marks a file that other files are causing problems for.

### Why does my Content Security Policy stop ct.css from working?

Because the stylesheet is served from the csswizardry.com origin, which a strict policy may block. The README gives two fixes: self-host the ct.css file, or paste its contents into a style element with class="ct" in your page.

### Does ct.css produce false positives?

It can. Only print stylesheets are taken into account for non-matching media types, script elements injected by JavaScript are flagged as blocking even though they were not in the server HTML, and removed script elements are not flagged at all.

### Can I use ct.css in production?

It is a diagnostic snippet for inspecting a page, and the README describes it as exposing potential performance issues. It reports no timings or scores, so it cannot measure whether a page is fast, and its own limitations mean a clean run is not a guarantee.

## Sources

- [csswizardry/ct on GitHub](https://github.com/csswizardry/ct)
- [Issues](https://github.com/csswizardry/ct/issues)
- [Project website](https://csswizardry.com/ct/)
- [README](https://github.com/csswizardry/ct/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/csswizardry-ct