Progressive enhancement never really left. It just spent a decade being drowned out by framework churn and the assumption that JavaScript is always there, always fast, and always welcome. That assumption keeps getting tested by flaky networks, CPU-throttled devices, aggressive ad blockers, and the growing share of users on lower-end hardware. The teams shipping the most resilient, performant sites right now are the ones who never abandoned layering.
What progressive enhancement actually means
The principle is simple: start with something that works for everyone, then layer capabilities on top for environments that support them. It is not about building for 2005 browsers. It is about building with a clear priority order: content first, behavior second, enhancement third.
A strong progressive enhancement baseline means:
- HTML delivers real content. Not a skeleton, not a spinner, not an empty
<div id="app">. Actual content, readable by a browser, a screen reader, and a search crawler. - CSS handles presentation. Layout, color, typography, and basic interactive states via
:hover,:focus, and:checked. None of this requires JavaScript. - JavaScript enhances. It adds transitions, real-time validation, infinite scroll, and optimistic UI. These improve the experience but are not load-bearing.
When something fails in layer three, layers one and two still hold. That is the contract.
The web’s durability comes from its ability to degrade gracefully. Progressive enhancement is how you make that durability deliberate.
Why it matters more now than it did five years ago
The JavaScript-everything era produced fast developer experiences and slow user experiences. A single-page application that ships 400 kB of JS before rendering any content makes a silent bet: the user’s device is fast, the network is reliable, and nothing in the JS dependency tree has an error. That bet fails more than teams admit.
Several forces are pulling the industry back toward a more layered approach.
Performance budgets are tighter. Core Web Vitals tie real business metrics to loading behavior. LCP rewards sites that put content in the initial HTML. INP rewards sites that don’t block the main thread with parse-time JavaScript. A no-JS baseline starts with both of those wins built in.
Server-rendering is mainstream again. Astro, Next.js App Router, SvelteKit, and Remix: every major framework now defaults to rendering on the server. This is progressive enhancement applied at the framework level. You get HTML from the server; JavaScript hydrates on top of it. The static, server, and edge rendering conversation is really just progressive enhancement at the infrastructure layer.
Network conditions are unevenly distributed. A user on a train, in a car park, or on a plan switching between towers will frequently be on a connection that degrades mid-session. An app that requires JavaScript to show any content punishes that user with a blank screen. An app built on a solid HTML foundation shows the content immediately; enhanced interactions may lag, but the core experience holds.
JavaScript errors are runtime errors. A CSS bug looks bad. A JS error can make a page completely non-functional. With a progressive enhancement approach, a broken enhancement degrades to the base experience rather than breaking everything.
Building a no-JS baseline that holds up
A “works without JavaScript” baseline does not mean plain or ugly. It means structural thinking applied before adding behavior.
Forms
HTML forms submit to a URL and process server-side. That is fully functional without JavaScript. Enhancement layers on top: client-side validation, async submission to avoid full page reload, inline error messages. The baseline works; the enhancements are polish. This pattern alone makes a significant share of user-facing functionality resilient.
Navigation
A <nav> with anchor tags is the baseline. JavaScript can enhance it with animated transitions, prefetching, or a mobile drawer. But if the JS fails or loads slowly, navigation still works. The enhancement is additive, not load-bearing.
Interactivity with HTML and CSS
A surprising amount of interactive UI is achievable without JavaScript. The <details> and <summary> elements give you native disclosure/accordion behavior. The :checked pseudo-class with a hidden checkbox enables toggles, tab panels, and modal-like patterns. CSS :has() opens up reactive styling based on form state. Lean into what the platform provides before reaching for a script.
Media and images
Images load or they don’t. Progressive enhancement for images means srcset and sizes attributes for responsive loading, loading="lazy" for below-fold images, and a meaningful alt attribute for when the image fails. None of this requires JavaScript. See the image optimization guide for the full treatment.
The layering framework in practice
When you sit down to build a component, work through three questions in order:
- What is the minimum HTML needed to convey the content or action? Write that first. Validate it, check it in a screen reader, submit it without CSS and JavaScript enabled.
- What CSS is needed to make this presentable and usable? Styled but not JavaScript-dependent. This includes focus styles, hover states, responsive layout.
- What JavaScript would improve this? Not make it work. Improve it. Improved means meaningfully better for users who have it, not broken for users who don’t.
This is not slower development. It is a different order of operations that tends to produce less total code, fewer edge cases, and more maintainable components. The discipline pays back quickly.
Common objections, addressed directly
“We’re building an app, not a document site.” The distinction matters less than teams think. Even web applications have authentication pages, error pages, onboarding flows, and account settings. In these areas, rich interactivity is incidental and a solid HTML baseline costs almost nothing. You pick where to invest in enhancement; that doesn’t mean progressive enhancement is irrelevant to the rest.
“Our framework handles all of this.” It might. Astro is designed around progressive enhancement. It is our default choice for marketing sites for precisely this reason. But a framework that renders on the server can still ship broken-by-default experiences if the team does not apply the layering principle. Tools enable the pattern; they don’t enforce it.
“Accessibility is covered by our ARIA implementation.” ARIA describes semantics; it does not create functionality. Accessible components built on progressive enhancement are more robust than accessible components built on JavaScript-dependent ARIA, because the underlying HTML structure is already semantic. The two concerns overlap; progressive enhancement tends to raise the floor. Accessibility is a design decision, and the same is true here.
“Our users are all on fast devices.” Your analytics show you only the sessions that completed. They don’t show the sessions where a user hit a blank screen, waited, and left. Survivorship bias in performance data is real.
Performance and resilience as the same thing
A page that sends less JavaScript is faster. A page built on HTML-first semantics is more accessible. A page that functions without JavaScript is resilient to a broken CDN, a failed A/B test script, or a third-party analytics tag that throws an error. These are not three different goals requiring three separate efforts. They are the same goal achieved by one approach.
The cost of a slow website is real and measurable. But the cost of a broken website (a page that shows nothing because a script didn’t load) is worse. Progressive enhancement addresses both simultaneously.
How Strynal approaches it
At Strynal, progressive enhancement is not a policy we debate. It is the default orientation for every web project we build. We start from the HTML structure before writing a line of JavaScript. We test forms without scripts. We validate navigation at the baseline. We add enhancement layers that genuinely improve things rather than gates that require JavaScript to pass.
This applies whether we’re building a brand site for a company redefining its category or a complex application for an enterprise client. The same layering principle scales. It produces sites that are fast, indexable, accessible, and resilient. In 2025, that is table stakes for anything claiming to be well-built.
If you want a site engineered to hold up under real conditions, tell us what you’re building and we’ll scope it together.