Slow page routing during development.

Dear Maintainers, I recently began using this repo for a project of mine. I tested the production builds at first. The pages were 👌 blazingly fast with the Wordpress setup. So I began to work on development mode and that’s where I encountered very slow routing of around 4-6 seconds in average and even in incognito.

Filtered Network Tab showing time taken to get the json file for the page from wordpress.

Network Tab showing all the requests.

Here’s what I did.

1. Installed Wordpress using Local App from WpEngine and setup a test site Foobar.
2. Installed WpGraphQL plugin.
3. Installed WP Lorem Ipsum plugin which helped me to generate dummy pages(10) and dummy blog posts(10).
4. I then forked this starter repo and then cloned it using git clone
5. Install packages using yarn
6. Set the graphql endpoint in env.local as WORDPRESS_GRAPHQL_ENDPOINT="http://foobar.local/graphql"
7. I then tested the production build first using yarn build && yarn start which worked like a charm.
8. Then I thought of playing around in the development. I ran yarn dev and that’s where I found that all the pages load very slowly. They are even slower than the actual Wordpress site as well so I thought there must be something going on.

Here’s my console logs.

& Here’s my repo. https://github.com/Keshavdulal/next-wordpress-starter

From my guess/research so far it’s something to do with Fast Refresh and HMR maybe but I am not sure so I thought of reaching you guys here. I am fairly new to WordPress & NextJS but seasoned in React. Let me know If I am missing something during setup. Any insights are welcomed. 🙌

[Keshavdulal]

Pardon me coming back at this after so long. Here’s an update incase anyone comes across this.

This is an issue with the nextjs framework itself.

Here’s an ongoing discussion on Github Issues

This slow routing issue has nothing much to do with this or any starter for that matter. I tried making one from scratch but faced the same issue.

My Use Case/Context

I was making some network requests (for global data such as header/footer navigation items) in a getInitialProps method at _app.js so that those data can be reused across all the pages. But not so fast.

According to Nextjs Docs as of writing this says: (May be this will change in future)

- Adding a custom getInitialProps in your App will disable Automatic Static Optimization in pages without Static Generation.
- App currently does not support Next.js Data Fetching methods like getStaticProps or getServerSideProps.

So, How I solved it?

• I used file-based local data caching mechanism to speed up the slow-routing.
• An article on the Caching Solution by Flavio Copes

Here’s a speed comparison after applying the solution. Left - After Caching Right - Before Caching

There are other solutions discussed in the github discussion too but the above one worked in my case. So hope this helps.

[colbyfayock]

yeah @doingandlearning @GuilleAngulo and I were chatting about it a bit in my discord https://spacejelly.dev/discord

so a little context, we’re currently using getInitialProps in a custom _app.js to grab globally available data as there really isn’t any type of global data layer mechanism to do that right now, beyond adding those requests on each page in something like getStaticProps, and i guess setting up a new context or pass those as props each time, which feels like the wrong way to handle it

part of the downside is this is typically discouraged, as it automatically disables some optimizations. the reason we’re thinking it’s okay here is because the app ends up being statically compiled anyways, so this is at no cost to the user

now i haven’t run any tests to confirm this but i believe that to be the reason why it’s slow page to page, because that ends up making all of those requests every time a new page loads, and there are a few in there to get all the relevant WP data

i think a big thing that currently isn’t working properly (or might just not be set up) is a caching mechanism for those requests. each time the apollo client is being used, it seems to be creating a new instance, which im guessing means it’s also not doing any sort of caching

that wasn’t the intent but it didnt seem to work as expected

@GuilleAngulo said he’s going to poke at it a bit and see if he can figure anything out. im not a graphql expert but trying to also do a little digging around to see if i can find anything that make ssense as to how to properly set up apollo to take advantage of caching

this article for instances sets up the client a little differently, could help: https://www.apollographql.com/blog/getting-started-with-apollo-client-in-next-js/

More info from their docs: https://www.apollographql.com/docs/react/caching/cache-configuration/

if we can’t seem to figure something out i can reach out to people over there and see if they have any recs