If you follow this blog, you may have noticed that I've been working on a side project for the past 8 months or so. I'm really passionate about building and growing teams and I'm lucky enough to get to do this in my day job. As a result, this lead me to write a self-published book entitled Building Great Startup Teams.
One of the great things about being a web developer is that I can use this skill to build a website for the book! I don't normally get to play with cutting edge technology in my day to day job, so building this site was a good chance to put some of this into practice. I thought it would be useful to share the process I went through whilst creating buildingstartupteams.com.
The website itself is pretty simple, but I wanted it to be fun at the same time! In this article, I am going to run through the different tools and techniques that I used to build buildingstartupteams.com including Hosting, Service Workers and Material Design.
Buildingstartupteams.com is a basic website and I didn't need anything fancy to host it. I am storing the code in a Github repo, and it only made sense to use Github Pages to host the site too. I found it really easy to get started and you simply host directly from your GitHub repository - edit, push, and your changes are live. It's also absolutely free and works perfectly.
Github Pages provides a default domain name based on your project (ie. deanhume.github.io/buildingstartupteams.com), but I wanted to use a custom domain instead. The documentation provided on Github was really helpful and simply involved creating a CNAME file in the repo and pointing the DNS servers accordingly.
With this site, I knew that I wanted to use some of the powerful features of Service Workers. Due to various safety reasons, Service Workers require pages to be served over HTTPS in order to work. By default, Github pages have built-in SSL pages, which means you can easily get started with Service Workers if you are happy with the default domain name. However, I wanted to run a custom domain and this meant I'd have to find a way to get this to work. Fortunately, Cloudflare offer a free one-click SSL option for custom domains.
Setup was super easy and in just a few clicks I had SSL running against my custom domain. Using a service like Cloudflare is great because it meant I didn't need to purchase a SSL certificate and was hassle free. Another added benefit of serving the pages over HTTPS is that Google has started to favour pages served over HTTPS in their page rankings. Double whammy!
Using Material Design Lite made it easy to ensure that the site was accessible across multiple devices. If you'd like to quickly test how your site looks across multiple devices, I'd also recommend checking out Resizer from the Google Design team.
It's pretty basic, but gives you a super quick snapshot of your site across different devices.
Web Page Performance
I really care about web performance. Firstly, because it's important for our users and secondly because it's fun to make lean, faster web pages. When I approach the creation of any website, I always try to keep performance in mind. The first place I usually start is with the images on a site because according to the HTTP Archive, they make up over 60% of the weight of a web page! In order to squeeze any wasted bytes out of the images on the site and because they aren't going to change often, I used the web interface on Kraken.io to optimise the images.
Service Workers & WebP images
WebP images can be a great way to reduce the size of images served from a website. WebP is an image format that provides lossless and lossy compression for images on the web. This means that the image sizes are around 25 - 35% smaller than their original equivalent, which makes them perfect for the web. Unfortunately they are only currently supported in Chrome, Opera, Chrome for iOS & Android, and Opera Mini so you need to be selective in how you serve them.
I've previously blogged about a sneaky technique that uses Service Workers to dynamically return WebP images. If the browser doesn't support them, the Service Worker will simply serve the original image. I've used this approach on the website and it seems to be working nicely. The WebP images save the user just over 500 KB!
I've previously written about creating offline pages for a website, and I've always wanted to put it into practice on a real website. I created a simple offline page for this site that will present the user with an excerpt from the book if they don't have any connectivity.
Saving users bandwidth using the Save-data header and Service Workers
I was fortunate enough to watch a brilliant talk by Ilya Grigorik where he shared a new feature that is due to be released in Chrome that uses the save-data client hint. It's a feature that allows any users to "opt-in" to receive low bandwidth resources from the server. For example, It's ideal for users that are on a slow mobile network and simply want to see a web page without any fancy images or layout.
Because this site is hosted on Github Pages and had no real "backend" as such, I decided to work all the magic in a Service Worker. If you'd like to see this in action, please head over on the Github repo. This feature isn't fully available in Chrome yet, but you can play around with the Chrome Data Saver to achieve a similar effect. I am hoping to do a follow up post that will walk through this process step-by-step.
As always, all of the code for the site is available over at the Github repo. Please check it out and give me any feedback or questions that you might have! The great thing about using Github pages to host your code is that you can freely and openly share what you are working on - great stuff.
Oh, and check out the Building Startup Teams website - I'd love your feedback on that too!