The Web Isn’t a Set of Pages Anymore — It’s a Runtime System

There’s a quiet lie modern web applications tell us.

Open any product in a browser and it looks structured:

There’s a homepage
There are “pages”
Navigation suggests hierarchy
URLs imply boundaries

It feels mappable.

So I tried mapping it — not as a designer, but as an engineer asking:

If I give a machine a starting URL, can it discover the same product structure a human experiences — reliably and at scale?

What I found was this:

The web isn’t a set of pages anymore.
It’s a runtime system.

Once you accept that, you stop thinking in pages.
You start thinking in execution graphs.

1. Why Lighthouse and WAVE Are Necessary — But Not Sufficient

Tools like Lighthouse and WAVE are foundational.

Lighthouse measures:

Performance
Accessibility
SEO
Best practices

WAVE surfaces accessibility violations directly in rendered output.

They provide clarity about a page under defined conditions.

But they share a structural assumption:

They treat your app as a static snapshot of a single route at a single moment.

They answer:

“How healthy is this surface?”

They do not answer:

“How reliable is the journey across transitions and states?”

And that’s where complexity lives.

2. The Modern UX Problem: Journey Reliability

Consider a simple user intent:

Check pricing → Compare plans → Start trial

In a traditional site:

/pricing → /plans → /signup

In a modern application:

UI changes without route transitions
Feature flags alter rendering
Auth state changes entry points
Multi-step flows live inside a single URL

The journey is not a sequence of URLs.

It’s a sequence of state transitions.

The architectural unit is no longer the page.

It’s the transition surface.

3. When a URL Stops Meaning a Page

Three common patterns break naive mapping.

A) One URL, Many Experiences

Same URL:

New user sees onboarding
Returning user sees dashboard
Logged-out user sees marketing

One URL. Multiple realities.

B) Many URLs, One Experience

/pricing
/pricing/
/pricing?utm=linkedin
/pricing#faq

Many nodes. One experience.

C) No URL, Real Journey

Some of the highest-friction steps happen without navigation:

Authentication modals
Inline drawers
Client-side state machines

If you audit URLs, you miss the journey.

The real unit becomes:

A stateful view snapshot.

4. Your App Is a Graph, Not a Hierarchy

Most teams talk about:

Navigation trees
Pages
Sections

Runtime systems behave as directed graphs:

Multiple entry points
Cycles
Dead ends
Hidden nodes

There are two graphs:

The designed graph (what Figma suggests)
The executed graph (what the runtime produces)

UX breaks in the gap between them.

That gap also explains:

Path-specific performance regressions
Accessibility failures after hydration
SEO breaks on client routes
Screenshots showing incomplete UI

You can pass Lighthouse and still ship a broken journey.

Because the journey is the product.

5. Why Journey Discovery Is Architectural

Trying to model journeys programmatically exposes architectural truths.

A) The Page Is Not Stable at DOMContentLoaded

Modern apps:

Render shell
Hydrate
Fetch
Re-render

Capture too early → capture a lie
Capture too late → lose scalability

This isn’t crawling.
It’s orchestration.

B) The Link Graph Is Polluted

Modern sites generate massive link noise:

Assets
API endpoints
Framework internals
Tracking variants

Separating signal from infrastructure is architecture.

C) Depth ≠ Complexity

Depth 2 may cover the entire product.
Depth 6 may still miss core flows.

“Max depth” is not a crawler setting.
It’s a structural hypothesis.

6. A Better Mental Model: Journeys Are Hypotheses

Instead of:

“Discover all pages.”

Think:

“Infer likely journeys and validate them with evidence.”

Evidence might include:

Repeated navigation patterns
CTA clustering
Breadcrumb structures
URL canonicalization
Screenshot similarity
Template clustering

This is where UX meets architecture.

The goal is not to crawl everything.

It’s to discover:

Real entry points
Real conversion paths
Real drop-offs
Silent failure screens

7. Journey Quality Is the Missing Metric

Most teams measure:

Page performance
Component bugs
Accessibility score
SEO score

Users experience:

Time-to-success
Path clarity
Consistency
Predictability
Trust

Journey quality is architectural:

Routing model
State transitions
Loading strategy
Error invariants
Navigation consistency

8. The Conclusion I Didn’t Expect

I began trying to capture a website.

I ended realizing:

The next layer of frontend maturity isn’t auditing pages.

It’s auditing systems across journeys.

Lighthouse reveals page-level truth.
WAVE exposes accessibility surfaces.

But the future is:

Journey discovery
Journey classification
Path-level regression detection
Journey-level metrics

Because users don’t experience scores.

They experience paths.

Closing Thought

Frontend is not just UI.

At scale, frontend is:

Distributed system behavior in the browser
Orchestration under uncertainty
State, rendering, and performance as a runtime

Learn to see your product the way the runtime sees it.

Not the way the sitemap pretends it is.

Tags: User Journeys, Product Design, Frontend Architecture, Software Architecture, System Design