Hi, we have published the site alison-sant.netlify.app recently and connected it to the (on godaddy hosted) domain alisonsant.com (with the A-Record option).
The site itself is a headless nuxt (latest v3) build relying on an externally hosted cms with simple API calls (useFetch calls that work with server-side rendering).
the site config has been optimised to use all features of netlify/nitro, meaning that the preset “netlify_edge” is activated as well as “ssr: true” and “prefetch: true” so it is building a very well compiled final version.
sadly when accessing the site on netlify (no matter which domain, either the internal netlify.app one or the custom godaddy one) it has a very long first rendering time (up to 10 seconds depending on the site url and page) during which the site is just staying blank.
I’m writing this post to find out if this could have to do with anything domain related (moving the domain completely to netlify is not an option as other things like MX records are being used actively on godaddy) or if it is rather an issue in the app published (maybe cause the API calls are sending too large json files and data which makes it slow on first rendering, even though it all should happen server-side with ssr and nitro active?).
thanks, N.
The page itself loads very fast:
r
Your page seems to require too many assets before it can produce menaingful content on the screen. This sounds like an issue with incorrect design/optimization decisions than Netlify.
thanks for checking on your end @hrishikesh ! maybe I wasn’t specific enough, as I see the home page seems to load quite fast most of the time, but any sub-page has very long waiting times for the server response, see attached for the url https://alisonsant.com/topics/mobility (13.3s).
now I know that the site loads a lot of image data (all implemented with lazy sources in the frontend) and am just wondering whether something could be going wrong on the server-side parts (either dns-related, or that the usually very fast server-side caching/passing-on of data through the netlify _edge features is not working as intended maybe.
Can you confirm the issue is not related to your API being slow to respond? As you mentioned, the data is being fetched via API, so if the API takes a long time to send data, the page would be slow as well. Have you tried adding console.time() statements in your code to debug that?
@hrishikesh I will try debugging with the console.time() command thanks! maybe it could also be a more profound misunderstanding on my end, as I’ve thought that when using nuxt 3 in combination with prefetch:true, the api-calls using useFetch or useAsyncData would not actually be fetched on each visit of the website, but rather only during the build-process and then the API/json data would be ready on each visit – if that’s not how it actually works or if that’s impossible with nuxt3/netlify_edge, that would explain that subpages with bigger API/json-data take much longer as I’ve not taken into account realtime API fetching in the architecture of the backend site data.
this is the nuxt3/nitro prerendering docs I’m referring to: Prerendering · Get Started with Nuxt – which should if I understand correctly not call the actual API on each load of the website via domain, but rather call the API once at build-time and then later on just inject the payload from the server on netlify, which should probably not result in 12 seconds loading times?
the following are details from my nuxt config:
nitro: {
prerender: {
ignore: ['/entry/preview'],
crawlLinks: true,
routes: ['/', '/**', '/topics/**', '/types/**'],
},
preset: 'netlify_edge',
},
prefetch: true,
ssr: true,
routeRules: {
'/': { static: true },
'/**': { static: true },
'/topics/**': { static: true },
'/types/**': { static: true },
},
and inside the nuxt frontend code for the category pages (that are loading so slow) only the following external API call is being made in the setup function and should be prerendered instead of being fetched on demand and blocking the page on server side:
const { data: topic } = await useFetch(`https://backend-domain.com/api/topics/${route.params.id}`);
When you use netlify_edge preset, I don’t think any of that is respected. Nuxt does not deploy an Edge Function per route, or does not exclude the Edge Function from the prerendered paths. It consumes 100% of the requests.
So I think, even if you try to prerender it, the edge preset is preventing you from being able to use it. We have some changes for Nuxt 4: Netlify’s Platform Primitives is Easier Than Ever with Nuxt 4, which says:
Known static paths will now return a 404 immediately without invoking a function, but that page also says:
If you’ve opted in to the netlify-edge preset, none of the above has changed.
Given that the disclaimer points to the text above the line, so it might not apply to it, however these are the hanges for Nuxt 4. For Nuxt 3, the Edge Function does consume every request.
You can try adidng some console.log() statements in your page’s logic. If these statements appear in your Edge Function log, it’s definitely being rendered on the server.
1 Like
oh I see I have completely misunderstood the netlify_edge preset! after switching back to a simplified config with no preset (I guess by not setting one manually nitro automatically selects the default netlify preset instead of edge) the routes that have been manually set in the prerender options are loading super fast.
nitro: {
prerender: {
ignore: ['/entry/preview'],
routes: ['/', '/**', '/topics/**', '/types/**', '/topics/mobility'],
},
},
ssr: true,
one other issue, that the dynamic routes i.e. /topics/... are not loading fast yet has nothing to do with the above settings I guess, but rather that I am using dynamic route names (meaning I have a structure like /pages/topics/[...id].vue which does not seem to work with the prerender of just /topics/** but rather needs to either have route crawling activated or then using the nitro life-cycle hook as described in Nuxt 3 Hybrid Rendering: Pre-Render Dynamic Routes (SSG) – I’ll give this a go, but your answers helped so much pinning down this issue thanks @hrishikesh !
