0

I have to build a website that features:

  • 10.000 views/month
  • 5-6 content post types
  • 100-200 entries
  • many images
  • the client will add/update/handle entries like 1 time a week

Until here I used Wordpress with custom theme but now I was thinking to build it with an headless CMS (Wordpress, Prismic, ...) + separated front end (Next.js).

Given the above website informations I think I need SSR for all pages (can't use static site generation because of the frequently entries updates, correct?), so my question is: it makes sense to develop a website like that in this way (headless cms+Next.js)? That is, for a site like that, does it have more advantages (in performance) than a pure Wordpress?

Fred K
  • 13,249
  • 14
  • 78
  • 103

2 Answers2

2

If you want performance you can use static site generation for your case. The frecuency of 1 change per week is low frecuency. You can add to prismic io, or to any headless cms, a web hook to trigger the static generation each time the post change.

You can see how the webhooks work in prismic and it able to use SSG in your use case and give all the performance you need: https://user-guides.prismic.io/en/articles/790505-webhooks

The special point in the performance, that can make a great diference is the use of images and media. Worpress do not optimice the images well. In a headless case you can use procesa optimicer image api like imgx (prismic has media integration with imgx https://prismic.io/blog/prismic-image-optimization-imgix). That service and the Image component from next js https://nextjs.org/docs/api-reference/next/image. give to me the performance close to 100 in google light house in all my sites. The media is not the only thing in performance but can have the 70% of the size of the site, so you should look the size of the images if you are looking for performance.

Finally if you use headless architecture, eventualy if you see a better performance tecnology you can change next js for another one. But at the moment it is a good choose.

Pablopvsky
  • 209
  • 2
  • 5
  • I understand that SSR is slower than SSG, but SSR is slower than a "classic" website (PHP etc)? I mean, building a Next.Js based website + SSR is so slow? It isn't already a big improvement? – Fred K Apr 06 '21 at 15:00
  • Yes, Next Js + SSR is already a big improvement and is a good choose too. I highly recommend it. Next Js + ssr + wordpress or any headless cms. – Pablopvsky Apr 06 '21 at 23:33
  • Well, so in comparison, CMS headless+Next.JS+**SSG** compared to CMS headless+Next.JS+**SSR** is just a little performance improvement? – Fred K Apr 10 '21 at 10:03
  • Yes. We can cofirm that the diferense can be milliseconds, assuming the api is fast. Headless+Nest.js+SSG will have a paint in 0.3s 0.6s, Headless+Nest.js+SSR will have a paint in 0.9s . It is to give an example. It should be clarified that there are many variables that can affect performance, but let's assume they are the same. – Pablopvsky Apr 10 '21 at 11:51
1

I did a research on this subject recently. Here are some points :

With headless e-commerce, the UI is separate from the backend. Developers will have full control over what is printed on the screen. They can create brand-specific user experiences. The ability to customize is not limited. The downside of the problem is the cost of developing the frontend, as it is no longer provided.

Using headless e-commerce allows you to separate the CMS from the e-commerce engine part. Because we use the API. This allows the marketing team to use their favorite CMS tool, and at the same time, you can use the engine with the most features. However, you cannot use WYSIWYG in CMS, preview, or quickly update the content, because the frontend is independent.

The division between the back end and the frontend is a good design, in terms of the system. I think of a situation where you can have several different shops, with some UI changes (color code, logo) sharing product categories.

Speaking of performance, for headless systems to have a good performance, the API needs a quick response time. I researched the WooCommerce REST API and I found it not to be fast. I usually had about 1000 ms responding time for a request. However, I also saw a few articles to improve this.

Reference :

Đăng Khoa Đinh
  • 5,038
  • 3
  • 15
  • 33