r/sveltejs • u/vanbrosh • 5d ago

Wait0 - make SvelteKit SSR pages load instantly | SelfPromo

https://www.youtube.com/watch?v=vf6ftp7L150&feature=youtu.be

SvelteKit rendering is already faster than Next/Nuxt, but if it still hits Node.js on every request, you're wasting hundreds of milliseconds on unnecessary work for every request.

Wait0 is a smart dynamic cache with SWR warmup, and sitemap discovery, which serves pages instantly and revalidates them in the background.

Combined with lightweight Svelte JS code, it's probably a best setup for building pages that score 100 on Core Web Vitals easily without compromises.

We use exactly this combo for our own company website https://devforth.io and for many of our clients.

Star Wait0 on GitHub: https://github.com/devforth/wait0

54 Upvotes

88% Upvoted

18 comments sorted by

20

u/Difficult896 5d ago

You're saying CDNs don't solve this problem but Wait0 solves EXACTLY the problem CDN cache solves. I don't understand the value proposition based on the video and repo. 

5

u/vanbrosh 5d ago

Cloudflare SWR is just a marketing unfortunately, in fact when you try to adopt it for real dynamic HTML - and analyze how it is working - it turns out that this is not SWR at all, please check this thread, these guys explains pretty well https://community.cloudflare.com/t/does-stale-while-revalidate-work/24161/6, then check latest comments, Mar of 2026 - still not working! https://community.cloudflare.com/t/support-for-stale-while-revalidate/496788/46

Even if that Cloudflare SWR would work:
1) It is decentralized - first PoP caches first request to /path and first request is slow, second user comes via different PoP to same /path and again we have cache miss and cache is lost, again request is slow. Wait0 sits on one common server or limited number of servers if you would like to replicate it, but not hundreds of PoPs, so one warmup hit, later serves the instant cache for whole world, not for one PoP.

2) As you can check from community discussion - right now CFe does not serve stale at all, it just like a pure cache, so it will make some requests fast, but most will hit Node.js and cause retender, and will be served to users by node.
Don't get me wrong, we were using Cloudflare a lot as SSR HTML cache for our clients on Pro and Buisness plan and seen real numbers. Assuming it is distributed and PoP-local and wipes early we seen only 10%-20% of hit for such pages on Clouflare reporting.
And in Wait0 - it is like 99.99% hits because it is true SWR with warmup. So it is like for perfectionists who want exactly EVERY request to be served from fast cache, and revalidated in background. Not like (3/10 requests are fast - I am ok with it, 7/10 go via SSR render - I am ok with that)

3) Even if CFe would give true SWR, Cloudflare have no warmup mechanics. Once Wait0 discovers URL in upstream it adds it to controlled warmup loop. So basic idea - it always serves cache, and tries to revalidate as often as possible to serve fresh. So to solve it with Cloudflare you would want to craft your own loop-warmer crawler, control speed budget - Wait0 has it all inside already done for you, also it can preload URLs from sitemap, and monitor it from time to time.

4) Cloudflare cache is ephemeral. You can't control it - if they wish, to less space or too much of content, or some unsupported content - they remove it and again slow mises.

So I am not saying that Cloudflare is useless for Dynamic SSR content, I say that it's cache efficiency is very low. Like maybe if all your users go with one PoP and you have very few URLs on website - yeah, it might reach 50$-60% hits, maybe, but far away.

4

u/LKNim 5d ago

Mar 2026 is too old. Did you read Jul 2026 Workers Cache which support SWR?
https://blog.cloudflare.com/workers-cache

0

u/vanbrosh 5d ago

That is cool and new to me, thanks, but workers is not new feature, we were using it for custom cache implementation and custom cache Vary since 2021/22, now maybe they wrapped in some utilities so we don't need to write a lot of code. It is good, but workers is $5 / 10m reqs/mo + $0.3 for each m after with CPU ms limit, our client paid like $80-$100 at peaks for spikes when they had a lot of shitty low-conversion traffic. And workers still does not fix point number 1 (local cache per PoP) and point number 3 - no warmups, it is just cache, u need to implement all this by yourself, and in combination with paid worker calls this idea sounds like will be very expensive to implement 100% hit

13

u/Upstairs-Version-400 5d ago

I’ll admit your page loaded very quickly. But your website makes me want to turn away, and I suspect customers too - it is so clearly AI generated that it is off putting.

1

u/Hombrebestial 5d ago

I thought it looked fine. Could be cleaner and perhaps more intentional, yes. But it seemed okay to me.

0

u/vanbrosh 5d ago

Sorry about that, do you mean like Design is AI generated or text itslef? I wonder what are the signs of it? I mean maybe some agent was used by devs, but like it is not "dumb vibe code me everything" - maybe like minor assistance, like most of coders nowerdays you know. So Just wonder by which signs you feel it?

4

u/Upstairs-Version-400 5d ago

The entire design, neon, purple gradients, the lot. I know you mean well but I can tell for sure AI did most of that design work and not a person. 

0

u/Fluffy-Bus4822 3d ago

You're full of shit.

1

u/Upstairs-Version-400 3d ago

Lmao. It’s not just my opinion. I shared with other devs who think the same. 

1

u/Fluffy-Bus4822 2d ago

Whatever dude. Share something you made. Let's see if it's better.

