7 Reasons NOT to Use a Static Site Generator

By Craig Buckler
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

Static Site Generators

Trending posts on SitePoint today:

In my previous article we discussed reasons why you could benefit from using a static site generator. To recap:

  • A static site is a collection of pages contained in basic HTML files. You could hand-write these in a text editor, but managing assets and repeated elements such as navigation can become problematic.
  • A content management system (CMS) stores page content in a database and provides facilities to edit and apply themes. Management becomes easier at the expense of flexibility, performance, server requirements, security and backups.
  • A static site generator (SSG) is a compromise between using a hand-coded static site and a full CMS. You generate an HTML-only website using raw data (such as Markdown files) and templates. The resulting build is transferred to your live server.

static site generators

Popular static site generators include Jekyll, Pelican, Hugo and Metalsmith — see StaticGen for many more options.

SSGs appear to offer the benefits of both CMS and static worlds, but they will not be suitable for every project …

1. You’re On Your Own

You won’t get far using a static site generator without some development expertise. The process is more difficult than using a CMS, there are fewer reference resources, and you could struggle to find pre-built plugins and templates.

Contrast that with WordPress. A non-technical user may require installation assistance but, once done, they can edit a site and install one of the many thousands of themes and plugins available. They may not have the best bespoke website, but they’re running with minimal intervention.

2. Choice Paralysis

There are many static site generators, but even the most popular tools are used by a tiny proportion of the web community. You’ll need time to research, investigate and evaluate the options. The undisputed champion is Jekyll but, while you don’t necessarily require Ruby expertise, it will help if you’ve used the language before.

There are many CMSs, but there’s one obvious choice: WordPress. It powers more than one in every four websites, so help is abundant. Again, it will help if you have some PHP experience, but even a non-developer can create a reasonable website using off-the-shelf themes and plugins.

3. The Initial Setup Time

Creating your first static site will take time. You’ll need to learn the build process, and much of the template code will need to be developed. Deployment scripts may also be necessary.

Developing a custom CMS theme can also be complicated, but pre-built templates are available and assistance is easier to find. File deployment is rarely required following the initial installation.

4. No Administration Interface

Clients may be cautious when faced with a CMS interface. Asking them to create and edit a set of Markdown files may terrify many. You can make the process easier. For example:

  1. allow them to use their existing CMS, or
  2. provide simpler workflows such as editing Dropbox files in StackEdit.

But this will further impact your initial development time.

5. Website Consistency

Static sites are flexible: anything contained within source Markdown files can be rendered as page content. Users may be able to include scripts, widgets or numerous undesired items.

A CMS constrains the user, because content is normally bound to a database with specific fields. Control panels prompt the user so it’s obvious they must enter a title, body content, excerpt etc. Even if the user enters something in an unexpected field, it won’t appear on the website unless it’s implemented within the theme template.

6. Managing Large Sites

Consider a website with thousands of pages, regular publications, real-time breaking news and dozens of authors in multiple locations. SitePoint is a great example. It would be possible to manage content using a static site generator, but:

  • content editing and publishing is more awkward. Editors may require access to the Git repo or shared folders rather than a simple web or app interface.
  • real-time updates would be delayed because the site must be rebuilt, tested and deployed
  • build times could increase rapidly and deployment would become cumbersome.

Static site generators are perhaps best suited to sites containing no more than a few hundred pages with a couple of new posts every week. Automated build and deploy processes will be required, and you may reach a point where a CMS becomes a more practical option.

7. Sites with Server-side Functionality

A true static site cannot offer interactive facilities such as user logins, form filling, search or discussion forums. There are some client-side options such as lunr.js search and Disqus commenting, but your choices will be more limited.

There are solutions such as using a build step which generates a static site containing necessary <?php ... ?> code blocks. This should pre-render HTML where possible, e.g. navigation, includes, partials, etc. to ensure pages are more efficient and require less effort from the PHP processor. Unfortunately, you’re increasing the build complexity, and it may be of little benefit to some frameworks.

Is a Static Site Right For You?

Before making any decision, examine:

  • your project requirements, size, complexity, etc.
  • your userbase
  • your team’s development skills, and
  • the hosting and/or deployment factors.

The vast majority of websites rarely exceed a few dozen pages, receive infrequent updates and depend on a developer to make those changes. A CMS is often overkill, and static site generation could ease development and reduce costs. However, persuading your client to abandon their CMS administration panels could be a tougher task …

