Headless static website
Here's my typical technical setup for small and medium sized websites: Back-end: Headless CMS, usually Prismic or Storyblok. PHP on the server to generate the website. Front-end: Static website (html,css and javascript). No need for advanced routing or server setup (same hosting and server as Wordpress, Drupal etc. can be used). Various frameworks and libraries when relevant (GSAP, Three.js etc .) When a CMS editor publishes new content from the CMS, a webhook is calling a script on our server. This script loads all data from the CMS and generates static files on the server. The process is usually very fast (less than 2 seconds), in opposition to many popular frameworks I have tested. Editors can preview/view updated content easily and have a fast and friction-less editing experience. The benefits from a setup like the above are primarily: Great editing experience in the CMS. Very fast website (nothing is loaded from databases). Great SEO (nothing relies on javascript interpretation). If the website is ranking high, then updates are usually visible within a couple of hours! Great Lighthouse score. This helps both SEO and accessibility. When using Prismic, we have all images in the imgix CDN. This means fast load times globally. Headless means a separation of the back-end (handling all your data and assets) and the presentation layer (what your website visitors see). This makes it easy to work independently in either, but also avoids situations in which a content editor is designing in the CMS. Downsides to a headless setup: Very large websites can experience longer build times. The modules and content in the CMS doesn't look designed (but very few CMS actually offers this anyway). Some services can be hard to integrate (Shopify, Hubspot etc. are all possible, but not as easy or deeply integrated as I sometimes would like). You don't host your own data. For many companies this is actually good, because you have back-ups and don't have to worry about servers and databases. But for some larger companies, hosting and storing all data is important. Please have a look at my freelance front-end developer portfolio if you are interested in more.

Here's my typical technical setup for small and medium sized websites:
Back-end:
Headless CMS, usually Prismic or Storyblok.
PHP on the server to generate the website.
Front-end:
Static website (html,css and javascript).
No need for advanced routing or server setup (same hosting and server as Wordpress, Drupal etc. can be used).
Various frameworks and libraries when relevant (GSAP, Three.js etc .)
When a CMS editor publishes new content from the CMS, a webhook is calling a script on our server. This script loads all data from the CMS and generates static files on the server. The process is usually very fast (less than 2 seconds), in opposition to many popular frameworks I have tested. Editors can preview/view updated content easily and have a fast and friction-less editing experience.
The benefits from a setup like the above are primarily:
- Great editing experience in the CMS.
- Very fast website (nothing is loaded from databases).
- Great SEO (nothing relies on javascript interpretation). If the website is ranking high, then updates are usually visible within a couple of hours!
- Great Lighthouse score. This helps both SEO and accessibility.
- When using Prismic, we have all images in the imgix CDN. This means fast load times globally.
- Headless means a separation of the back-end (handling all your data and assets) and the presentation layer (what your website visitors see). This makes it easy to work independently in either, but also avoids situations in which a content editor is designing in the CMS.
Downsides to a headless setup:
- Very large websites can experience longer build times.
- The modules and content in the CMS doesn't look designed (but very few CMS actually offers this anyway).
- Some services can be hard to integrate (Shopify, Hubspot etc. are all possible, but not as easy or deeply integrated as I sometimes would like).
- You don't host your own data. For many companies this is actually good, because you have back-ups and don't have to worry about servers and databases. But for some larger companies, hosting and storing all data is important.
Please have a look at my freelance front-end developer portfolio if you are interested in more.