<p>There are a few different solutions for this. Personally my favourite is to switch on static caching in nginx, as it's a relatively quick and easy solution. Andrew has you covered on how to do that here: <a href="https://nystudio107.com/blog/static-caching-with-craft-cms" rel="nofollow noreferrer">https://nystudio107.com/blog/static-caching-with-craft-cms</a></p>
<p>If you're not using nginx, then a popular choice is the Blitz plugin: <a href="https://plugins.craftcms.com/blitz" rel="nofollow noreferrer">https://plugins.craftcms.com/blitz</a> (I've not used it myself so can't really comment, but it sounds good if you're not into rolling your own solution in nginx). Blitz offers a static export of your site too, so it's literally just html files, which would be more portable than nginx's static cache (i.e., you could host the site directly on a CDN).</p>
<p>With any kind of static system, you'll need to ensure:</p>
<ol>
<li><p>That any form submissions such as keyword search and contact forms still work by dynamically refreshing any CSRF tokens via AJAX.</p>
</li>
<li><p>That the relevant actions in Craft cause the cache to be deleted. Again, Andrew has you covered here if you're using nginx static caching with the FastCGI Cache Bust plugin: <a href="https://github.com/nystudio107/craft-fastcgicachebust" rel="nofollow noreferrer">https://github.com/nystudio107/craft-fastcgicachebust</a></p>
</li>
</ol>
<p>Overall I prefer nginx static caching because I still have the dynamic benefits of a CMS and don't have to worry about complicated workflows for updating an entire load of files and redeploying them somewhere whenever someone corrects a spelling mistake... but I guess if you can fully automate that it's a fine solution.</p>

CC BY-SA 4.0
2020-11-26T18:44:39.680Z
Thanks James, this is very helpful!
Andy Lake
CC BY-SA 4.0
2020-11-26T14:57:20.773Z
2020-12-01T16:29:59.427Z
2020-12-01T16:29:59.427Z
James Smith
<p>Has anyone tried creating a process whereby the pages/entries generated from Craft could be presented as static HTML?</p>
<p>I am keen to know what different approaches have been taken in the past as we are considering it for a company website.</p>

<entries>
Rendering pages from Craft CMS as static HTML
# Rendering pages from Craft CMS as static HTML

(Asked by: username_0 on 2020-11-26)

Has anyone tried creating a process whereby the pages/entries generated from Craft could be presented as static HTML?

I am keen to know what different approaches have been taken in the past as we are considering it for a company website.

**Tags:** entries

---

## 1 answers

### Answer by username_1 on 2020-11-26. Score: 5 | Accepted answer

There are a few different solutions for this. Personally my favourite is to switch on static caching in nginx, as it's a relatively quick and easy solution. Andrew has you covered on how to do that here: <https://nystudio107.com/blog/static-caching-with-craft-cms>

If you're not using nginx, then a popular choice is the Blitz plugin: <https://plugins.craftcms.com/blitz> (I've not used it myself so can't really comment, but it sounds good if you're not into rolling your own solution in nginx). Blitz offers a static export of your site too, so it's literally just html files, which would be more portable than nginx's static cache (i.e., you could host the site directly on a CDN).

With any kind of static system, you'll need to ensure:

1. That any form submissions such as keyword search and contact forms still work by dynamically refreshing any CSRF tokens via AJAX.
2. That the relevant actions in Craft cause the cache to be deleted. Again, Andrew has you covered here if you're using nginx static caching with the FastCGI Cache Bust plugin: <https://github.com/nystudio107/craft-fastcgicachebust>

Overall I prefer nginx static caching because I still have the dynamic benefits of a CMS and don't have to worry about complicated workflows for updating an entire load of files and redeploying them somewhere whenever someone corrects a spelling mistake... but I guess if you can fully automate that it's a fine solution.

> **Comments:**
> **username_0**: Thanks James, this is very helpful!  

---

