From WordPress to Jekyll
Guillaume Briday
5 minutes
Up until last May, my personal website and blog used two different technologies, namely WordPress on one side and Pug then Middleman on the other. It was far from ideal to maintain, evolve, or use on a daily basis.
So I decided to bring everything together with a single technology that met my needs and desires; thus, I turned to the famous Jekyll.
What is Jekyll?
Jekyll is a tool developed in Ruby that allows you to generate static pages and a blog. Concretely, by adhering to a structure defined by Jekyll, writing your pages in Markdown or Liquid, and with a customized configuration, you simply need to run a single command line to generate your entire website with the correct folder architecture and HTML files ready to be deployed on any host.
One quickly understands why this technology is very interesting to use.
Why did I migrate?
Performance gain
As I just mentioned, Jekyll compiles our site. We thus obtain a set of static HTML pages. Unlike a CMS like WordPress, the pages do not need to be generated at each visit. There is no database connection that takes an eternity to always make the same queries. Not to mention the addition of certain plugins, which are not particularly performance-friendly when it comes to the web.
Thus, my blog went from an average loading time between one and two seconds to less than 500 ms. It's much more pleasant to use; the feeling of slowness has completely disappeared, and the experience is only better for the user.
Gain in stability and security
There are no updates to do to fix security vulnerabilities every two weeks. There is no code to maintain, no PHP version to specify, and finally no need to update PHP or MySQL. It's the huge advantage of working with simple .html
files.
Simple to backup
With Jekyll, you work only with files. From the tool's configuration, to the theme and articles, it's only .md
, .html
, or .yml
files. No need to maintain a database with dumps to make regularly for fear of losing everything.
Unlike WordPress (where it is not very relevant), here we can version our configuration and theme in the same place. A single very lightweight folder can be backed up and transferred to the cloud or GitHub.
Simple to deploy
Once everything is compiled, your pages and assets are in one single folder named _site
. Of course, inside it, you will find HTML files named according to your pages, but also subfolders (to manage categories, for example), your images, and everything your site needs to function.
The idea is not to touch this folder; all modifications must be made upstream.
You can compile everything as many times as you like; then, just take this folder and upload it to your FTP for everything to work. It's the only thing to do, and it's perfectly transparent for users.
If you use a version control system like Git, know that many services handle hosting for you; you just need to push
your code to the remote repository, and the site will be compiled for you. It's great!
The most well-known being GitHub Pages if needed. Unfortunately, at the moment, you cannot have your own secured domain name via GitHub; you will need to use a third-party hosting.
Simple to write articles or pages
Jekyll is designed to use Markdown when writing an article or a page. It natively converts your markdown files into HTML pages. It's super practical because there's no need to connect to a slow and complex interface, among other things. You just need to open a text file, and you're ready to write.
No need for an internet connection or a computer. Now, I often find myself starting my articles on my iPhone because the Markdown syntax avoids having a complex interface for formatting.
Moreover, I can now very easily share the source code of my site. This gives readers the ability to correct or modify an article or other directly via a Pull Request on GitHub, which can save me from having to do it manually in some cases.
Managing comments
I might be getting carried away a bit. There are some downsides, and not insignificant ones, when managing a blog. Since Jekyll is not a server-side technology, there is no comment management.
My goal being to make this blog also a space for exchange, it's problematic. Fortunately, there is a plethora of solutions available.
The most used (even on CMS like WordPress) is undoubtedly Disqus. You must have already seen it on many sites. Setting up Disqus is child's play and the user experience is super pleasant, but it poses several problems for me.
First, it breaks the simplicity of backup and deployment I was looking for with Jekyll. Comments are hosted on an external service over which I have no control. Disqus is also awfully slow; it needs many JavaScript dependencies, and in the end, I end up with the same loading times I had with WordPress.
Finally, user privacy is not respected by Disqus, which tracks the sites you visit—not cool.
There are open-source and much lighter alternatives like Isso, but they still do not meet my needs.
To not complicate my life, I took advantage of the presence of PHP on my host to make a simplistic script that sends me an email via a form at the bottom of each article; I was inspired by an existing plugin: jekyll-static-comments. Once I receive the information by email, I add them in a _data
file, these files are natively managed by Jekyll.
When generating the site, Jekyll retrieves the list of comments, which are then added statically to each article. This allows me to greatly simplify backup and deployment. However, it's an action I have to do manually for each comment, unless someone sends me a Pull Request directly.
This solution does not limit spam, and it's a less pleasant user experience, I find. A good compromise had to be found, and with the little traffic I have, the goal is perfectly met. There are even already some comments on the site!
Managing assets and templates
Jekyll natively integrates support for Sass and CoffeeScript (with a gem), which is really handy.
Sass handles import
and minification, which is not yet the case in JavaScript. So, if you want to minify your JS or use require
, you will necessarily have to use tools like Webpack or Gulp.
For the theme part, Jekyll integrates the template engine Liquid. I'll let you read the documentation to see all the possibilities, but what you should remember is that you can use layouts for each of your pages and create reusable pieces of HTML for each of your pages. Thus, it is quite possible to find the following code in a post.html
file:
<body>
{% include header.html %}
<div class="container">{{ content }}</div>
{% include footer.html %}
</body>
Your article's content will replace {{ content }}
, and thus this layout will be reusable, but used only during compilation and not at each page load. The possibilities are endless, and if you wish to see a concrete example, the source code of this site is available on GitHub.
One last interesting feature, mainly for developers, is the support for Highlight. Highlight allows managing syntax highlighting of code snippets during compilation, which will avoid some latency when this is done in JavaScript upon page load.
I hope I have been clear about the reasons that led me to make this change; if you have any questions, do not hesitate to ask them in the comments.
Thank you!