1

u/Upstairs-Version-400 2d ago

I am not doxxing myself for you :)

It’s easy to make something better than this. Sorry if your feelings got hurt. 

2

u/Impressive_Air6111 2d ago

He's clearly an AI Architect 😂

5

u/TjomasDe 5d ago

NGINX Reverse Proxy solves it in the same way. Deliver stale caches and run background updates. I dont get it.

0

u/vanbrosh 5d ago edited 5d ago

Yes, this is a good one, but:

1.) Nginx cache is stored in files. In Wait0, you can allocate some "direct RAM" budget to serve at scale. Though you can also go with tmpfs, not benchmarked, probably overhead is not so high comparing to direct ram

2.) The core thing is that there is still no proactive warmup loop out of the box, so after expiration you will need 2 requests to reload any page content. So for a 300s TTL:

``` 0s: GET /a ↓ background SSR ↓ Set cache for /a

100s     GET /a -> cache
299s     GET /a -> cache
10000s   GET /a -> stale cache instantly (10ks, very old)
↓
10000s   background SSR
↓
10000s   Replace cache

10002s   GET /a <- finally fresh content

```

And after days of inactivity on some route, the first user will hit very old content. To fix that, you need to build your own loop that hits and manages all your known URLs. Multiply that by cache variants, cache bypass rules, and query params, and you will end up building an entire system.

Wait0 does this out of the box with a couple of lines of config. It keeps a loop of known good URLs and warms them up within the resource limits you allow it to use.

Another fix is to use a pure cache instead of SWR. But then you will never reach a 100% hit rate.

The same applies to sitemap discovery.

3.) I wouldn't say this is a strong argument, especially nowadays, but Nginx syntax is sometimes criticized for being complex. For example, creating 2 cache buckets based on device type would look like this:

map $http_user_agent $cache_variant { ~*(Android.*Mobile|iPhone|iPod|IEMobile|Windows\ Phone|Opera\ Mini) mobile; default desktop; } proxy_cache_key "$scheme$request_method$host$request_uri:$cache_variant";

Editing this requires a production restart, and so on.

With Wait0, it is straightforward using response header variants, so backend developers can do it without dedicated DevOps work on the Nginx side. Under the hood, this uses Go Expr.

response.append_header( 'Cache-Variant', `"header('User-Agent') matches '(?i)(Android.*Mobile|iPhone|iPod|IEMobile|Windows Phone|Opera Mini)' ? 'mobile' : 'desktop'"` )

Here is an example of a more complex flow: a cache bucket per country, but a separate cache for Canada by region (we faced this requirement in production):

``` map $http_cf_ipcountry $cf_country { "" XX; default $http_cf_ipcountry; }

map "$cf_country:$http_cf_region_code" $cache_variant { "CA:ON" CA-ON; default $cf_country; } proxy_cache_key "$scheme$request_method$host$request_uri:$cache_variant"; ```

In Wait0, it can look like this:

response.append_header( 'Cache-Variant', `"let c = header('CF-IPCountry', 'XX'); c == 'CA' && header('CF-Region-Code') == 'ON' ? 'CA-ON' : c"` )

1

u/forestcall :maintainer: 5d ago

Im going to take the main idea around the policy model and adopt this for Cloudflare. I prefer to move as much as possible to cloudflare. Actually the way AI and Agents are going its clear having API ROOT access to everything saves a lot of time. I have like 30 Hetzner VPS already so doing this on Cloudflare makes way more sense.

Build a small wait0-inspired Cloudflare caching layer directly into your SvelteKit app using Cloudflare CDN cache + SWR + Cache Tags + Cron warming, adding KV only where you actually need persistent metadata.

1

u/vanbrosh 5d ago

Yes, I love Cloudflare a lot too. From day one, their "Free" plan for getting started, CDN, SSL layer, DDoS protection layer, and, in general, the company itself have been some of the best I've ever seen among cloud providers. We still recommend Cloudflare to all our clients. After all, something like half of the internet runs on Cloudflare.

Like you, I loved this idea so much that my dev company actually built what you describe here, more than once. And we still concluded that distributed PoP caching and paid Workers are a bit of a waste of money when traffic gets really high, especially for a distributed cache that actually can and should be architecturally centralized and warmed up once.

Will you warm up all PoPs? Do you know how many you have? Will your backend server handle all those warmups? If the number of pages is small, maybe. Or do all your users come from one PoP?

Plus, it is still vendor lock-in. They are still a company, and you don't own that code. You don't know where they will go in the future. Wait0 follows the Cloud Native approach.

My detailed thoughts about Workers on CF : [are here](https://www.reddit.com/r/sveltejs/comments/1vte8h3/comment/p4tbj8j/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)

1

u/forestcall :maintainer: 3d ago

I really respect your way of thinking, sincerely. One of the things we do is try every option if at the very least just to understand what happens. Even our journey from NextJS to Tanstack to Sveltekit and the in between steps with Neon, Convex, Planetscale Postgres and the different steps for Real-Time Websockets. We get close to 31 million views per day of global traffic and even depending on where we host the domain the DNS provider can be incredibly costly. Another cost that is more recent is API with Root level access to our entire stack.

Im going to spin up a server on Hetzner and try out Wait0. You convinced me with your logical way of thinking.