A few months back we set out to redesign and rebuild our website. While we were still really fond of our old site — it was clean and simple — we knew that it didn’t really suit our needs any more. We found it to be too, well, inflexible. Our portfolio page displayed all our work at the same size – making it hard to promote our best work, and our blog posts had a restricted the amount of layout options.
Moving to WordPress
As part of the redesign, we were also moving platform, from our custom Ruby on Rails based content management system (CMS) to WordPress. WordPress is a great fit for us. Out of the box, you get support for all typical website content. You can create posts and pages, and organise them using categories and tags. It’s also really easy to extend and customise with custom post types and custom templates. WordPress is open source, and incredibly well supported. It is used by 29% of websites. One of the advantages that comes out of that is a really good plugin ecosystem.
Take the Yoast search engine optimisation (SEO) plugin for example. Yoast analyses your posts and gives your content readability ratings, as well as tools to help you target keywords.
Our new portfolio grid
We set the size (large 2×2, tall 1×2, wide 2×1, or regular 1×1) of the tiles in the WordPress admin. When they are displayed, the browser’s auto-layout algorithm compacts the grid, using the smaller tiles to fill in any holes. This drastically simplifies creating a great looking grid layout, while simultaneously easing the administration burden that would have traditionally come with a complex layout. Browsers that don’t support CSS Grid simply show the full grid as 1×1 tiles.
Another big focus of the redesign was the article pages. We wanted far more flexibility in terms of layout — to be able to craft interesting-looking posts that can incorporate multiple image sizes, videos, and styled pull-quotes.
While we are using large, high resolution images in places like article headers, we don’t want to drain a mobile users bandwidth or keep them waiting for images to load. To help with this, we are using two performance techniques with our images — responsive images, and lazy-loading.
Image sizes are predefined, with multiple sizes used for each image, chosen to fit the website’s layout. When an image is uploaded, WordPress generates versions of it for all of the image sizes. We then tell the browser the size of which the image is displayed, using the HTML image tag’s srcset and sizes attributes. This lets the browser choose the best image size for the user’s device.
Lazy-loading refers to only loading the images when they scroll in to view. We use the image’s dimensions to reserve the space that the image takes up. This prevents browser “reflows”, when the page shifts around because extra content has loaded, which can be especially annoying when reading an article on a mobile device.
With our new site, we are also welcoming a new font. Say goodbye to the geometric and precise Futura, and hello to the more relaxed and friendly Museo Sans.
We wanted to go with a nice and large body font size to make blog posts easily readable, and big, bold headlines. We created a typographic scale for all of our font styles. To enable our typography to work across screen sizes, we adjust the ratio used in our typographic scale up and down, relative to our base font size of 16px. This makes the difference in size between the body copy and the largest heading much smaller on an iPhone than on an iMac, but all the styles stay in tune.
Optimising font-loading performance
Web fonts are great. Apart from when you have to wait for them to load. We want to show Museo Sans as quickly as possible, but we don’t want to block our content from showing if it’s slow to load. For this reason, we are using a two-stage font loading technique. We show a system font, such as Helvetica or Arial, by default. We then load a tiny version of Museo Sans that contains only alpha-numeric characters. On a good connection this subset should load before the stylesheet, meaning the user never has to see the system font. Once the subset has loaded we then fetch the full set of web fonts including all the font weights and italics. On subsequent page loads, we skip right to showing the full web font.
To sum up, we’ve been building a great website and all that.