Why your Nuxt/Next/SvelteKit apps still load slowly, and how Wait0 fixes it

Modern SSR frameworks like Next.js, Nuxt.js, and SvelteKit usually deployued to send every page request to the application Node.js/Bun/Deno server.

That is most obvious default, recomended in docs.

For every request, Node.js runs JavaScript, fetches data, renders components, and turns them into HTML.

Again. And again. And again.

Even when the result barely changed.

More servers don't make a request faster

Most production apps already have some reverse proxy in front of SSR. Nginx/Traefik/Envoy etc. Many setups also run multiple Node.js processes or replicas.

That helps with concurrency, but it doesn't remove the Node.js work.

A request still reaches your SSR server. Your server still renders the page. And if rendering depends on a slow database query or API, the user waits for that too.

A CDN or local statics servers helps enormously with static assets like JavaScript, CSS, fonts, and images.

But the HTML behind a dynamic SSR request often still has to reach your application.

Most pages don't need to be rendered every time

A lot of supposedly "dynamic" content changes surprisingly slowly.

Landing pages. Blog posts. Product listings. Contact pages. Documentation.

Even an e-commerce product page can usually survive showing data that is 10 or 30 seconds old.

And if one tiny piece of information really needs to be live, such as an exchange rate or stock count, the client can update it after hydration.

You probably don't need to render the entire page again for every visitor.

Meet Wait0

Wait0 is an open-source caching proxy built specifically to cache dynamic content, backed by SSR apps.

It sits in front of your SSR app, remembers rendered responses, and serves ready-to-go HTML directly from cache.

Your Node.js app doesn't even need to wake up.

Wait0 uses memory first for maximum speed and can overflow to disk when needed.

Both configurable in yaml:

storage:
  ram:
    max: '100m'
  disk:
    max: '1g'

server:
  # wait0 listens on this port
  port: 8082

  # and proxies to this origin
  origin: 'http://localhost:8080'

rules:
  - match: PathPrefix(/blog)
    priority: 1
    varyByQueryParams: ['page']
    # Stale-after signal: serve cached content, then refresh in background.
    expiration: '1m'

  - match: PathPrefix(/)
    priority: 2
    # Defaults to HTML and XHTML, keeping static assets out of wait0.
    cachableContentType: ['text/html', 'application/xhtml+xml']
    expiration: '1m'

It always works as Stale-While-Revalidate cache. When cached content becomes stale, the user can still receive the existing response immediately while Wait0 refreshes it in the background.

Fast now. Fresh next.

Keep the cache warm

Wait0 can also proactively refresh known URLs.

With WarmUp, you define how aggressively Wait0 should refresh pages in the background, so every request for know URLs will be fast and fresh.

Configured like this:

rules:
  - match: PathPrefix(/)
    warmUp:
      pauseBetweenRuns: '10s'
      maxRequestsAtATime: 20

You can specify how many requests at a time form Wait0 to origin and how many time to wait between loops.

The Sitemap module can discover URLs automatically from your sitemap and keep those pages warm before users even request them.

Config:

urlsDiscover:
  # Delay before the first sitemap scan; 0s scans immediately.
  initialDelay: '20s'
  # Rescan interval; omit to scan only once.
  rediscoverEvery: '10m'
  # Sitemap or sitemap-index URLs; origin-relative paths are also accepted.
  sitemaps:
    - 'https://example.com/sitemap.xml'

You also get a dashboard with cache usage and SSR statistics.

Drop it in front of your existing app

You don't need to rewrite your Next.js, Nuxt.js, SvelteKit, or other SSR application.

Put Wait0 in front of it and let your existing stack keep doing what it already does, just much less often.

• GitHub: github.com/devforth/wait0
• DockerHub hub.docker.com/r/devforth/wait0

Wait0 is built by DevForth. We build fast, scalable custom web applications where performance is treated as a core product feature.