Merge commit '83bef6955e014d40c0f00db9cebe09113154e999'

docs/content/en/showcase/1password-support/bio.md

@@ -0,0 +1,5 @@
+
+**1Password** is a password manager that keeps you safe online. It protects your secure information behind the one password only you know.
+
+
+The [1Password Support](https://support.1password.com/) website was built from scratch with **Hugo** and enhanced with **React** and **Elasticsearch** to give us the best of both worlds: The simplicity and performance of a static site, with the richness of a hosted web app.

docs/content/en/showcase/1password-support/index.md

@@ -0,0 +1,39 @@
+---
+
+title: 1Password Support
+date: 2018-02-22
+description: "Showcase: \"Compiles 400 pages in five languages in the blink of an eye.\""
+siteURL: https://support.1password.com/
+byline: "[Mitch Cohen](https://github.com/mitchchn), Documentation Team Lead"
+aliases: [/showcase/1password/]
+
+---
+
+At 1Password, we used to go through a different documentation platform every month: blog engines, ebooks, wikis, site generators written in Ruby and JavaScript. Each was inadequate in its own special way. Then we found **Hugo**. We made one last switch, and we're glad we did.
+
+### Not all static site generators are created equal
+
+Finding a tool that will make your customers, writers, designers, _and_ DevOps team happy is no easy task, but we managed it with Hugo:
+
+**Hugo is static**. We're a security company, so we swear by static sites and use them wherever possible. We feel much safer pointing customers at HTML files than at a complicated server which needs to be hardened.
+
+**Hugo is Go**. We love the Go programming language at 1Password, and we were delighted to learn that Hugo used the same Go template syntax that our designers and front-end developers had already mastered.
+ 
+**Hugo is FAST**. Our previous static site generator took nearly a minute to compile our (then much smaller) site. Developers might be used to this, but it wasn't cutting it for writers who wanted to see live previews of their work. Hugo did the same job in milliseconds, and to this day compiles 400 pages in five languages in the blink of an eye.
+
+**Hugo is flexible**. Thanks to Hugo's content and layout system, we were able to preserve our existing file and folder structure and port our entire production site in a few days. We could then create new content types that weren't possible before, like these snazzy [showcases](https://support.1password.com/explore/extension/).
+
+**Hugo is great for writers**. Our documentation team was already comfortable with Markdown and Git and could start creating content for Hugo with zero downtime. Once we added shortcodes, our writers were able to dress up articles with features like  [platform boxes](https://support.1password.com/get-the-apps/) with just a bit of new syntax.
+
+**Hugo has an amazing developer community**. Hugo updates are frequent and filled to the brim with features and fixes. As we developed the multilingual version of our site, we submitted PRs for features we needed and were helped through the process by [@bep](https://github.com/bep) and others.
+
+**Hugo is simple to deploy**. Hugo has just the right amount of configuration options to fit into our build system without being too complicated.
+
+### Tech specs
+
+* [1Password Support](https://support.1password.com) uses Hugo with a custom theme. It shares styles and some template code with [1Password.com](https://1password.com), which we also moved to Hugo in 2016.
+* Code and articles live in a private GitHub repository, which is deployed to a static content server using Git hooks.
+* Writers build and preview the site on their computers and contribute content using pull requests.
+ * We use Hugo's [multilingual support](/content-management/multilingual/) to build the site in English, Spanish, French, Italian, German, and Russian. With the help of Hugo, 1Password Support became our very first site in multiple languages.
+* Our [contact form](https://support.1password.com/contact) is a single-page React app. We were able to integrate it with Hugo seamlessly thanks to its support for static files.
+* The one part of the support site which is not static is our search engine, which we developed with Elasticsearch and host on AWS.

docs/content/en/showcase/flesland-flis/bio.md

@@ -0,0 +1,8 @@
+
+A business page for Flesland Flis AS. A Norwegian Tiler located in Bergen.
+
+The page is designed and developed by Sindre Gusdal:
+
+* [Absoluttweb AS](http://www.absoluttweb.no)
+* [Sindre Gusdal](https://www.linkedin.com/in/sindregusdal/)
+

docs/content/en/showcase/flesland-flis/index.md

@@ -0,0 +1,24 @@
+---
+
+title: Flesland Flis AS
+date: 2018-04-24
+description: "showcase: Business Page for a tile shop in Bergen, Norway"
+siteURL: https://www.fleslandflis.no
+byline: "[Sindre Gusdal](http://www.absoluttweb.no), Absoluttweb AS"
+
+---
+
+For **Flesland Flis** I use a combination of **Hugo, Forestry.io and Netlify**. Static Site Generators and Hugo has been on my radar for a long time, and with all the nice features released in Hugo the last years, it's now my preferred solution for new clients. Also a huge thanks to the guys at [Forestry.io](https://forestry.io), for making such a smooth CMS for Hugo.
+
+The #1 reason why I love Hugo is the logic between content and layout, and of course the speed. Compared to solutions like Jekyll, Hugo is just better at all the stuff I value the most - speed, flexibility, theming and more.
+
+### Thanks, Hugo!
+
+Today I use Hugo in a combination with GULP and Foundation 6 + my own Hugo starter theme. This works great for me, and gives me all the flexibility I need. Then I can include FancyBox, Responsive Text and other Node Modules when needed.
+
+In the past I had to do a lot of changes to layout, content and css, if the client f.ex needed an extra PDF or an image-gallery to a certain page. Just small details not fitting in the template, would be a hassle. So updating existing webpages was boring and time consuming.
+
+Today I just copy-paste a new layout file, adds some frontmatter, Pushes to GIT and that special page is done.
+
+**Gotta love it:)**
+

docs/content/en/showcase/forestry/bio.md

@@ -0,0 +1,5 @@
+
+Forestry.io is a Git-backed CMS (content management system) for websites and web products built using static site generators such as Hugo. 
+
+Forestry bridges the gap between developers and their teams, by making development fun and easy, while providing powerful content management for their teams.
+

docs/content/en/showcase/forestry/index.md

@@ -0,0 +1,48 @@
+---
+title: Forestry.io
+date: 2018-03-16
+description: "Showcase: \"Seeing Hugo in action is a whole different world of awesome.\""
+siteURL: https://forestry.io/
+siteSource: https://github.com/forestryio/forestry.io
+---
+
+It was clear from the get-go that we had to go with a static site generator. Static sites are secure, performant, and give you 100% flexibility. At [Forestry.io](https://forestry.io/) we provide Content Management Solutions for websites built with static site generators, so we might be a little biased. The only question: Which static site generator was the right choice for us?
+
+### Why Hugo?
+
+In our early research we looked at Ionic’s [site](https://github.com/ionic-team/ionic) to get some inspiration. They used Jekyll to build their website. While Jekyll is a great generator, the build times for larger sites can be painfully slow. With more than 150 pages plus many custom configurations and add-ons, our website doesn’t fall into the low-volume category anymore. Our developers want a smooth experience when working on the website and our content editors need the ability to preview content quickly. In short, we need our builds to be lightning fast.
+
+We knew Hugo was fast but we did [some additional benchmarking](https://forestry.io/blog/hugo-vs-jekyll-benchmark/) before making our decision. Seeing Hugo in action is a whole different world of awesome. Hugo takes less than one second to build our 150-page site! Take a look:
+
+```bash
+                   | EN   
++------------------+-----+
+  Pages            | 141  
+  Paginator pages  |   4  
+  Non-page files   |   0  
+  Static files     | 537  
+  Processed images |   0  
+  Aliases          |  60  
+  Sitemaps         |   1  
+  Cleaned          |   0  
+
+Total in 739 ms
+```
+
+In fact, we liked Hugo so much that our wizard Chris made his workflow public and we started the open-source project [Create-Static-Site](https://github.com/forestryio/create-static-site). It's [a simple way to spin up sites](https://forestry.io/blog/up-and-running-with-hugo/) and set up a modern web development workflow with one line of code. Essentially it adds build configurations as a dependency for JS, CSS and Image Processing.
+
+Lastly, we want to take the opportunity to give some love to other amazing tools we used building our website.
+
+### What tools did we use?
+
+* Our Norwegian designer Nichlas is in love with [**Sketch**](https://www.sketchapp.com/). From what we hear it’s a designer’s dream come true.
+* Some say our main graphic is [mesmerizing](https://twitter.com/hmncllctv/status/968907474664284160). Nichlas created it using [**3DS Max**](https://www.autodesk.com/products/3ds-max/overview).
+* [**Hugo**](https://gohugo.io/) -- of course.
+* Chris can’t think of modern web development without [**Gulp**](https://gulpjs.com/) & [**Webpack**](https://webpack.js.org/). We used them to add additional build steps such as Browsersync, CSS, JS and SVG optimization.
+* Speaking about adding steps to our build, our lives would be much harder without [**CircleCI**](https://circleci.com/) for continuous deployment and automated testing purposes.
+* We can’t stop raving about [**Algolia**](https://www.algolia.com/). Chris loves it and even wrote a tutorial on [how to implement Algolia](https://forestry.io/blog/search-with-algolia-in-hugo/) into static sites using Hugo’s [Custom Outputs](https://gohugo.io/templates/output-formats/).
+*  [**Cloudinary**](https://cloudinary.com/) is probably one of the easiest ways to get responsive images into your website.
+* We might be a little biased on this one - We think [**Forestry.io**](https://forestry.io/) is a great way to add a content management system with a clean UI on top of your site without interrupting your experience as a developer.
+* For hosting purposes we use the almighty [**AWS**](https://aws.amazon.com/).
+* [**Formspree.io**](https://formspree.io/) is managing our support and enterprise requests.
+* We also use browser cookies and JS to customize our user’s experience and give it a more dynamic feel.

docs/content/en/showcase/hartwell-insurance/bio.md

@@ -0,0 +1,6 @@
+
+Hartwell Insurance is an insurance company set up solely to service the Broker community.
+
+By combining **Hugo**, **Service Worker** and **Netlify**, we were able to achieve incredible global site performance.
+
+The site was built by [Tomango](http://www.tomango.co.uk)

docs/content/en/showcase/hartwell-insurance/index.md

@@ -0,0 +1,69 @@
+---
+
+title: Hartwell Insurance
+
+date: 2018-02-09
+
+description: "Showcase: \"Hugo + Netlify + PWA makes for a rapid website.\""
+
+siteURL: https://www.hartwell-insurance.com/
+
+byline: "[Trys Mudford](http://www.trysmudford.com), Lead Developer, Tomango"
+
+---
+
+We’ve just launched a shiny new website for [Hartwell Insurance](https://www.hartwell-insurance.com/) – I’m really proud of it. It was tackled in a different way to most previous Tomango site builds, using some fancy new tools and some vintage web standards.
+
+It’s a multi-page, single-page (!) website written in Hugo, a static site generator built with performance as a first-class feature. _I’ve outlined a load of benefits to Hugo & static sites [here](https://why-static.netlify.com/), in case you’re interested._
+
+> **In essence, a static site generator pre-renders the whole site into HTML files and serves them like it’s 1995.**
+
+There’s no Apache or Node backend that does compilation at runtime, it’s all done at the build step. This means the server; Netlify in this case, only has to do one thing – serve files. Unsurprisingly, serving simple files is VERY quick.
+
+The starter point was the [Victor Hugo](https://github.com/netlify/victor-hugo) repository that Netlify have created. It let me dive in with Hugo, PostCSS, BrowserSync and ES6 without setting up any tooling myself – always a win!
+
+I then took all the content from the design file and moved it into Markdown, putting shortcodes in where necessary. This site did need a number of custom shortcodes for the presentational elements like the expanding circles and full width backgrounds. But mostly it was just clean, semantic HTML with some CSS and JS enhancement thrown in.
+
+For example, this two column layout shown below. I used CSS Columns with a  `break-after: always;` on the `<h1>`. No multi-wrapper or difficult-to-clear shortcodes, just clean HTML.
+
+![The multi-column setup on Hartwell Insurance](hartwell-columns.png)
+
+For the ripple effects on the section headings, I used JS to prepend a `<canvas>` element then animated it with `RequestAnimationFrame`. It adds a nice bit of movement on the page.
+
+On the [Hartwell Profitmaker](https://www.hartwell-insurance.com/profitmaker/) section, I toyed with the idea of using Vue.js for the calculator, but after giving it some thought, I decided to code in Vanilla. The result, all of the site JS comes in at 3.2KB!
+
+The plan was to host with Netlify and therefore get access to Netlify Forms. It meant spending 0 minutes on getting a backend set up – I could focus fully on the frontend.
+
+Cache invalidation isn’t normally something I spend all that much time thinking about when building a site. But as this site was going to be a Progressive Web App, invalidating files would be important to ensure the site didn’t appear broken when we made changes. As I was using Victor-Hugo, I wasn’t really sure how to best tackle this and sadly spent far too many hours wrangling with Webpack and Gulp files to try and get hashed file names working nicely.
+
+Then; while I was waiting for a haircut, I read a [Netlify blog post](https://www.netlify.com/blog/2017/02/23/better-living-through-caching/) on how they do cache invalidation with HTTP2 and it promptly blew my mind.
+
+When you request an asset, they send an ETag in the headers which is a hash of the file. There’s also a header to tell the browser not to trust it’s own cache (which sounds a little bit bonkers).
+
+So when you request the page, it opens a persistent HTTP2 connection up (so no new connections for file requests). When it gets to requesting that asset, the browser sends the ETag back to Netlify and they either return nothing if the ETag matches, or the new file with the new ETag. No `app.klfjlkdsfjdslkfjdslkfdsj.js` or `app.js?v=20180112`. Just a clean `app.js` with instant cache invalidation. Amazing.
+
+Finally, the [Service Worker](https://www.hartwell-insurance.com/sw.js) could be added. This turned out to be straightforward as the Netlify cache invalidation system solved most of the pain points. I went for a network-first, cache-fallback setup for both assets and HTML. This does mean flaky speeds are reliant on the page connection time, but given we’re on HTTP2, I’m hoping the persistent connection and tiny ETag size will keep it quick. For online connections, every request is up to date and instantly live after any update. Offline connections fall back to every assets’ last cached state. It seems to work really nicely, and there’s no need for an update prompt if assets have changed.
+
+---
+
+## The results
+
+The WebPageTest results are looking good. The speed index is 456, 10x smaller than the average Alexa top 300,000 score.
+
+![WebPageTest results](hartwell-webpagetest.png)
+
+[TestMySite.io](https://testmysite.io/5a7e1bb2df99531a23c9ad2f/hartwell-insurance.com) is return ~2ms time to first byte from the CDN edge nodes. Lighthouse audits are also very promising. There’s still some improvement to be gained lazy-loading the images and inlining the CSS. I’m less excited about the [second suggestion](http://www.trysmudford.com/css-in-2017/), but I’ll certainly look at some lazy-loading, especially as I’m already using `IntersectionObserver` for some animations.
+
+![Lighthouse results](hartwell-lighthouse.png)
+
+The most encouraging result is how quick the site is around the world. Most Tomango clients (and their customers) are pretty local and almost exclusively UK-based. We have a dedicated server in Surrey that serves our market pretty well. It did take me by surprise just how much slower a connection from the USA, Australia and Japan to our server was. They’re waiting ~500ms just for the first byte, let alone downloading each asset.
+
+[Hartwell Insurance](https://www.hartwell-insurance.com/) are a US company so by putting them on our server, we’d be instantly hampering their local response times by literally seconds. This was one of the main reasons for going with Netlify. They provide global CDN hosting that’s quick from anywhere in the world.
+
+---
+
+This project was such a blast to develop, it’s a real pleasure to put new technologies to good use in production, and to see real performance and usability benefits from them. Even using classic web methods of serving folders with files is fun when you’ve been databasing for a while – there’s something really ‘pure’ about it.
+
+---
+
+_This was originally posted on [my website](http://www.trysmudford.com/perfomance-wins-with-hugo-and-netlify/)_

docs/content/en/showcase/letsencrypt/bio.md

@@ -0,0 +1,3 @@
+
+
+Let's Encrypt is a free, automated, and open certificate authority (CA), run for the public's benefit. It is a service provided by the [Internet Security Research Group (ISRG)](https://letsencrypt.org/isrg/).

docs/content/en/showcase/letsencrypt/index.md

@@ -0,0 +1,21 @@
+---
+title: "Let’s Encrypt"
+date: 2018-03-13
+description: "Showcase: Lessons learned from taking letsencrypt.org to Hugo."
+siteURL: https://letsencrypt.org/
+siteSource: https://github.com/letsencrypt/website
+byline: "[bep](https://github.com/bep), Hugo Lead"
+---
+
+The **Let’s Encrypt website** has a common set of elements: A landing page and some other static info-pages, a document section, a blog, and a documentation section. Having it moved to Hugo was mostly motivated by a _simpler administration and Hugo's [multilingual support](/content-management/multilingual/)_. They already serve HTTPS to more than 60 million domains, and having the documentation available in more languages will increase that reach.[^1]
+
+{{< tweet 971755920639307777 >}}
+
+I helped them port the site from Jekyll to Hugo. There are usually very few surprises doing this. I know Hugo very well, but working on sites with a history usually comes up with something new.
+
+That site is bookmarked in many browsers, so preserving the URLs was a must. Hugo's URL handling is very flexible, but there was one challenge. The website has a mix of standard and what we in Hugo call _ugly URLs_ (`https://letsencrypt.org/2017/12/07/looking-forward-to-2018.html`). In Hugo this is handled automatically, and you can turn it on globally or per language. But before Hugo `0.33` you could not configure it for parts of your site. You could set it manually for the relevant pages in front matter -- which is how it was done in Jekyll -- but that would be hard to manage, especially when you start to introduce translations. So, in [Hugo 0.33](https://gohugo.io/news/0.33-relnotes/) I added support for _ugly URLs_ per section and also `url` set in front matter for list pages (`https://letsencrypt.org/blog/`).
+
+The lessons learned from this also lead to [disableLanguages](/content-management/multilingual/#disable-a-language) in Hugo `0.34` (a way to turn off languages during translation). And I also registered [this issue](https://github.com/gohugoio/hugo/issues/4463). Once fixed it will make it easier to handle partially translated sites.
+
+
+[^1]: The work on getting the content translated is in progress.

docs/content/en/showcase/linode/bio.md

@@ -0,0 +1,4 @@
+
+**Linode** is a cloud hosting provider that offers high performance SSD Linux servers for your infrastructure needs.
+
+**Hugo** offers the documentation team incredible performance as we scale and continue providing quality Linux tutorials.

docs/content/en/showcase/linode/index.md

@@ -0,0 +1,21 @@
+---
+
+title: Linode Docs
+
+date: 2018-02-12
+
+description: "Showcase: \"Hugo allows us to build thousands of pages in seconds.\""
+
+siteURL: https://linode.com/docs/
+
+siteSource: https://github.com/linode/docs
+
+---
+
+The documentation team at Linode has been writing guides since 2009, with the goal of helping new and experienced Linux users find the best tools and get the most out of their systems.
+
+As our library grew into thousands of guides, we needed a fast static site generator with intuitive templating and the flexibility to extend Markdown without constantly writing HTML and CSS.
+
+Hugo solved a lot of our growing pains with features like shortcodes, customizable URLs, LiveReload, and more. We have already brought our site build time down from minutes to just a few seconds, and we are excited to see what future developments in Hugo will bring.
+
+Thank you to all the [Hugo contributors](https://github.com/gohugoio/hugo/graphs/contributors) and  especially [@bep](https://github.com/bep) for helping us with the adoption of Hugo.

docs/content/en/showcase/pace-revenue-management/bio.md

@@ -0,0 +1,4 @@
+
+Pace was started in 2016 to give hotels the super-power to always have the right price.
+
+We've been using **Hugo+Gulp** from the very beginning and the workflow is proving to scale incredibly well with us as we grow the team and business.

docs/content/en/showcase/pace-revenue-management/index.md

@@ -0,0 +1,28 @@
+---
+
+title: Pace Revenue Management
+
+date: 2018-02-08
+
+description: "Showcase: \"When we came across Hugo we were blown away.\""
+
+siteURL: https://www.paceup.com/
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+
+---
+
+From the beginning, at Pace, we were focused on solving customer needs and didn't want to over-engineer our marketing or sales. At the same time we didn't want to lock ourselves into a Wordpress, Squarespace or the like.
+
+The ideal was a fast, simple, static site builder. When we came across Hugo we were blown away. Being a European company we wanted to be multi-lingual from the get-go and allow multiple team-members to collaborate and own their content. We also felt that a tech-company in 2018 should be capable of hosting its own blog in a simple way.
+
+Here was Hugo, that allowed us to completely separate content from layout. Our sales-team edit a markdown-file, the engineers commit and off we go -- immediately deployable or pre-viewable.
+
+The only other way to have all that Hugo offers is to go down the full rabbit-hole of building your own server-side React or some such. Possibly Jekyll but again very complex to work with. The alternatives come with too much work for what should be quite simple.
+
+**Hugo + Gulp + Netlify for the win! Don't over engineer your web presence!**
+
+Huge thanks to [@bep](https://github.com/bep) and [community](https://discourse.gohugo.io/) for Hugo.

docs/content/en/showcase/quiply-employee-communications-app/bio.md

@@ -0,0 +1,4 @@
+**Quiply** is an employee communications app enabling mobile collaboration across an entire organization.
+Our customers get their own branded app enabling them to communicate fast and effectively with all employees, also non-desk and shift workers. 
+
+As the Quiply app's build process is based on **Gulp**, we have started to build our company and product website using **Gulp + Hugo** which is super-fast and gives us exactly the flexibility we need.

docs/content/en/showcase/quiply-employee-communications-app/index.md

@@ -0,0 +1,29 @@
+---
+
+# A suitable title for this article.
+title: Quiply Employee Communications App
+
+# Set this to the current date.
+date: 2018-02-13
+
+description: "\"It became immediately clear that we'd use Hugo going forward as it compiles super-fast, is intuitive to use and offers all the features we need.\""
+
+# The URL to the site on the internet.
+siteURL: https://www.quiply.com
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+# siteSource: https://github.com/gohugoio/hugoDocs
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[Sebastian Schirmer](mailto:sebastian.schirmer@quiply.com), Quiply Co-Founder"
+
+---
+
+With the launch of our Employee Communications app Quiply we created a very simple and static one-page website to showcase our product.
+
+As our customer base and demand for marketing and communication started to grow, we needed a solution to easily grow and extend the contents of our web presence. As we do not have the need to serve dynamic content, we decided to use a static site generator. Amongst a couple of others, we tried Hugo and it became immediately clear that we'd use Hugo going forward as it compiles super-fast, is intuitive to use and offers all the features we need.  
+
+Our website which we launched a couple of weeks ago is still growing and new content is being added constantly. By using Hugo, this can be easily done by content authors writing markdown files without always having to touch HTML or CSS code. It is available in German only for the time being, an English version is in the works.
+
+Huge thanks to everyone involved in making Hugo a success.

docs/content/en/showcase/small-multiples/bio.md

@@ -0,0 +1,3 @@
+
+Small Multiples is a multidisciplinary team of data specialists, designers and developers that help people make the best use of their data, a journey that starts from strategy, to concepts, mock-ups, prototypes, design, and development.
+

docs/content/en/showcase/small-multiples/index.md

@@ -0,0 +1,47 @@
+---
+
+title: Small Multiples 
+date: 2018-02-28
+description: "\"Hugo has excellent support and integration with Netlify and we were immediately blown away by how fast it was.\""
+siteURL: https://smallmultiples.com.au/
+byline: "[Small Multiples](https://smallmultiples.com.au/)"
+draft: true
+---
+
+Previously we had built and hosted our website with SquareSpace. Although SquareSpace was adequate for quickly showcasing our work, we felt it didn’t reflect our technical capabilities and the types of products we build for our clients.
+
+For many client applications, static front-end sites provide fast, scalable solutions that can easily connect with any back-end service, API or static data. We wanted to use the same processes and infrastructure that we use to host and deploy many of our products, so we felt that building a static site was the right solution for our website.
+
+Netlify is a hosting and deployment service that we use for many products. Our developers really like it because it has strong integration with GitHub and it works with the build tools we use such as Yarn and Webpack. It creates a production build every time we commit to our GitHub repository. This means we can share and preview every change internally or with clients.
+
+Application development has become increasingly complex and there is a strong motivation to simplify this process by avoiding complicated backends in favour of applications that consume static data and APIs (a JAMstack).
+
+Libraries like React make this easy, but we also wanted something that was server rendered. This led us to look at React based tools for static site generation such as GatsbyJS. We liked GatsbyJS, but in the end, we didn’t choose it due to the lack of availability of a simple CMS driven data source.
+
+For this, we considered Contentful. Contentful is a beautifully designed application. It’s basically a headless CMS, but it’s not specifically designed for websites and it becomes quite expensive at a commercial level. Their free tier is possibly a good option for personal sites especially with Gatsby. We also evaluated prose.io. This is a free service for editing markdown files in a GitHub repository. It works well, but it’s quite basic and didn’t provide the editing experience we were looking for.
+
+At the same time, we started exploring Hugo. Hugo is a static site generator similar to Jekyll, but it’s written in Go. It has excellent support and integration with Netlify and we were immediately blown away by how fast it was.
+
+We had been closely following the redevelopment of the Smashing Magazine website. We knew this was being powered by Hugo and Netlify and this showed us that Hugo could work for a large scale sites.
+
+The deciding factor, however, was the availability of CMS options that integrate well with Hugo. Netlify has an open source project called NetlifyCMS and there are also hosted services like Forestry.io. These both provide a CMS with an editing interface for markdown files and images. There is no database, instead, changes are committed directly back into the GitHub repository.
+
+In the end, we chose Hugo on Netlify, with Forestry as our CMS. The site is built and redeployed immediately with Netlify watching for changes to the GitHub repository.
+
+Was this the right choice? For us, yes, but we learnt a few things along the way.
+
+The Hugo templating language was very powerful, although also frustrating at times. The queries used to filter list pages are concise but difficult to read. Although it’s easy to get started, Hugo can have a significant learning curve as you try to do more complicated things.
+
+Hugo has particular expectations when it comes to CMS concepts like tags, categories, RSS, related content and menus. Some parts of our initial design did not match perfectly with how these work in Hugo. It took some time to figure out how to make things work the way we wanted without losing all the benefits of structured content.
+
+There were a few teething issues. We picked some relatively new technologies and as a result, we encountered some bugs. We were forced to find some workarounds and logged some issues with Hugo during the course of development. Most of these were fixed and features were added with releases happening frequently over the time we were working on the project. This can be exciting but also frustrating. We can see Hugo is developing in the right direction.
+
+NetlifyCMS was also very new when we first looked at it and this is partly why we opted for Forestry. Forestry is an excellent choice for an out-of-the-box CMS and it needs very little code configuration. It provided a better editing experience for non-technical users. I would still say this is true, but it also provides fewer options for customisation when compared with NetlifyCMS.
+
+Fortunately, the site is more portable now than it was, or would have been with a dynamic CMS like WordPress, or a fully hosted service like SquareSpace. It should be comparatively easy to swap the publishing functions from Forestry to NetlifyCMS or to change the templates. No part of the pipe-line is tightly coupled, the hosting, the CMS and the templates and the build process can all be updated independently, without changing anything else.
+
+We have complete control over the design and mark-up produced. This means we can implement a better responsive design and have a stronger focus on accessibility and performance.
+
+These technology choices gave us a good performance baseline. It was important to implement a site that took advantage of this. As a data visualisation agency, it can be difficult to optimise for performance with a small bundle size, while also aiming for high-quality visuals and working with large datasets. This meant we spent a lot of time optimising assets making sure there was little blocking the critical path for faster rendering and lazy-load images and videos.
+
+The end result is a high performance site. We think this could have been achieved with GatsbyJS, Hugo or any another static site generator. However, what was important was the decision to use static infrastructure for speed, security, flexibility and hopefully a better ongoing development experience. If you are looking at choosing a static site generator or wondering whether a static is the right choice for you, we hope this has helped.

docs/content/en/showcase/stackimpact/bio.md

@@ -0,0 +1,4 @@
+
+**StackImpact** is a production-grade performance profiler for production and development environments.
+
+The [stackimpact.com](https://stackimpact.com/) website is built with awesome Hugo. Grunt is used for CSS minification and bundling.

docs/content/en/showcase/stackimpact/index.md

@@ -0,0 +1,21 @@
+---
+
+title: StackImpact
+
+date: 2018-02-20
+
+description: "\"Hugo is a perfect choice for a product website.\""
+
+siteURL: https://stackimpact.com/
+
+---
+
+After gradually handing over the control of our website to WordPress plugins, we realized that we needed to act.
+
+Static web sites have natural advantages such as security, performance and content versioning (e.g. with Git). Static site generators such as Hugo made static websites cool again. Importantly, the best practices of software development (e.g. peer reviews, multi-stage deployments, rollbacks) can now be easily applied to websites.
+
+Besides the blog and documentation sections, our website needed custom sections with own templates. Hugo supported it beautifully.
+
+Hugo is written in Go language and uses Go templates. StackImpact is a performance profiler that has an advanced support for Go applications. Being aware of the advantages of Go in terms of speed and productivity, this was another strong reason for choosing Hugo.
+
+Thanks to all Hugo contributors for making such a beautiful and fast site generator!

docs/content/en/showcase/template/bio.md

@@ -0,0 +1,8 @@
+
+Add some **general info** about the site here.
+
+The site is built by:
+
+* [Person 1](https://example.com)
+* [Person 1](https://example.com)
+

docs/content/en/showcase/template/index.md

@@ -0,0 +1,49 @@
+---
+
+# A suitable title for this article.
+title: Hugo Showcase Template
+
+# Set this to the current date.
+date: 2018-02-07
+
+description: "A short description of this page."
+
+# The URL to the site on the internet.
+siteURL: https://gohugo.io/
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+siteSource: https://github.com/gohugoio/hugoDocs
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[bep](https://github.com/bep), Hugo Lead"
+
+---
+
+Have a **notable Hugo site[^1]**? We would love to feature it in this **Showcase Section**
+
+We would really appreciate if you could:
+
+1. Fork https://github.com/gohugoio/hugoDocs
+1. Create a copy of the [content/showcase/template](https://github.com/gohugoio/hugoDocs/tree/master/content/showcase/template) directory with a suitable name. If you now run `hugo server`, your site should show up in [http://localhost:1313/showcase/](http://localhost:1313/showcase/) and on the front page.
+2. Adjust the [files](#files) and write a story about your site
+3. Create a new pull request in https://github.com/gohugoio/hugoDocs/pulls
+
+**Note:** The Showcase section uses the latest bells and whistles from Hugo, [resources](/content-management/page-resources/) with [image processing](/content-management/image-processing/), so you need a reasonable up-to-date [Hugo version](https://github.com/gohugoio/hugo/releases).
+
+## Files
+
+The content of the [content/showcase/template](https://github.com/gohugoio/hugoDocs/tree/master/content/showcase/template) directory explained:
+
+index.md
+: The main content file. Fill in required front matter metadata and write your story. I does not have to be a novel. It can even be self-promotional, but it should include Hugo in some form.
+
+bio.md
+: A short summary of the website. Site credits (who built it) fits nicely here.
+
+featured-template.png
+: A reasonably sized screenshot of your website. It can be named anything, but the name must start with "featured". The sample image is `1500x750` (2:1 aspect ratio).
+
+
+
+[^1]: We want this to show Hugo in its best light, so this is not for the average Hugo blog. In most cases the answer to "Is my site [notabable](http://www.dictionary.com/browse/notable)?" will be obvious, but if in doubt, create an [issue](https://github.com/gohugoio/hugoDocs/issues) with a link and some words, and we can discuss it. But if you have a site with an interesting Hugo story or a company site where the company itself is notable, you are most welcome.