Page timing out for relatively simple page

I have a page that is quite simple; it has some MUI and ANT components, but the content is largely just HTML and CSS. Even still, I get a Timeout error, saying the page reached 10 seconds. I have 1 big image, but when I’ve removed it, the error persists.

My most recent attempts to fix the issue included loading some components asynchronously, but if you check earlier deploys ( [Production] main@[366321e]) you will see that my code was initially just a large block of HTML and CSS, with very few actual components.

This is my site’s link.
and the error is happening on the Education tab

hi @williamconvertino

Welcome to our forums! I’m able to open up the site now, did you change anything?


scratch that! I just noticed the error happening now. What are you doing on that particular path? can you please share some code implementation?

This is a link to the page itself

It essentially just sets the background image and header.

The main content is controlled by this component:

The asynchronous calls were just an attempt to have the main page load within the time limit, but, if I understand correctly, these calls are actually included by the limit.

The two cards themselves are essentially just instances of this component:

This is essentially just an ANTD collapse with an image. I hardcoded in a change in width for certain screen sizes, a hotfix for the formatting looking strange on mobile.

It might be worth noting that the useWindowDimensions hook is taken from here:

Hi, @williamconvertino. This appears to be a path using the server-side rendering (SRR) feature of Next.js. Paths that are using SSR (as opposed to incremental static regeneration aka ISR) will be handled by this function:

You can find the logging of that function on that page above (if you are logged in - no one else outside of you or our support team can see those logs).

I tried loading the page and it didn’t complete within 10 seconds. When this happens our CDN forces the connection to end and sends a 502 response to the client browser. However, the logging for the function invocation didn’t show anything interesting (other than the timeout itself):

Feb 7, 07:06:00 PM: e85dcb5b 2023-02-08T03:06:10.894Z e85dcb5b-0483-497d-82a4-55780003db37 Task timed out after 10.02 seconds
Feb 7, 07:06:10 PM: e85dcb5b Duration: 10016.68 ms	Memory Usage: 278 MB	Init Duration: 165.48 ms	

Now, our support team can increase that timeout to a maximum of 26 seconds. However, your site visitors probably don’t want to wait 26 seconds for a page to load so debugging the function to find out why it is slow is recommended.

To debug this, we recommend adding console.log() and console.time() statements to the code responsible for this path to find out where the function is spending most of its time. Once that is known, you can then work on refactoring the slow parts.

Is the result of that pageload cacheable and reusable? If so, you might consider turning this into a incremental static regeneration (ISR) page.

ISR pages still have a function run to create the HTML, but then they cache the result so the function is only run once. The function won’t be run again unless a new deploy occurs or until the revalidation time-to-live (TTL) value is reached (whichever happens first). The revalidation TTL has a minimum of 60 seconds.

So, if you know a page won’t change often, you can set the TTL to a value like 1800 seconds which will cause the page to be rebuilt each half-hour or when a new deploy occurs. The function runs might still be slow but that would be limited to once per 30 minutes. The rest of the time the cached version will be used and load much more quickly.

Finally, if the page can cache for the length of the entire deploy, you might just make this a static page so no code is ever run again outside of the build. Static pages will almost always out perform any SSR or ISR pages in terms of the time it takes to load the URL.

As you can see, there are options about how to resolve this:

  • continue using SSR and debug/refactor to make the code faster
  • switch to ISR and accept that when the page needs rebuilding that first rebuild might be slow (or you could refactor it to be fast and still use ISR)
  • switch to SSG (static-site generation) for this page - that is faster to load but the page can only be updated with a new build and deploy

Which is best is up to you to decide. However, if you want to discuss any of those solutions above in more detail, please reply anytime.

My page is a simple blog, so it sounds like SSG should be fine. My website uses a template, so I didn’t set up any of the rendering code. How would I switch it to SSG?

Hey @williamconvertino,

Please refer to: Basic Features: Pages | Next.js