Why we Chose a Static HTML Site Over a Dynamically Served One — Our Story
First, I have a confession to make: our new website is still under development. We are really working hard to make everything work 100% before we start blogging over there.
I think it’s time for everyone who cares about speed to rely on a static website solution instead of a dynamically served one. For example, choosing Jekyll over WordPress.
For blogging, we think Medium will do for now, that explains why we don’t need WordPress.
Again, it is possible to blog on a static website by the way, so no big deal.
Blogging using a static website solution is simple as long as you set up everything beforehand.
You will then use Sublime Text or any text editor of your choice to write blog posts and then save them, and push. And the post is live!
Our major goal is to share stories and articles that reach as many people as possible.
This means rather than relying on SEO of a new domain like ours, it’s a better choice to start here at Medium and then later start blogging on our own website.
How we decided it was time to move from WordPress to a simple static site generator — Jekyll
We were in a restaurant; two of my friends and I, and we started discussing the projects we have completed in the past two years.
Our focus narrowed onto one project we collaborated on back in 2015.
I don’t know how Google PageSpeed Insights found itself in our conversation. But I will tell you what happened next: We loaded Google’s PageSpeed Insights to check how our client’s site was performing.
Even though we had done a great job to select the best caching plug-in, minified all the files of the theme we had created for the client in the best way we could, we were still being greeted with strange complaints by the search giant.
We passed its mobile test, but failed terribly when it came to the desktop test.
We approached the client the following week to sort out the issues.
In the end, we scored only 65/100 which wasn’t so bad after all (most optimizations were to leverage caching, as we realized the client had somehow disabled the plugin, and help her compress the images and use another plugin to minify JS and CSS files).
Sincerely, the client didn’t know about the implication of the issues on her site, but she thanked us for taking our time to help her sort out the issues.
Whoa! After that, we went back to the drawing board.
Our new approach
Never again will we fail to educate our clients on the advantages and disadvantages of any chosen solution — even if they propose it to us like our client had done.
To redefine our future approach, we divided into the web to look the best way to solve page loading issues of a website.
We realized many people are going back to the 90s. Static HTML, Facebook comments plug-in or Disqus for comments, and Formspree for form submissions.
Others were leveraging advanced CRM softwares for lead generation, meaning they don’t need any server-side code other than embedding the tracking code on the HTML pages of their websites.
Here is a lovely link listing the best of the best free CRM tools you can choose from.
What we did.
We were now so sold into the idea of static websites. But then we were also to find the right tool to use to generate the static content.
It took us a whole week to finally make a decision. We read several reviews, tried a few, but finally, we settled on Jekyll. It’s a killer!
Jekyll, as it occurred to us, is well documented, just like the others, but it’s additionally widely used. Meaning that an issue that we were to come across most likely had a solution lying somewhere on the web.
Making our client happy
When we were confident, we went ahead to convert all the pages of the website to html but for the other functions that we could not touch for the moment, we created a subdomain and installed WordPress there.
So right now, the homepage and all other frequently visited pages are static, while the major functions we had written for WordPress still find their home within the subdomain installation of WordPress.
Our website was next on the line. We knew that we could not host it on Github Pages forever.
We were sure that somehow we had to integrate SSL in future. Why would we not go fully HTTPS when Let’s Encrypt is giving it out for free? Besides, today’s browsers have an annoying habit of reminding your visitors how insecure your website is if it has no encryption.
And just as a side note: If you are to use https to serve content from your website, make sure that all the fonts, CSS styles and scripts that you link on any page of your website are https://example.com/script etc. Otherwise, The browser will show a red flag to the user telling them that anything that they share with your site can be hijacked.
Github Pages doesn’t support SSL integration for custom domains.
If you have a question, feel free to ask in the comments section below.
See you in the next one as we explore much about taking your small to medium business online.
Our journey has not been without hiccups. Some functions couldn’t work while we were testing the site over at gh pages. But those hiccups are gone now. For example, we could not use the Paginate plugin for the blog while on gh pages. Remember that Github Pages doesn’t support all of Jekyll plugs, it supports just a few. This is true unless you are ready to build your website locally and push the resulting static files.
Thanks for reading. Click the ❤ button below if you liked this article. Follow us for more insightful information.
Elevatika has a personality. She is listening, determined and delivers results.
We create modern, beautiful and fast-loading websites, design attractive and inspiring brands, and we manage social media accounts for forward thinking individuals and businesses.