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