How we rebuilt the website

As a front-end developer at Mozilla, I end up working on big sites that have been around for a long time. There are a lot of interesting challenges when working with legacy code at a large scale, but rebuilding from scratch usually isn’t an option.

The View Source Conference website, on the other hand, is a small site. So when we decided to move away from WordPress, we had the chance to start fresh.

Here are a few highlights of the architectural decisions we made to make the site faster, more secure, and more reliable.

A Static Site

When a user requests a page from a CMS (content management system) like WordPress the server puts it together from databases and templates. This takes the server a small amount of time. When a site is built on request like this we call it a “dynamic” website.

When a user requests a page from a static site the server only has to find and serve one file. It’s faster and takes fewer resources. We used a static site generator to generate our files before transferring them to the server.

Static files are also easier to copy than dynamic sites, this means we can copy our static site to different CDNs (content delivery networks) around the world. Getting our content closer to our users is a very effective way to reduce latency which is one of the biggest hurdles to delivering a site fast.

Offline First

A service worker is JavaScript that runs in a browser but not as part of a page. The most common use for service workers is to watch network requests and respond instead of the server.

I wanted to be sure the conference attendees would have access to the event schedule, even if they didn’t have wifi. So, when a user arrives on the site, browsers that support service workers automatically cache the conference schedule.

If the user returns to the site without a network connection the service worker will reply to the request with the cached schedule.

I am very grateful for the documentation published by The Guardian, Jeremy Keith, and others who are already using Service Workers.

Mobile First

When responsive web design first became the norm, the industry standard was to serve the full desktop site to all browsers with a bunch of extra code telling mobile browsers which pieces to remove to make the simplified mobile version. With the spread of mobile came the Mobile First development approach. Mobile first delivers the content and code for the mobile version of a site first and then the larger more powerful desktop computers do the work of creating a better large screen experience.

The View Source Conf site starts as a minimal mobile-friendly version. Then media queries in CSS and media queries in JavaScript add more complicated layout instructions for larger screens.


I used inline SVGs for the logo and icons. They look crisper on retina screens and, because they’re inline, don’t require any extra assets to download. Inlining also meant that I could change the logo’s colour in our print styles. It was my first time creating accessible SVGs.

No Script

All the content and functionality on the View Source site works with JavaScript disabled. Instead of sending shims and polyfills to older browsers to make them handle newer JavaScript features, we support those browsers by telling them not to load the JavaScript at all.

This meant we could write modern JavaScript! It also simplified testing. Less capable browsers just get functional, readable content, with no chance for odd JavaScript errors.

This isn’t a new idea, it’s progressive enhancement combined with the BBC News’ “Cut the Mustard” test.


HTTPS protects the privacy and security of your users and with Let’s Encrypt it’s free. You can tell browsers to only load your site over HTTPS with the Strict-Transport-Security header.

Do Not Track

We use Google Analytics to measure site traffic and try to improve our conversion rates but we respect the privacy of users visiting with Do Not Track enabled. By detecting Do Not Track settings we can avoid serving them the Google Analytics file. If a user has not set Do Not Track but has an ad blocker installed all our code runs without requiring Google Analytics to initialize.

View Source

Hear industry leaders speak about topics like web performance, security, reliability, CSS grids and more at the View Source Conference in London October 27, 2017. See the full schedule! Or watch videos of last year’s talks.

About Stephanie Hobson

Stephanie has been coding since 1998 for websites as big and small. HTML, CSS, and JavaScript have always been her passion so her interests naturally extend to web standards, progressive enhancement, performance, analytics, and accessibility. She's currently working as front-end dev for MDN Web Docs.

More articles by Stephanie Hobson…


  1. Robert Erb

    Thanks, Stephanie. Nice article.

    October 19th, 2017 at 10:56

  2. veganaiZe

    It’s about time! Thank you for helping to lead the way to ditching these bloated CMSs, in situations like this, where they are nearly worthless and only serve to burn up resources.

    This information should go at the very top of a best practices list!

    October 19th, 2017 at 12:47

  3. nkanderson

    Just curious which static site generator you ended up using?

    Thanks, and nice write-up!

    October 27th, 2017 at 13:30

    1. Stephanie Hobson

      Thanks! We’re using Metalsmith. It worked very well but we were occasionally frustrated by the documentation. (The documentation may have changed since we build the site though).

      October 31st, 2017 at 12:53

Comments are closed for this article.