Staticify your site for Performance – Part 1

Being able to serve the most users out of your shared hosting/vps is one of the most crucial component as you scale in users. For most wordpress sites (like mine), contents are mostly static without a lot of features that warrant the use of the server side framework.

Converting the site to be static html will bring a lot of changes that will open your eyes.

Static HTML sites

The good

  • Performance

Converting the site to be plain html pages will help the loading times, and request/second a big margin compared to using PHP (for wordpress sites)

  • Security

WordPress sites power more than half of the whole internet. That makes it a lucrative target for hackers to pick on. Running any server sided application exposes you to a lot of security vulnerabilities that may hit your site sooner or later. Changing the site to only serve html greatly limits the scope of attack that hackers can do.

The bad

May not fit your usecase

If your wordpress site is a dynamic page, i.e e-commerce site then having a static site wouldn’t fit your case. Having some dynamic forms would pose an issue too. However, some hybrid solutions can be implemented to serve for both cases (html for static contents, php for dynamic contents)


Setting up a static site requires maintenance and due diligence as the static site may break due to unforeseen reasons. However, this also encourages you to have another environment to test out your changes before deploying it to live which is what a moderate site should have before each change (new post, new plugin, etc).


Before we dive in into using static sites, some changes are needed to be done to prepare your site to support static html. I’ve listed some common stuffs that will require change, but do comment if you need help some other changes not listed here


Custom Google Search can be used to replace the default search bar without much changes.

Comment Form

Disqus can be used to replace the comment form, which is typically better than doing your own comment section with akismet.

Contact Form

To be done in Part 2

Tested Static Site Generators

wp2static v6 – Not the latest version but I believe the same issue occurs in the newer versions

The good

Ease of Use

Being a plugin in wordpress itself, configuring the plugin and generating the static website is pretty easy and intuitive

Multiple deployment options

From local deployment to Cloudflare workers, Netlify, BunnyCDN and more, having multiple deployment options makes life easier for technical and non-technical people to deploy their static sites to the internet

The bad

Weird Bugs

From my past experience in using it, it simply dies or still requires changes for the static site generated. From what I’ve read, v7 fixes it but it is still not stable yet so I’m refraining myself from using it for production use.

Requires maintenance

Like any other static site generators, sometimes it may generate some weird behaviour and requires some maintenance every now and then


The good

Less erratic behaviour

The command below generates the static site without much of a fuss

wget \
--recursive \
--no-clobber \
--page-requisites \
--html-extension \
--convert-links \
--restrict-file-names=windows \
--domains \
--no-parent \;

The bad

No Shared hosting support

wget is not supported in shared hosting so it may not be an option for shared hosting users

Requires Maintenance

Like any other static site generators, sometimes it may generate some weird behaviour and requires some maintenance every now and then

Deployment options limited

Compared to wp2static, deploying to other platforms require manual deployment which may take more time/put some people off into using it


For now, due to the erratic behaviour of wp2static, wget is my go-to selection for now and more to be covered on Part 2 as I continue using as a static site