Slow initial load times with Next.js SSR #5361
Replies: 0 comments 9 replies
-
|
Where is your Algolia server vs the server that's hosting the search? Could it be that they're physically far apart? |
Beta Was this translation helpful? Give feedback.
-
|
Sure! The repo for the site is private, but tomorrow I'll see if I can throw up a public repo with the relevant code. In the meantime, this is the page: https://where-next-frontend-preview.vercel.app/experiences Honestly, as a human, it's feeling reasonably fast to me--especially after first load--but speed-testing tools really don't like it. Though actually today we somehow managed to score 2.5 seconds and 9 seconds for LCP running separate tests on the same page, so it's starting to feel more like more of an environment issue than a code issue, since these components presumably run the same way every time. Oh, and I feel like I have to mention that I'm maybe the 4th developer to work on this site--I'm very aware of how messy things have gotten under the hood :D |
Beta Was this translation helpful? Give feedback.
-
|
Looking forward to getting some sandbox reproduction, because seeing the network panel, the implementation doesn't look optimal. Even though you mentioned the app was SSRed, there are 3 network requests sent to Algolia on the initial load. |
Beta Was this translation helpful? Give feedback.
-
|
Well, this is embarassing! In the process of extracting all the necessary components for a sandbox environment, I found a gap in the prop drilling. After fixing the gap, the page load as a human tester is waaaaay better! Even on throttled connections it's coming through pretty reasonably. Speed tests are still sort of all over the place, but I inherited (and have occasionally created, case in point) a bit of a mess with this site so I think I need to do a general clean-up before doing more Algolia optimizations. Sorry, really feel like I should have caught that typo earlier for as many times as I've been over these files! Thanks for taking the time to help--it's my first time on the Algolia/InstantSearch stack and I've been loving it so far. |
Beta Was this translation helpful? Give feedback.
-
|
Glad you have a much more performant site now, it makes me think we could have a warning if the server side rendering provider is used, but no results were passed |
Beta Was this translation helpful? Give feedback.
-
|
Could certainly end up helping people lacking in typo-catching skills and potentially other situations as well! |
Beta Was this translation helpful? Give feedback.
-
I've got a Next.js app hosted on Vercel, mostly using static site generation (SSG), but we went with SSR for the one page that's currently using Algolia to display an initial product list and search the list. We'd initially been using CSR, but speed tests were coming upt pretty abysmal and CSR isn't the most SEO-friendly. Switching to SSR (using react-instantsearch-hooks) bumped up the speed quite a bit, but we're still seeing 5+ second initial load times, which obviously isn't ideal.
The implementation is pretty much in line with the Next.js section of the Algolia SSR docs.
The site is preconnecting, I've pared down the Algolia response to only the properties we're using on the frontend, components are being imported dynamically, the cache control headers are set up--and we're still getting long load times. Is there something obvious I'm missing? I'm fairly new to Algolia, so very possible there's a trick I'm not savvy to.
I'm thinking of trying SWR or getting creative, like using ISR to regularly update a static non-Algolia page of data and then replacing it with the Algolia components when they're ready, but obviously would prefer to stick with the SSR solution Algolia provides out of the box.
Beta Was this translation helpful? Give feedback.
All reactions