High TTFB with Pages
Hi!
So, there're kinda two issues here.
First one is a high TTFB, averaging 500-800ms for a static Nextjs website.
I tried to fix that by creating a cache rule for the website in Cloudflare. However, after I had done that, in some occassions the website returns a blank page with no content. Refreshing a couple of times sometimes returns the correct content, looks like something went wrong with caching.
However, is it normal that the TTFB is so high with CF Pages without any extra caching setup?
54 Replies
Guess it's something with the app router, if the connection is slow, the entire page is blank which I think is getting cached by some edge locations.
I do think there's an issue here tho... CF Pages Functions (for a static site) reply really slow
You're using next-on-pages or static export? Link to your site?
Next-on-pages. I currently reenabled my cache rule so it's faster (https://spectate.net) but on the pages url it's slow: https://spectate-marketing-frontend.pages.dev/
You can see here where I disabled the cache rule, TTFB goes through the roof. Can't remember it was like that before without the cache rule
next-on-pages is special and uses a function to handle all requests. TTFB is really low with CF Pages and static assets, but this isn't just static assets
That's what I thought too, the app itself (app.spectate.net) is a separate CF pages project, also Nextjs App Router with next-on-pages, its TTFB is quite low, total response takes 200-300ms including authentication etc.
This website is just a static marketing site, it doesn't do any serverside stuff, started to happen when migrated to App Router though... so I guess that has definitely something to do with it
and maaaaaybe I see something, will get back to it asap
Is the site open source or any more information? I'd ask @Better James for his help if he has time, he is the resident nextjs person and maintainer of next-on-pages. Not really sure if there's enough information to go off though. Maybe something that changed recently or some known app router quirk
Edit: opps, that was supposed to be a silent ping 
could trry #next-on-pages as well
could trry #next-on-pages as wellMy initial thoughts would be that your route is opted into the edge runtime and doing SSR stuff, maybe sending fetch requests that take a while to complete, before returning back to the client
Yea I see what's happening here
Before with the pages dir, I had getStaticProps()
During the rewrite to App Router, I of course removed that one. But still opted in to next-on-pages due to api routes. Note: all content is static from the CMS. But I guess it's now retrieving those as I haven't set the "dynamic" property, going to try to play with that
I thought it wasn't necessary as it doesn't do any fetch or other server side calls but maybe (have to check) it's because I accidentally made the root layout an async function
Generally my view is to only opt routes into the edge runtime that need to do work on the server, otherwise leave them opted out and they'll get prerendered at build time
Ahhh really? That's interesting, didn't know that, I just opted in everything to run on edge. Woops.
Or at least the root layout, which forces sub segments to be edge too
I know this isn't CF pages related, but, I'm getting this now (which is why I always opted in for edge). These should only get the latest content from the CMS, they also have
generateStaticParams. Am I missing something here with next-on-pages?
Yeah so with dynamic routes that get prerendered, they generate a fallback nodejs function. To avoid generating a fallback function and to only prerender routes for the ones provided in
generateStaticParams, you can do export const dynamicParams = false;Ahhhhhhhhhhhh alright!
I saw that in the docs indeed
They're SSG now, but still complains about edge (same error as before)
did you mean to also enable edge, no right?
No
Umm, are you sure you put the export and that you're returning paths in generateStaticParams?
Yep :S Very similar to getStaticPaths, and if I build and run locally it does get the paths
oh wait a sec, nope it's throwing 404's (I tested with edge still on a couple of mins ago woops)
that's odd
if it returns an empty array it'll try to generate a fallback function instead and ignore the route segment option saying not to 🙄oh dang. this change... 
^screenshot from the Prismic docs
notice the difference.. woops.
I'm still using the asLink helper which was required with getStaticPaths
smh
The pain hahaha
Aaaanyway, regarding the TTFB
I found it pretty odd that the homepage (which isn't from the CMS, thus static) was so slow
especially compared to my app itself which has auth etc
This is what I saw in the Function Metrics. The worker functions were having a hard time
Oh my gosh
Also received a couple of "CPU limits exceeded" errors which I never experienced with my app with auth middlewares etc.
Yea that was my reaction too 😂
For reference, this is the app ^
Well, I've not seen someone that high before I'll be honest. I wonder if that was because it was all on the edge runtime maybe when it didnt need to be
Hmm, the app is also on the edge router for every page since I set it in the root layout
Then my second message would that your root page is probably doing some heavy lifting
It was async, but didn't do anything. Obviously an issue, but don't think it would cause this high of a cpu time
For comparison, my blog (all prerendered) ranges from taken 1ms-14ms. The app directory demo which has SSR ranges from 2ms to 120ms, depending on the route
Yep that's what I experience too with the app
So you have to have been doing something on the root page that was taking years
There is no chance in a million years that the routing we do would take that long
I'm fine sharing it tbh - https://gist.github.com/bjarn/9d54047240b005af1cf7b07cd9cb1468
Really that was it, I'm just as surprised haha
the page itself didn't have functions either, but was async
maybe that really is the issue
I'm going to see and build again
That's crazy
also that's the layout not the actual page, i meant it was something on the page that was taking years not the layout, since the layout will apply to all the other routes that work fine
Yup, same for the page, doesn't do anything special
https://gist.github.com/bjarn/565c926daabed9ef2d10a57082f03d82
How bizarre
yuuup
Well, it's a nextjs thing for sure.
nothing to do with next-on-pages or CF
Insane.
😔
I can feel the homepage being slow when navigating too while other pages are instant
wow.
I found it
You're not going to believe me
It's... an SVG (which is a component precompiled by svgr)
On the website, you see that giant world map with all the dots? That's the one. That caused all the issues.
Oh wow lmao, how unfortunate...
It contains too many layers, badly optimised
never thought it could be the culprit. I guess nextjs was rendering it on the worker, causing these issues
What a relieve haha, thanks btw to the both of you for helping out!
Glad to hear all is well now 🙂
Much better 🙂
😍