-
Notifications
You must be signed in to change notification settings - Fork 27.8k
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
Slow TTFB (Time to First Byte) for a very simple production deployment. #4646
Comments
As you can see here: the TTFB is considerably lower: The only changes I made:
Then I ran
I made no changes to the code. |
I've cleaned up, however I am still seeing the same results, while your deployment has indeed a smaller TTFB Example - https://satv-tgrbmyzrec.now.sh/ |
Additionally I have tried Nextgram example app - https://github.com/now-examples/nextgram I think it's quite important if there is a possiblity to cut 400ms from TTFB |
Could you check the latency on http://sfo.now.sh/ and http://bru.now.sh/? Also what location are you testing from? |
SFO avg. 200-250ms I am testing from Romania with 290mb/s internet speed. |
So I've scaled https://satv-tgrbmyzrec.now.sh/ to bru and the TTFB is ~200ms. It seems like the majority is latency 🤔 |
I do not necessary disagree with what you say, however interestingly your example - https://dfhjdsjfhjdshjfhjhjksdf-ilsvtjqpfn.zeit.sh/ |
https://ietv-tszrtadfvd.now.sh/ on this one I have region BRU with scale rules min:3 max:3 It's interesting that your examples come out with 200ms and mine with 700ms TTFB time. I am not sure I could get on your examples 200ms if I am getting 700ms on mine due to latency. Do you have any ideas or suggestions? |
I observed the same behavior. For the the static frontpage of my app (Link: https://wwwtest.urteile-gesetze.de/, Premium plan), I got 270ms TTFB. I have the impression that there is simply too much load on the zeit.co servers. This makes page-rendering on the server very slow. I will benchmark the rendering-speed this weekend. |
I'm seeing similar behaviour on SF01, however, my TTFB is consistently 1.5-1.6 seconds |
Hello! I'm from Chile, I have a spa test in the firebase housing and this load is very fast. Now, develop another test spa with Next.js that you implement in Zeit hosting (sfo.now.sh) and the first load is always slow :( very slow |
@danbeck your app has a 110ms ttfb for me. @jhalvorson based on your profile you're from Edinburgh, try scaling to BRU1, it'll avoid a roundtrip halfway around the world. @robertoaikode what's your deployment url? @driglou based on You can check this using |
Hey, sorry meant to say BRU1, not SFO1. The TTFB is ~350 this morning which is way better than last night (scaled to 2 auto). I'll keep an eye on it and reach out if it gets back to the slower speeds. I presume a Next.js GitHub issue isn't the best place to reach out for Now issues, should that be the Slack channel? |
Yeah, definitely 👍 https://zeit.chat (for anyone coming to this issue) |
@timneutkens the url is https://propiedadesmussa-ujaidvjqfe.now.sh/ When entering, the first charge always takes up to 1 minute. I re-enter after being inactive for a few hours and the aforementioned is repeated. |
@robertoaikode that's because by default instances freeze. You can read about scaling your app here: https://zeit.co/docs/other/faq#why-does-my-deployment-occasionally-have-long-response-times |
I'm also experimenting very high latency in Firebase Storage files: |
That's unrelated to Next.js. I'm going to close this issue since we introduced https://zeit.co/blog/now-2 |
I've created a basic "Hello world example, however when deploying in production mode I am getting slow loading speed, which is mostly accumulated by slow TTFB.
I'm deploying to zeit.co Premium plan.
Repository for reproduction - https://github.com/driglou/satv
The text was updated successfully, but these errors were encountered: