Full Circle Magazine FR

Ceci est une ancienne révision du document !

Last month, I wrote about Ubuntu Phone, intending to follow up on it this month. Unfortunately, I’ve lacked the time to complete the article for this issue – you can expect it to be in next month’s issue. Instead, I’ll discuss a new website creation tool called ‘static site generation’. If you’re not interested in websites, and want to learn more about Ubuntu Phone programming, check back next month!

What is static site generation?

Static site generators are command-line tools that can take content from formats such as markdown and reStructuredText, and insert the content into HTML templates. At the most basic, you can think of it as a content management system that, when compiled, doesn’t save content to a database, but straight into a static html page.

But… why?

Anyone who has had to work to optimize a page for performance knows that static sites load much faster (and with less effort), because there is no delay while querying the database, or while running for-loops to insert information. Naturally, some sites lend themselves to content management systems (really large sites, sites with various editors and moderators, or sites that need to serve dynamic content). As is always the case in web design, it’s a matter of picking the right tool for the job, in order to create the site as fast as possible, to have it perform well, and to avoid reinventing the wheel at every turn.

But my CMS site loads quickly?

It’s possible to have a site load very quickly when being used with a CMS, but this is generally the result of a great deal of testing, and plenty of performance tweaks.

A comparison

Note: According to studies by Google, any site that takes longer than 1 second to load (on mobile, mainly) will generally have users leave due to the wait. Studies from Amazon and Google also saw that an increase of loading time of 1 second (say, for example, from 400ms to 1.4s) could result in a drop of revenue between 14 and 18%.

A site I am working on was originally created using Django CMS - where it would load in about 612ms from my local machine (with no network latency, a quad core CPU, and an SSD), which is perfectly reasonable. Shifting it to an Nginx server running uwsgi saw the load times jump up to 700-800ms. However, the more content that was added to the page, the longer it would take. Version 3.2 of Django CMS seems to have improved on the speed, but it is not, as of writing, at a final release. The equivalent site using Pelican (a static site generator) loads in 402ms, and the only optimization I have done so far is to merge my CSS files. There is no compression of any sort running, and is being served only with python http.server. As the site is a redesign for my own company, and I will be the only one managing it, I have no need for a CMS – I could just as easily write the HTML by hand. However, the number of pages make it unreasonable to create everything by hand, which is where Pelican comes in. I can manage my content easily in reStructuredText (or, theoretically, anyone who knows Markdown, HTML, or reStructuredText), and can assign various templates to the pages, according to the meta information. The resulting static site can be hosted easily and quickly on Nginx, and use less resources than a Django CMS setup running Nginx, uwsgi, and postgresql. Note: this is not a criticism of Django CMS, as I could probably optimize my approach in order to reduce load times. A static site generator simply reduces the amount of optimization I need to accomplish.

I’m sold! Where do I start?

There are various static site generators on offer. The most common and well-known is Jekyll, which is used for GitHub Pages, among other things. Jekyll uses the Liquid templating language, and is written in Ruby. I, however, am currently using Pelican, and for two main reasons: It uses Jinja2 for templating, which is the same as Django. Meaning I could carry over existing templates quickly. It is written in Python, and so has integrated translation options for multilingual sites (using Jinja2 i18n). As my site is always in English and German, this was a big factor for me.

So, depending on what you’re most comfortable with, you may prefer Jekyll over Pelican, or a number of other static site generators over either. Use what you’re comfortable with, as it will help cut down the learning curve. If you want to use plugins for automatic integration of bootstrap (for example), then I would recommend checking the plugin options before choosing a generator.

Does this mean I can’t use forms, or any dynamic content at all?

Forms are essentially just HTML that gets sent via POST (typically) to a php file. If you use a combination of Nginx and apache (or just apache), you can still include a php file for sending the information around. Depending on what you mean by dynamic content, it should be possible too. iFrames or widgets from other sites shouldn’t be an issue, or, if you want to semi-dynamically create a grid (for example), you can create templates using for-loops to iterate through information in order to insert it into HTML. If you’re looking for login areas and personalized HTML, a CMS will probably be easier for this.

Okay, I’ve installed a generator. What now?

Now would be the time to check the homepage and view the documentation. As each generator has a slightly different file structure, and different commands to compile, it’s necessary to check the documentation. Once you’ve created a project (most likely done with a quickstart command), then it’s time to create some sample content, and a template (or to adjust an existing template).

My site is done…do I have to buy hosting?

Since static HTML is so easily served, there are some offerings where you can upload a site without much trouble. For example, GitHub Pages. Technically, you could even host it in some fashion on Dropbox. So, depending on your needs, you may not need to pay for additional hosting - or if you do, you’ll most likely not need too powerful a server to adequately serve the content.

Should I optimize?

Depending on how quickly your site loads, you may not feel you need to. My recommendation, at least, is to optimize images and enable server compression if your site is going to be mobile-friendly. Assuming, of course, that you’ve minimized your CSS and JS already. You’ll most likely not need to do every optimization you can for that last 3% decrease in size, but some basics are recommended.

I hope this article has been interesting for anyone looking at, or working on, a project where you keep thinking “this site is almost too small for a CMS, but too large for doing it by hand!”. Or anyone interested in creating a quick project website for GitHub. If you have questions, suggestions, or comments, you can reach me at lswest34+fcm@gmail.com.