Very slow posts loading from Wordpress rest api - PROBLEM WITH getServerSideProps()

[Thoonx]

I'm learning Next.js and can't resolve a problem with slow page loading in production with pagination.

For some reason page loads for minimum of 2 seconds for only 2 posts that are called from wordpress REST API with low res image and title. App is full basic just for learning with no extra libreries.

Here is the demo page that I deployed on Vercel:

Try clicking the NEXT BUTTON to see slow performance
https://nextwp-rdm3z16jm.vercel.app/posts/test

and here is my repo for this component:
https://github.com/Thoonx/nextwp/tree/master/pages/planet // check out test.js

Does anybody know what am I doing wrong?

Is there a better way to create pagination, maybe somehow with getStaticProps?

Thanks!

[alanqchen]

I would consider testing how fast the request times are with the WordPress API. If they take a long time to resolve, it may be a factor in why it takes so long to build.

Nevertheless, with getServerSideProps, the page is rebuilt on every request, which means that the client will have to wait for the server to build and then serve the page.

I would instead consider getStaticProps with the invalidate property to take advantage of incremental static regeneration since it doesn't appear that the user needs to see the most up-to-date list constantly. The user will receive a previously built page while a new version is generated in the background to be served on the next request when done.

[mattcarlotta]

Looking at some metrics...

Tests

3 requests (not including JS assets) when a test page is loaded: 1 to retrieve page HTML and 2 to retrieve data from API.

Request 1

Request URL: https://nextwp-rdm3z16jm.vercel.app/_next/data/qVRdrN3Ql3YM6oJHfE5xp/posts/test.json?page=2
Request Method: GET
Status Code: 200 
Remote Address: 76.76.21.21:443
Referrer Policy: no-referrer-when-downgrade

Request 2, direct request/response times ~400ms-800ms

access-control-allow-headers →Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type
access-control-expose-headers →X-WP-Total, X-WP-TotalPages, Link
allow →GET
content-encoding →gzip
content-length →1326
content-type →application/json; charset=UTF-8
date →Mon, 07 Sep 2020 04:09:36 GMT
link →<https://antuncrnja.com/w/wp-json/wp/v2/posts?per_page=2&page=2&?_fields=id%2Ctitle%2Ccontent%2Cacf%2Cfeatured_media%2Cbetter_featured_image>; rel="next"
server →Apache
status →200
vary →Origin,Accept-Encoding,User-Agent
x-content-type-options →nosniff
x-powered-by →PHP/7.4.9
x-robots-tag →noindex
x-wp-total →7
x-wp-totalpages →4

Request 3, direct request/response times ~400ms-1000ms

access-control-allow-headers →Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type
access-control-expose-headers →X-WP-Total, X-WP-TotalPages, Link
allow →GET
content-encoding →gzip
content-length →50
content-type →application/json; charset=UTF-8
date →Mon, 07 Sep 2020 04:08:25 GMT
link →<https://antuncrnja.com/w/wp-json/>; rel="https://api.w.org/"
server →Apache
status →200
vary →Origin,Accept-Encoding,User-Agent
x-content-type-options →nosniff
x-powered-by →PHP/7.4.9
x-robots-tag →noindex
x-wp-total →7
x-wp-totalpages →1

Total API response times: 800ms - 1800ms
Plus the cost of using gSSP (page is render blocked until data is requested/retrieved + data is rendered into document before being sent to client).

Average times for ~3 page requests...
Screenshot
p1: 1527ms
p2: 1537ms
p3: 1543ms
p4: 1530ms

Conclusions

Alanqchen pretty mentioned the issue: There are some major slowdowns in your API endpoint response times. My guess is that your API doesn't cache requests/responses, so it treats each incoming request as unique. As a result, the data that is retrieved has to be read from the source -- either from a file or from a database. This could be one factor in slowing response times. Another factor is that the average ping times to antuncrnja.com are around 150ms, which is pretty slow when compared to this random selection: google, vercel, target, stackoverflow, npmjs, codesandbox and github (all ~20ms or less, except github's ~70ms response times).

I'd recommend using getStaticProps (gSP) over getServerSideProps (gSSP) if the data doesn't change as much... or alternatively, you could use client-side requests with skeletons, which shouldn't render the block the page and improve the UX. In addition, if you could move the API end-point to the same domain as the application then this will improve latency (utilizing Next's API routes). On the same note, your use of API routes is incorrect; any pages in the api directory should be RESTful instead of a storage file for constants.

TLDR: Your API responses are very slow. The domain response is slow and the API endpoint is even slower. Either move the API within your project and/or utilize some sort of data (with filters) caching.