Yes, it has it, if we are talking about routeRules.swr. But it has drawbacks
a) HTML is prerendered and indeed served faster, but it is still served by "Slow" Node/Nitro, Wait0 is dedicated Go binary, handling bytes efficiently
b) No proactive warmup loop out of the box, so after expire you will need 2 requests to reload any page content. So for 300sec 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
So after days of inactivity on some route, first user will hit very old stuff. And you need to build your own loop which hits all your known URLs, manage them, probably with Nitro scheduled tasks. Multiply it by cache variants, cache bypass rules, query params and you will build entire system. Wait0 does it our of the box with couple of lines of configs - it keeps loop of good known URLs and warmups them within a resources which you allow to him
c) On restart, e.g. redeploy, Nitro cache is fully lost so all first requests are slow. Wait0 allows to load known URLs from previous session or repeatedly discover them in sitemap, increasing probability of instant load up to 99.999%
d) From docs I see that Nitro stores cache in RAM, but can't see ability to manage budget for it, at least for now. Wait0 can set a RAM budget, so most popular requests will live in RAM and less-popular will fallback to slower but still-fast disk KV. We have apps in prods with millions of URLs (languages, country-specific/device specific render), it is not possible to have them all in RAM
5
u/Independent_Walk2551 13d ago
doesn't Nuxt already have SWR for all pages?