For a practical demonstration of how to build a site with a static site generator, see my How to Create a Static Site with Metalsmith article.

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Really great, thank’s!

  • One of the reasons listed was better security by having no code executed on the server. That argument falls apart if you’re willing to have some code running.

    • Craig Buckler

      That’s the compromise. A static site is more secure because no server code is executing. But you may need to forego that benefit if you absolutely require server-side processing.

  • mbokil

    A lot of the news sites switch from dynamic to static under a heavy load which limits features but still allows pages to be served. An interesting hybrid approach.

    • Craig Buckler

      Thanks mbokil – that’s a good point. Some sites also produce a few static pages for news or features experiencing heavy load. It’s a great idea but few site owners will have the resources to do it.

    • OHHHhhhh! THAT’s wtf is going on…! I wonder if they could be a little more informative to keep my finger off the refresh key. Think that might help the server?

    • Constraints breed creativity.

  • Craig Buckler

    Great stuff. I agree a static generator is suitable for the majority of sites. It should be the default choice unless many people are making daily updates.

  • Raivo Laanemets

    Do not forget to properly set up redirects for feeds when switching to static site. Static site generators often support feeds but existing readers won’t know about the new feed URL. HTML meta redirects and JavaScript-based redirects won’t work, you need a proper server-side redirect through htaccess file or similar technique. Or just create symlink that matches old feed URL to the new feed file.

  • Fahad Murtaza

    SSGs, that is a cute acronym for Static Site Generators, the other one I know is Special Services Group, the army unit.

  • Hello, thank you very much for this cool advice, i will try to use your tips! Also, I would like you know, what kinds of platform I can use of it! Thank you very much for your answer)

  • Nicholas Johnson

    So don’t use a static site generator if you or your client don’t know how to code, or if you need dynamic content like a forum.

    • I think they call it SquareSpace.

      • True Siteleaf make possibility to auto gen a static and host it but is expensive

        • I wouldn’t call $7.20 a month (the early bird price for Siteleaf currently) expensive.

    • Ralph Mason

      There are also tools like Siteleaf that provide the option to manage and present a static site to your clients.

    • > “So don’t use a static site generator if you or your client don’t know how to code, or if you need dynamic content like a forum.”

      @forwardadvance:disqus There are solutions for both of what you mention.

  • Kael

    O disagree with everything in the article. As a developer I consider Hugo, Harp e Hexo and similar SSGs much more easier to understand than WordPress. How can ppl consider WordPress easy to *properly* manage? My clients are having a better time with markdown and the frontmatter than using wordpress web interface.

    • Craig Buckler

      The point I was making is that you can install WordPress, grab a theme, sprinkle on a few plugins and issue a login ID within minutes. That’s how some companies operate – they don’t write any code. That has to be easier!

      I would love it if all clients preferred markdown. In my experience, most prefer WYSIWYG even if they inevitably mess things up. In addition, they can visually manage the page hierarchy rather than moving or renaming files.

      However, I think you should read the previous article:
      I agree WordPress is overkill for the majority of websites.

      • Michael Butts

        I agree, I am a developer as well using jekyll , customizing my own theme and dealing with importing into an existing site was quite the headache, whereas wordpress I could have installed and been done

  • treegb

    Take a look at Dokuwiki.

    Dokuwiki is a CMS wiki similar to Mediawiki or many other wiki platform, but the system is much more simple to setup, edit, query, backup.

    Dokuwiki is written with PHP so it is a dynamic website, but no database needed, Dokuwiki store data in plane text instead of database. This makes the data more “safe” and posible to read/modify outside of wiki if necessary.

    As a wiki platform, Dokuwiki use wiki markup, which is no different to SSG markup
    , but I’m not sure about insert the dynamic content in content in Dokuwiki, it can insert html tag in content but not sure if PHP works too.

    Dokuwiki have a plugin to convert whole site to static HTML site, this make no different as the efficiency or security aspect compare to SSG.

  • Craig, thanks for putting together two articles to show both sides of the story. I want to emphasize that I read the first article as well, so I appreciate that I don’t think your intentions are to give SSGs a bad rap. There is no question: there are some projects that static site generators simply aren’t meant to handle, and it seems an underlying motif for both articles is that your client’s proclivities can, and should, hold tremendous sway. Before I start, I should note I’ve only been in dev for about 4 years, but I’ve been a publisher for closer to 15:)

    With that said, some of your claims seem to be contradictory–not so much in the pro-SSG article, but more so in this follow-up piece. For example, one of your main points is “Choice Paralysis”, although I’d argue that the selection of professional-grade SSGs is roughly one or two dozen, an exceedingly small number when compared with options for traditional database-driven CMSs.

    Further, your point on decision fatigue comes only a few paragraphs after you extol WordPress’s “many thousands of themes and plugins available.” This implies that a) there isn’t choice paralysis in the themes and plugin world and b) plugin and theme installations don’t have considerable short- and long-term consequences…and we both know they do. The large number of themes for Hugo, Jekyll, and Hexo notwithstanding, this misses a more important point: markdown is the easiest, most inexpensive, and (I would argue) intuitive way to create exportable, standalone content. To your point of deciding on SSGs, the near universality of markdown with embedded metadata stands as a fail safe for client’s concerned with long-term preservation of intellectual property in the event that an open-source SSG is no longer maintained. The real challenge goes from “how to get the hell out of WordPress” to finding a computer *anywhere* that can’t open a text file to be modified.It’s worth noting that in the world of text files, storage becomes an unequivocal non-issue.

    To your point of being able to find more help in the large development community, this implies that a solution like WordPress gives your clients more freedom in choice of vendors after project handoff. I’d be interested in meeting a designer for WordPress that somehow can’t manage to write CSS and JavaScript for an SSG that uses a much more intuitive templating syntax than PHP.

    Your point about how “content editing and publishing is more awkward” with SSGs is certainly not my personal experience. From what I’ve observed, files and folders dovetail very well with the conceptualizations of content held by many “non-technical users.” More importantly, it also conforms very well with the mental model of…the Internet. The URL is a beautiful thing because it can be easily grokked by my 5-year-old niece; this is why even “dynamic” CMSs like WordPress output files according to this paradigm.

    I know this is not the crux of this piece, but I think there are learning opportunities for any *company* that wants to approach web publishing professionally and is faced with this dichotomy. These include, but are not limited to the following:

    – Separation of concerns and semantics; i.e., since markdown forces you to abide by the former and leverage the latter. An often under-lauded consequence is much better writing.
    – SEO. You touched on this already in your previous article w/r/t performance.
    – Security. We don’t need to ruminate over WP’s abysmal track record, but I’d like to note that Hugo’s Golang templates will auto-magically escape the “scripts” you mentioned in I think what may have been an intimation of a security weakness in markdown.
    – Exportability and versioning. You touch on this in the previous article, but when it comes to intellectual property, git is the most powerful version control system known to man. NOTHING in the WordPress world comes close. It’s also free. So are accounts with GitHub, Gitlab, and Bitbucket.
    – Search as a module and other “server-side functionality.” If we’re talking about publishing websites, only mentioning lunr.js is a bit reductive. At the end of the day, the best choices for your clients are likely to be the same with WP, Hugo, Jekyll, etc. NB, WordPress search is, well, a joke. Also, I believe I’m writing a Disqus comment on a WordPress site right now, no?
    – Getting up and running. Granted this article is now 8 months old, but I would like to see the time it takes to set up a 2000-post blog with WordPress vs a 2000-post blog with Hugo and Netlify, which is basically the coolest service on the planet, IMHO. (I work for a nonprofit in Chicago, so I’m not using this comment as a revenue generator.)

    If the idea is that a client can get up and running by doing everything themselves and I’m not bringing up these points or offering development and publishing expertise, the first question to ask *could* be why I’m there in the first place. Then again, there are a lot of tough clients in the world, so I empathize, and you certainly bring up this point in the last couple sentences of the article.

    P.S. For what it’s worth, please know I’ve read dozens of your articles and I’m an unabashed fan that’s been meaning to comment for some time now. Seriously. However, this “part 2” seems like a bit of a hackneyed add-on to the sensibilities you espoused only one day earlier.

  • Oh man, a full 10 seconds? This *must* be an old article…;)

    • For those of you who learned how to do short division back in grade school, that’s 500 pages per second, or 1 page every 2 milliseconds. As of Hugo 1.7, when multilingual sites were introduced, Hugo page generation speed doubled. But that was sooo 5 months ago. *snickers*

  • > But, for most people, it is hard to see how an SSG would be worth the trouble.

    @walterbyrd:disqus Please see my comments above. I think your point is an interesting one, but I took this article in a very different way; i.e. managing the sometimes contradictory needs of your client with what are really best practices. “Easily synced with Google Drive” is in fact a great feature…as long as you never plan on leaving that ecosystem…or really ever owning your intellectual property in its entirety.

  • I believe SitePoint has chosen to selectively include comments which make them look good. As a result, I cannot condone information provided on this website and myself will no longer use it as a resource.

  • I wouldn’t touch Netifly with a 10 foot pole.

  • Subramani Ananthapadmanabhan

    I am an IT Pro and not a developer. I still think most of these articles are targeted at experienced web developers. After spending days figuring out Hugo (as it is blazingly fast); I realized that the speed here is at generating HTML pages not “serving” HTML pages like a HTTP server would do. Seems you do need to copy the Hugo Generated files to another web server like NGINX. So I am unable to understand if this blazing speed (to generate html files from 10,000 Markdown files) is needed for someone running a blog? I was looking for guidance on getting started with maintaining a tech blog that pulls Markdown hosted in Github and then render them into nice HTML with “Automatic” copy buttons next to tags. seems all HUGO/Jekyll do is more of convert some input file to HTML files and a HTTP server to preview what was generated.. is this understanding correct?

    • Craig Buckler

      In theory, generation speed doesn’t matter – you do it once to create static HTML files then move those to a web server (with Apache, NGINX, IIS or whatever). In practice, it does matter because you’ll be tweaking content and templates then re-rendering many times to check the changes. Moving a page could affect the whole site structure so menus on every page must be regenerated.

      As for hosting files on GitHub, your project should contain all the markdown pages, templates, processes, images and other assets required to build the site. You wouldn’t pull just the markdown – you’ll pull everything and generate it on your PC prior to upload. That said, SSGs can pull data from anywhere so you could programmatically grab data from GitHub but I cannot see much benefit in doing so – it’d just make content harder to manage.