I have hesitated for a long time.
Until I finally decided to switch to a static website using Publii.
Here's the full story.
Spoiler: I won't switch back to WordPress (for my personal site).
Table of Contents
The importance of speed
On the internet, speed is crucial.
Firstly for the users because no one wants to wait even a few seconds for a web page to load. We've been accustomed to fast access by the market leaders (and, let's be fair, by the native apps UX).
Secondly for Google: speed is an important SEO factor. It's easy to test how Google sees your website with Pagespeed Insights.
The WordPress version of my personal site scored around 70 at best when optimized with a bunch of plugins.
This is due to the way WordPress is working, loading its huge core engine for each visitor + usually loading all plugins & scripts on every single page, even when not used (there are ways to deactivate scripts on a per page basis but it's a pain).
When you're using WordPress, your website is assembled on the fly for each visitor, which requires extra processing (which you can mitigate to some extent via caching plugins).
When you're opting for a static website, the readymade content is simply served to the visitor, as it is. To modify the content, you simply push a new version. Voilà !
Additional benefit: there's no need to maintain any underlying code (like updating themes & plugins on WP). Static websites can be published cheaply to a wide range of platforms (Netlify, GitHub, Amazon S3,...) and don't require any specific CMS. I could even modify the clean HTML of my Publii site without the Publii app and if, for some reason, Publii stops updating their desktop platform, I'll still be fine.
Even WP leaders have an average performance...
A company rightfully promoting the speed of its WordPress hosting services (Kinsta) scores 65/100 on Google Pagespeed Insights with their own site.
Another leading WordPress hosting company, FlyWheel, scores 68/100. And I could list a few other examples...
To be honest, I almost switched from Gandi to Flywheel when I was still hesitating to move from WordPress to a static site. Flywheel kindly offered me to clone my site (for free) to give it a go on their platform. Yes, it was faster than on Gandi (for a cost of $23 per month) but it wasn't anything mind blowing. I was still waiting for each page to load.
So I decided to invest time and efforts (you'll see in a moment it wasn't that easy) to switch from WordPress to a static site.
And here's the result of my latest test on Google Pagespeed Insights.
98/100. That's what I call a fast website!
I've been following the evolution of Publii for a while.
The editor is free to download from Getpublii.com.
To publish your website, you will need to choose a hosting service.
For a simple project, I would advise you to go the Netlify route. It's free and very easy to set up (just drag & drop an empty HTML file provided by Publii).
I had considered Netlify for this site but the publication process got stuck multiple times (my whole WordPress site was 1.3GB at time of transfer due to all the PNG screenshots I've been using in my posts).
Hosting a static website on Amazon S3
It's not plug & play, like a "one-click WordPress install".
I decided to explore the procedure to host a static website on Amazon S3 since I already had an account opened at Amazon for another project. You will find a detailed tutorial on Publii's website, so I won't repeat the full instructions here.
Just bear in mind that when you create a S3 bucket you should name it with the full custom domain name you'll be using in production. For instance, for this site, my Amazon S3 bucket is named www.callmefred.com
It's a requirement if you want to link the bucket to a CNAME in the DNS settings of your domain, e.g. linking www to www.callmefred.com. on Gandi, where my domain is registered (don't forget the dot after the bucket name when setting the CNAME at your registrar).
Since I had secured my domain via HTTPS at Gandi (which is a trust factor both for users and Google), I needed a SSL certificate for the new website hosted on Amazon.
To easily publish a HTTPS secured website via S3, you'll have to create a Cloudfront distribution, which has the additional effect to distribute your site via the Cloudfront CDN, for free, all around the world, speeding up access for your visitors on the other side of the globe.
You will find the full procedure to create a Cloudfront distribution on Amazon's website. It's pretty straightforward. Just remember that you'll need to create a PUBLIC ACCESS policy for your S3 bucket.
Before creating a Cloudfront distribution, generate a free SSL certificate via AWS Certificate manager (NOTE (July 2019): it used to be compulsory to create a bucket in US East / N.Virginia to automatically retrieve a AWS SSL Certificate but it's not the case anymore. I've tested the procedure successfully with buckets created in the EU Ireland & London). Good to know!
Here's the full procedure to follow on Amazon, step by step:
1° create a Amazon S3 bucket (named after the full custom domain you will use in production)
2° issue a free SSL certificate via AWS Certificate manager
3° create a Cloudfront distribution using the endpoint (without http://) of your static website location on Amazon S3 (not the bucket address).
It's the HTTP address / endpoint (not HTTPS) you will find in the properties of your bucket (simply follow the Publii instructions above to create the bucket and the user credentials you'll need on Publii).
When your Cloudfront distribution will be deployed, you'll be able to test the URL of the distribution (ending with cloudfront.net) in your browser.
If you have properly linked your S3 endpoint to Cloudfront, this should open the URL of your static website hosted on S3.
But you will probably notice that the CSS of the site won't be properly loaded since the site's resources aren't accessed via httpS but via http.
You will solve this issue at the end of the process by changing the access URL of your site in Publii, using your production custom domain URL preceded by HTTPS. Good to know: don't change the S3 endpoint URL into https since it won't open.
So this is how your SERVER settings will look at the very end (in production mode) on Publii.
Before that, when you'll publish your site to S3 for the first time, the domain will be preceded by HTTP using the endpoint of your site in the Amazon S3 bucket (ending in my case with s3-website-us-east-1.amazonaws.com).
You will keep it like that until you'll decide to connect the CLOUDFRONT DISTRIBUTION URL to your CUSTOM DOMAIN via your registrar's DNS settings, using a CNAME.
For this final step, don't forget to add the dot after cloudfront.net. if required by your registrar when configuring the CNAME.
At the end of the process, your custom domain will be secured by the SSL certificate issued by Amazon and used by Cloudfront (I hope you managed to follow).
How much does it cost?
You won't pay a fixed price to host your static site on Amazon S3 + Cloudfront. You will pay a small variable fee based on data storage and usage.
Here's what Amazon says about the cost of hosting a static website on their platform.
The total cost of hosting your static website on AWS will vary depending on your usage. Typically, it will cost $1-3/month if you are outside the AWS Free Tier limits. If you qualify for AWS Free Tier and are within the limits, hosting your static website will cost around $0.50/month. To see a breakdown of the services used and their associated costs, see Services Used and Costs.
So it can be free or anyway much cheaper than hosting a WordPress website on a shared server and you will never face scaling issues if your site becomes popular.
Note: I wish this procedure was much simpler for beginners. It would be so nice for instance to just press on SSL to enable HTTPS on a domain and click on HOST STATIC WEBSITE on S3's landing page to display the full credentials to use in a CMS like Publii. I don't really understand why the whole process is still so complicated.
Importing WordPress content to Publii
I was a bit sceptical about the possibility to automatically import my WordPress content into Publii but it was frictionless. The whole process is explained on Publii's website.
It will work seamlessly for all the blog posts created with the classic WP editor. It won't work for the content created with an advanced visual builder like Divi since you will get a bunch of useless shortcodes in the imported page.
So I had to recreate a few pages in Publii, like this one. There's no Wysiwyg front-end visual builder with sections and rows to design pages but there are a few tools to add info, warnings, success messages and flat buttons. It was more than enough for my personal use.
I also had to rewrite the SEO meta descriptions which were not imported from the WordPress Yoast SEO plugin data. And since I didn't have Featured Images in WordPress (I was using hidden images configured via Yoast for sharing purposes), I had to select and upload one featured image for each post (from Pexels and Unsplash).
Quite a bit of work since I had 76 published blog posts but it was a nice creative exercise. I also recaptioned a few photos and removed a WordPress form shortcode (newsletter signup) at the bottom of each post, which I replaced by a Typeform conversational widget (details below).
The first publication of my site to S3 took a while (almost 2 hours) due to the weight of the content. Later updates were faster even if the rendering process could still be improved by Publii (it's much faster for a site of 5 pages than for 80 posts...).
If you're creating POSTS which should be considered as evergreen info PAGES (which you don't want to see in the feed of recent blog posts) you simply have to activate the HIDE POST feature in the STATUS section of your post.
You will link to these pages via the MENU you'll create on Publii. You can see examples at the top of my site.
Since I wanted to create a page showcasing all my blog posts besides the latest posts section on the home page, I tagged them all with "marketing tips" and I created a TAG PAGE for this specific tag, promoted in the top menu.
FYI, I removed the "tagged in" mention of that page with a bit of CSS.
display: none !important;
CSS will be your best friend on Publii
If you want to optimize the look n feel of your static website, you'll have to play with Custom CSS via Publii TOOLS page.
Besides all the attention you'll have to invest in the server set up as described above, you will also have to learn some CSS basics to be able to fine tune your static website.
I faced a very annoying bug when customizing my Publii site: I had decided to reduce the height of the hero section of the site on the home page from 42rem to 25rem.
For some reason, this broke the custom CSS behaviour :-(
It was fine on desktop/laptop but when I reduced the screen width under 900px, it wasn't active anymore (note: I'm using Publii's premium Editorial theme)...
Bob at Publii kindly answered my support ticket (on a Sunday!) and sent me a visual-override.js file to fix the problem (I simply had to replace the existing file under input / themes / editorial in the site's folder on my computer). Here's a Dropbox link to download this file if you need it (unzip & replace the existing js file).
You can customize almost anything using CSS rules. I modified the size of some headlines (h2,...) as well as the default color of hyperlinks, buttons, etc.
You can also create your own theme color scheme following these very simple instructions.
Let me stress here how much I appreciate the detailed documentation provided by Publii's development team. I'm not a coder (even if I can play with some basic HTML and CSS) and everything is crystal clear. Kudos to the copywriters.
Adding interactivity to your static website
A static website can include some level of interactivity, for instance data collection forms or inline chatbots, like this short one (the brand new conversational format from Typeform), to sign up for my weekly marketip tips (shameless plug).
You can also add scripts in the HEAD or BODY sections of your site via Publii's TOOLS page.
Since I didn't like the built-in sharing buttons of the Editorial theme, I added my own set of buttons using SHARETHIS.
You will see an example at the bottom of this post (you can share the post to test it).
To automatically insert the buttons in each post / page, I added the Sharethis code snippet in the post.hbs file of the Editorial theme (in inputs/themes/editorial), just before the publication date update (an info I decided to hide via the Publii theme post options).
There's also a Sharethis script added to the HEAD section of the site via TOOLS.
I've also added my GOOGLE TAG MANAGER script in the head section (as well as some code in the BODY section) and DISQUS to allow readers' comments at the bottom of each post.
It took me roughly 2 days for the whole migration, from the exploration of hosting possibilities to the final switch (declaring Cloudfront's URL as a CNAME for my domain, with almost instant propagation).
It would have been faster to move my site from Gandi to Flywheel, for sure, but the performance would have stayed pretty average at best.
Now I have a blazing fast Publii static website and to show my deep appreciation for the amazing work of these developers, I've decided to become a backer on OpenCollective.
Bear in mind that you can't design any type of website with Publii.
If you need specific interactive tools, closer to what we could consider a web application (e.g. a searchable job board, a directory or a map featuring shop locations, a complex booking flow), you will probably keep on working with WordPress or a similar solution for a while, as I still do for other projects. I also have to stick to WordPress for multilingual projects.
But if you just need some basic interactive features, you can create a static website and embed (or link to) external widgets, driven by Google Sheets, Airtable and some other solutions (with the added benefit of being able to leverage the data on the fly using Zapier or Integromat).
Here are a few suggestions:
It's really exciting to see how the web design scene for non-coders is evolving, beyond the WordPress paradigm! Feel free to share your thoughts in the comments below.
- create a local duplicate of your large site configuration (you simple have to clone the folder of the site which sits in your computer) with just one post, to quickly test design modifications before applying them to the main site. This test site will render faster.
- you can access your Publii site(s) from various computers using the same app by hosting your files on Dropbox. Read Publii's tutorial.
- If you modify your Custom CSS, changes might not be reflected on your site for 2 reasons: 1° Caching on Cloudfront (you then need to invalidate the /assets/css/* path) 2° Browser caching (clear browser history).
PS: If you're excited by the perspective of switching from WordPress to a static website but haven't totally understood all the procedure - which is indeed quite intimidating - feel free to contact me and I'll do my best to help you out.