I know some of you might be thinking … Why would you even want a static html website with all the free CMS systems out there now?
I believe there are still situations where static html would be a better choice than a php database driven website.
For instance if you have a small website that doesn’t consist of a lot of pages, and your pages do not change or get updated very often.
I know many people that use a CMS system and they rarely login to the administration dashboard. They get busy, forget, or maybe don’t even remember how to after awhile, which can open the door to a potential exploit if they don’t keep their system, plugins, themes, etc. updated.
A static html website will almost always consume less server resources when compared to a php database driven CMS website like WordPress with equal or similar traffic. The only way it wouldn’t is if it were using a bunch of script files that were doing something very unusual or out of the ordinary.
It takes CPU power and memory for php to load up, connect to and query the database, and to turn it into html that your web browser can understand. Not to mention if you are using plugins some of them do tend to be more resource intense than others.
Even if you happen to be using a cache plugin it’s not cached forever. Most plugins remove cached files after a specific time. So, they get created, removed, created again, removed again, and so on. Which also takes CPU power and memory to do. If you have a small website do you really need to do this several times per day?
Recently I worked on a static html site consisting of 13 pages. It was an older website that has been around for nearly 12 years. It was not optimized, or mobile friendly.
1. Make it mobile friendly.
2. Create a more modern design.
3. Optimize it for faster loading.
To make it mobile friendly I used a nice html5 template that I tweaked, and added a few extra features.
The create a more modern design was partly the new tweaked template along with new images.
The optimizing part consisted of several enhancements including:
Proper (actual) image size
Compressing .css, .js, and .html files
I also added expires and cache-control headers in .htaccess (aka browser cache).
Rather than let the server compress files on the fly, which does use CPU power and memory I chose to manually create them (static), and configure .htaccess to serve them.
For example, along with combining 7 .js script files into 1 I also compressed it with gzip. What I end up with is combine.js and combine.js.gz.
Almost all modern day browsers are capable or handling compressed files, but if the visitor happens to be using one that doesn’t they would get the uncompressed regular .js file instead.
In this case the uncompressed combine.js file is 111 KB, and the compressed .js.gz version is only 38k. So not only are 7 files combined into 1, which saves 6 requests the compressed version is also 73KB smaller.
There is only 1 .css file being used so I didn’t need to combine it, but it can be minified and then compressed. Similar to the .js the uncompressed minified .css file is 22KB, and the compressed .css.gz is 4KB. So there is another 18KB of savings.
The .html files I did not minify because I sometimes go back and make changes to these files, and it’s much easier to find what I’m looking for in an unminified version. Plus it doesn’t save that much anyway.
I did compress the .html files into .html.gz files though. Size and savings vary depending on each .html page. Index.html for example is 12.86KB uncompressed, and only 3.51KB compressed. So that’s about 9KB in savings.
Now by doing this for .js, .css, and .html a single index.html (homepage) load will save around 86KB if the users browser supports compression (most do). And, since these files have been created manually and physically exist on the server they will be used instead of on the fly compression if .htaccess is properly configured, which won’t use additional CPU power.
Since I also added expires and cache-control headers to .htaccess to tell the visitors browser to cache these files, any additional page views will load faster. They would only need to get images and .html/.html.gz files when visiting other pages.
This works well for smaller static .htm/.html based websites that don’t add, change, or edit content very often. If one were to make changes they would need to re-generate corresponding .gz files as well, which isn’t a big deal for small or minor edits.
After optimizing it scores A(95%) PageSpeed Score | B(85%) YSlow Score at GTmetrix. Page Load Time is just under 3 seconds. Less than 500KB Total Page Size, and 43 Requests.
The only reason it doesn’t score higher on YSlow is because it does have Google Adsense ads on it, and certain related things I have no optimizing control over.
For instance since they are on Google’s servers I can’t change them. The only way to score higher would be to remove them completely.
The page load time, total page size, and number of requests will change from one test to the next when there are Google Ads on the page. If I removed them this site would probably have a page load time in the 1-2 second range.
Incidentally, I have read articles about how WordPress cache plugins with .css/.jss minify enabled like W3 Total Cache made their site slower and the number of requests actually increased. The reason for this is the page/site that they were testing most likely had Google Ads, or some other advertising that changes each time the page is loaded. Many files could be loading the advertisement, and fewer the next. This isn’t an accurate way to test a plugin like W3 Total Cache.
You would need to remove advertisements from a test page/site that can change each time it loads. After you have removed them, test your page/site before installing a cache plugin, and again after installing one. When you are completely done testing put your ads back. This isn’t 100% accurate either because other things could be happening on your server, but it will be much more accurate than with ads that change each time the page loads.
WordPress and other CMS systems are great if you add, update, or edit content on a regular basis, but static html sites are still a good choice for smaller sites with infrequent updates or changes.