-
Notifications
You must be signed in to change notification settings - Fork 86
Slow TTFB on initial document request #552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, what is the status on this? Because of the slow ttfb and the fact that we can't get the ISR working makes our service feel extremely slow in Netlify :( Thanks! |
It seems the issue is from Nextjs itself. When the page needs to be server side rendered (has getServerSideProps or getInitialProps). I had to disable server side rendering completely to make nextjs respond quickly. Related to: |
I have the same issue and am not using |
Can confirm. This occurs for me as well without using any SSR in my app. I'm using:
Might have to consider switching to other jamstack service providers until this is addressed. |
Hi @ascorbic sorry for tagging you directly here but do you maybe know if this is still a known issue? Since we're exploring netlify as an alternative for hosting at the moment this might be a deal breaker for us and there seems to be no clear answer here. Not sure if lindsay is still active in this project. |
Hi @tbgse . There is no specific reason why this would be slower on Netlify than anywhere else. We are releasing version 4 today which is a full rewrite of the plugin and includes ISR support, so it would make sense to try that out and see if it can be reproduced. If anybody still is experiencing slow loading, please share a link to the page in question, and also say whether it's slow when running locally too. |
We've recently launched a new Next.js site and we're seeing a ~1-2s initial server response time on PSI for the home page. The home page is using The site is running NextJS v12.0.7 and @netlify/plugin-nextjs v4.2.7 |
@rshackleton can you share the build logs? |
@ascorbic can I email you them somehow to save me having to edit out client names etc? |
@rshackleton you could share a link to them here and I could access them, if that's simpler |
@ascorbic we use our own CI to build the site so I can't share a link to the logs, it would be easier to email or DM them |
Ah ok. You can email them to matt.kane @ netlify.com |
@ascorbic I have emailed the latest build log to you, hope that helps! |
Thanks, @rshackleton
Do you have rewrites or redirects that match these? If so, we can't serve them from the CDN, because they need to run the rewrites or redirects in front of them. Could you share the relevant rewrites and redirects from your next config? |
@ascorbic we have a redirect which needs to run for all requests to serve an unsupported browser page for ie11. This is using the next.js redirects as Netlify don't support redirecting based on user-agent because it isn't best practice (I don't argue this, but ie11 is ancient and user-agent sniffing for that one browser is arguably the best way to handle it).
If Netlify had allowed redirecting based on user-agent then we wouldn't need to use the option in nextjs which I assume means all static pages aren't served statically? |
Ah, I understand. This is soemthing you could do with an Edge Function. We will be handling this automatically when we shift all of our Next rewrite, redirect and header handling to the edge, but for now you could create a simple function that achieves this. SOmething like: export default async (request, context) => {
if(request.headers.get('user-agent')?.includes('Trident')) {
return context.rewrite("/unsupported.html");
}
}; |
Can't quite get that to work, I've added a new edge handler function as per the docs. It worked locally when running The build log includes the edge function bundling:
|
Have you listed it in your netlify.toml? |
Hmm. Could you share the deployment part of the logs too? |
Yep, I have emailed you the log for the netlify deployment |
Thanks. I'm looking into it |
@ascorbic have you been able to make any progress with this? |
@ascorbic sorry to keep chasing but this is a pretty significant issue for our client |
Hi @rshackleton. Sorry about the time this is taking. I did some digging into it to no avail so far. To help me diagnose it, could you share the content of |
(This is after running a build) |
@ascorbic embarrassingly I think I know why it isn't working, we're deploying with an older version of the CLI. 🤦♂️ I'm going to look at updating to the latest version and will check back if it works. EDIT: Ignore, I've checked and we did update to 10.5.1 on our preview deployments to test the edge functions so it isn't quite my incompetence yet. |
@ascorbic I've run {
"bundles": [
{
"asset": "684f0e2b3220d34da028612342218199150bba860ea8c31c138332c73d37f9be.js",
"format": "js"
}
],
"routes": [
{
"function": "unsupported",
"pattern": "^/.*/?$"
}
],
"bundler_version": "1.4.1"
} There is also a file called EDIT: Also confirmed this same file is output when running the |
OK, and to confirm the deploy logs don't show it as uploading the edge function? |
I can't see anything indicating it is uploading anything other than the 3 functions normally created by the nextjs plugin.
|
Thanks. So it's still that while the edge function is being correctly built and added to the manifest, it's not being uploaded. I'm going to consult with the team that handles the CLI here. |
@rshackleton This should be fixed in |
@ascorbic that has resolved the issue for us, the edge functions are being deployed correctly. Thanks. :) |
Awesome! Thanks for the update |
this is moving the conversation that started on community to here so we can explore if/how the plugin is contributing to or not addressing this behavior.
The text was updated successfully, but these errors were encountered: