Because the site was built so that JavaScript is the only path to the content. When the script fails to load, times out, or hits an error, there is nothing underneath it. A page built with progressive enhancement still shows its text and still works, just with fewer flourishes.
We see this most often on sites that look modern and score badly. The design is current, the animations are smooth on a fast laptop, and the whole thing collapses into a blank screen on a train. The failure is not the framework. It is the assumption that everything will always load.
Progressive enhancement is the old idea that fixes this. It has been unfashionable for about a decade. It is quietly more relevant now than it was then, and the reason is machines rather than browsers.
MDN Web Docs defines progressive enhancement as a design philosophy that provides a baseline of essential content and functionality to as many users as possible, while delivering the best possible experience only to users of the most modern browsers that can run all the required code.
The order is what matters. You build the content layer first in HTML, so the page is meaningful with nothing else. Then you add CSS for presentation. Then you add JavaScript for behaviour. Each layer improves the experience, and no layer is load-bearing for the one below it.
MDN also distinguishes it from graceful degradation, which starts from the full experience and strips things away for weaker clients. MDN notes both approaches are valid and often complement one another. In our work the difference shows up in what happens on a bad day, not a good one.
No. It has changed audience. It used to be about supporting old browsers, which is now a small problem. Today it is about machines that read your page without running your scripts, which is a large and growing problem for anyone who wants to be found.
Browser support genuinely is not the argument any more. Chrome, Safari, and Firefox all ship modern features quickly, and the gap between them keeps narrowing. If that were the only reason for progressive enhancement, the critics would be right.
The reason it matters now is that a growing share of your audience is not a person with a browser at all. It is a crawler, an AI assistant, or a preview generator. Most of those either do not execute JavaScript or do so inconsistently, which puts your content behind a door they cannot open.
A lot more than most people would guess. According to the HTTP Archive's 2025 Web Almanac, the median home page shipped 697 KB of JavaScript on desktop and 632 KB on mobile, measured in the July 2025 crawl. The median HTML on the same pages was just 22 KB.
Sit with that ratio for a second. The actual content of a median page is 22 KB. The code required to display it is roughly thirty times larger. That is not a rounding error, it is the architecture of the modern web.
The trend is not improving. The same Web Almanac notes that in July 2015 the median mobile home page was 845 KB, and by July 2025 the same median page had reached 2,362 KB. Connections got faster, and we spent the gains rather than banking them.
Every kilobyte of that JavaScript is a thing that can fail. Progressive enhancement does not ask you to ship less of it. It asks you to make sure the 22 KB that matters does not depend on it.
It looks like ordinary HTML doing its job. Real links that point at real URLs. Forms that submit to a server endpoint. Content in the markup rather than fetched after load. JavaScript then intercepts those working things and makes them faster or smoother.
Navigation is the clearest example. A link should be an anchor element with a genuine href, not a div with a click handler. When it is an anchor, it works with JavaScript disabled, it opens in a new tab on a middle click, a screen reader announces it correctly, and a crawler can follow it.
Forms follow the same rule. Give the form an action and a method so it works on its own, then add client side validation on top for immediate feedback. If the validation script fails, the user submits the form and the server catches the error. Nobody is stuck.
Content is the one people argue about. Text that appears only after a fetch completes is invisible to anything that does not wait and execute. Rendering that text into the HTML at build time removes the entire class of problem, which is the approach we take on our own site.
Directly and heavily. Search crawlers and AI answer engines read what is in the HTML response. Google will render JavaScript eventually, but many AI crawlers do not render at all. Content that only exists after execution is content those systems cannot cite.
This is the practical reason the old philosophy came back. Getting quoted by ChatGPT, Perplexity, or Google AI Overviews depends on your text being present and parseable in the raw document. No amount of on-page optimisation helps if the crawler receives an empty shell.
We went through the mechanics of this in detail in our piece on why AI crawlers miss JavaScript rendered content. Progressive enhancement is the architectural answer to that problem rather than a workaround for it.
The same discipline improves plain search too. Clean, meaningful markup gives search engines a clearer structure to work with, which is the case we made in our post on why semantic HTML still matters.
Substantially, and mostly as a side effect. Assistive technology relies on the meaning encoded in HTML elements. When you build the content layer properly, screen readers and keyboard navigation tend to work before anyone writes a line of accessibility specific code.
Native elements carry behaviour that is genuinely hard to rebuild. A button element is focusable, activates on both Enter and Space, and announces itself as a button. A styled div needs a role, a tabindex, and keyboard handlers to imitate that, and most implementations get part of it wrong.
MDN lists accessible alternatives alongside feature detection and polyfills as core progressive enhancement techniques. That framing is right. Accessibility is not a separate workstream bolted on at the end. It is what you get when the base layer is built correctly.
Not at all. It means the framework should not be the only way your content exists. Server rendering, static generation, and prerendering all let a framework produce complete HTML up front, then take over in the browser. The layers stay intact.
Plenty of teams have made peace with this already. Modern frameworks ship server rendering as a default rather than an add-on, precisely because client-only rendering caused these problems at scale. The tooling has moved toward progressive enhancement even where the vocabulary has not.
Our own position is simple. Use whatever tool suits the job, then check what a client receives with scripts disabled. If the page is empty, the architecture is wrong regardless of which framework produced it.
We treat the HTML response as the deliverable and everything else as enhancement. Content is in the markup before any script runs. Navigation and forms work natively. Animation and interactivity are added afterwards, and their failure never removes access to information.
Restraint is most of the technique. Across the projects we build, our average PageSpeed score sits at 98, and that number comes far more from what we leave out than from clever optimisation. Fewer dependencies means fewer things that can fail on a slow connection.
We also set limits before the build starts rather than measuring afterwards, which we described in our guide to setting and enforcing a performance budget. A budget makes the tradeoff visible while it is still cheap to change.
The results follow the discipline. On the Axis Align build the site loads in 0.7 seconds at a 98 PageSpeed score, and on Ajust sign-ups rose 230%. Neither outcome required exotic engineering. Both required deciding what the page needed before deciding what it could have.
Turn JavaScript off in your browser and load your three most important pages. Whatever survives is your real baseline. If the pages are blank, start by getting your core content into the HTML response, then work outward to navigation and forms.
That single test tells you more than most audits. It shows you exactly what a crawler, an AI assistant, or a person on a failing connection actually receives. Most teams are surprised, and the surprise is usually the whole page.
You do not need a rebuild to improve this. Moving content into the initial response and making links and forms native is often a matter of weeks, not months, and it pays off in search, in accessibility, and in resilience at the same time.
If you want to know how your site holds up with the scripts switched off, we are happy to run that check and tell you what we find. Reach out through phoenix.studio and we will get back to you within 48 hours.
Tell us where you want to go. We'll tell you how we'd get you there.