The following is a guest post by Jeremy Wagner, a web developer, author, and speaker living in the Twin Cities. He’s got a new book on web performance. Here we’re going to dig into a brand new CSS feature, that once it percolates through the browser ecosystem, will be great for performance.
If you’re a regular reader here at CSS-Tricks, chances are good that you’re familiar with using web fonts. You may even know a few useful tricks to control how fonts load, but have you used the CSS font-display property?
The font-display property in CSS is newly available in Blink-based browser. It gives us the same power found in browser features such as the Font Loading API and third party scripts such as Bram Stein’s Font Face Observer. The key difference, though, is that this capability is also now a CSS feature.
If this is new to you, no sweat. Let’s first talk a bit about default font loading behavior in browsers.
Font Loading in the Browser
Browsers are carefully crafted programs that do a lot under the hood that we may not suspect. Font loading falls under that category. When a browser loads a font, text that is styled to use that typeface is hidden until the font is loaded. This is known as the “Flash of Invisible Text,” or FOIT.
The FOIT Effect in Action
This loading behavior is there to save us from seeing unstyled text, but it can have repercussions for users on slow connections. By default, most browsers will hide text for up to three seconds until displaying fallback text while waiting for a font to load. Other browsers such as Safari will wait even longer, or even indefinitely, leaving some users with text that never renders.
The way we mitigate this problem currently is by using a JavaScript-based solution (like Font Face Observer) to track when fonts are loaded. We style the document using system fonts first. When we can detect that custom fonts are loaded via JavaScript, we add a CSS class to the document that then applies our custom fonts. This approach has been covered before. For example, assume you have a page that uses Open Sans Regular for all
tags. By default, you specify this rule:
p {
font-family: "Arial", "Helvetica", sans-serif;
}
As the font loads, either Arial or Helvetica (depending on the fonts available on your system) will display first. When we’ve verified that Open Sans Regular has loaded using JavaScript, we then apply a class of fonts-loaded to the tag, which will apply Open Sans to the
tag via this CSS:
.fonts-loaded p {
font-family: "Open Sans Regular";
}
These solutions work, but they can be rather unwieldy. That’s where the new font-display CSS property comes in.
Getting Acquainted with font-display
font-display is a new CSS property that is available as an experimental feature that first shipped in Chrome 49 and is now also in Opera and Opera for Android. Using it, we can control how fonts display in much the same way that we can with JavaScript-based solutions, only now through a convenient CSS one-liner!
font-display is used inside of a @font-face declaration for your custom fonts. This property accepts a number of values:
auto: The default value. The typical browser font loading behavior will take place, which is to hide typefaces that use custom fonts, and then display the affected text when fonts finish loading.
swap: The fallback text is shown immediately until the custom font loads. In most cases, this is what we’re after. JavaScript-driven font loading solutions almost always aim to emulate this setting.
fallback: This is sort of a compromise between auto and swap. There will be a short period of time (100ms according to Google) that text styled with custom fonts will be invisible. The unstyled text will then appear (if the custom font hasn’t already loaded by this point.) Once the font loads, the text is styled appropriately.
optional: Operates exactly like fallback in that the affected text will initially be invisible for a short period of time, and then transition to a fallback font. The similarities end there, though. The optional setting gives the browser freedom to decide whether or not a font should even be used, and this behavior hinges on the user’s connection speed. On slow connections, you can expect that custom fonts may not load at all if this setting is used.
Now that we know what values font-display accepts, we can apply it to a @font-face rule. Here’s an example of using the swap value in a @font-face declaration for Open Sans Regular:
Of course, we’re abbreviating the font face set in this example by only using a WOFF2 file, but I’m going for brevity, here. In this instance, we’re using the swap option for font-display, which yields a loading behavior like you see in the image below:
The font-display property’s swap value in action.
When we control font loading in JavaScript, this is the behavior we’re after. We want to make sure that the text is visible by default, then apply the custom font after it has been downloaded.
What constitutes “fallback text”, though? When you specify a font-family for an element, you do so with a comma-separated list of fonts. The fallback is whatever system font that’s next in line after the custom font:
p {
font-family: "Open Sans Regular", "Helvetica", "Arial", sans-serif;
}
In this example font stack, the custom font is Open Sans Regular, and the system fonts are Helvetica and Arial. When font-display: swap; is used, the initial font that’s displayed is the first system font in the font stack. When the custom font has loaded, it will kick in and replace the system font that was initially displayed. Using the other font-display values of fallback and optional rely on the system font fallbacks in the stack before deciding what to do with the custom font.
Most of the time you’ll want to use swap.
If you don’t know which option to use, then go with swap. Not only does it provide an optimal balance between custom fonts and accessibility of content, it provides the same font loading behavior that we’ve relied on JavaScript for. If you have fonts on the page that you’d like to have load, but could ultimately do without, consider going with fallback or optional when using font-display.
What if font-display isn’t supported?
The only failing of font-display is that support for it isn’t very wide yet. Therefore, you have two choices concerning its use:
You can just use font-display and that’s that. If other browsers don’t support it, they’re not going to get the benefits it provides. This isn’t necessarily bad in that it doesn’t break anything, but it could leave users of non-Blink browsers out in the cold.
You can detect support for font-display and provide an alternative. If time and resources allow, this is what you should do.
If decide to go with option 2, you’ll need a way to detect support for font-display. Fortunately for you, doing so is a simple task:
if ("fontDisplay" in document.body.style === false) {
/* JavaScript font loading logic goes here. */
}
It’s the perfect fallback. From here, we can decide what we want to do, whether it means falling back to a third party script like Font Face Observer, or to the native font loading API available in Firefox, Chrome and Opera:
if ("fontDisplay" in document.body.style === false) {
if ("fonts" in document) {
document.fonts.load("1em Open Sans Regular");
document.fonts.ready.then(function(fontFaceSet) {
document.documentElement.className += " fonts-loaded";
}
}
}
Note from editor: See comments here about feature detection. Might need to do this differently to get more accurate cross browser compatibility results.
Here we go the usual route, and let the font loading API handle the transition for us. Once the API knows that a font has loaded, we can apply a class of fonts-loaded to the tag. With this class applied, we can then write CSS that allows a progressive application of the custom typeface:
p {
font-family: "Helvetica", "Arial", sans-serif;
}
.fonts-loaded p {
font-family: "Open Sans Regular";
}
Obviously, we’d prefer to use a CSS one-liner like font-display to do all of this stuff for us, but at least we have the ability to fall back to another solution if need be. As time marches on, we can expect that this solution, like the font loading API, will find purchase in other browsers.
What About Third Party Font Providers?
If you embed fonts using a third party service like Google Fonts or TypeKit, there’s not much you can do. The font-display property must be used inside of a @font-face declaration. Because you don’t control the CSS that the font provider serves, you can’t control the presence of the font-display property in that instance, much less the value that’s passed to it.
It is likely, though, that as time goes on, these providers will modify the CSS they serve to include a font-display property, or allow it as a configurable option when you retrieve an embed code on their service.
Either way, font-display is a welcome addition to the web typography landscape. It greatly simplifies what is otherwise an unwieldy sort of task in JavaScript. If you’re using Chrome, go to `chrome://flags/#enable-experimental-web-platform-features` and enable Experimental Web Platform Features and try out font-display for yourself!
Flat design has lost its lustre, and designers are now looking to pack their designs with texture, color, and pattern. So if you want to add a bit of punch to your design, look no further than this massive backgrounds bundle.
The files are fantastic for all kinds of use, from flyers, posters, and leaflets, to websites, apps, and banners.
Split into 19 different thematic sets the bundle covers styles ranging from watercolor, to grunge, to deep space. The files are almost all 300dpi, and resolutions range from 2560x1600px to 6000x4000px making them perfect for retina screens.
The bundle even comes with an extended license that means you can use these files on unlimited personal and commercial projects.
The regular retail price of this bundle is $300, but for a limited time you can download all 1600+ files for just $17, that’s 94% off!
Tim Brown with a new (metaphorical) term to describe a value that can fluctuate between two set values:
In canal and river navigation, a lock is a device used for raising and lowering vessels between stretches of water that are at different levels. That’s exactly what our formula accomplishes. Our formula is a CSS calc “lock”.
To fluctuate between a 1.3em and 1.5em line-height depending on the screen width:
Packaging, of course is created to protect the products inside, it’s there to inform the customer of the product and act as a means of promotion of the brand, but design enthusiasts know that packaging has a secondary dimension: to create a thing of beauty that upholds a brand’s identity and engages the audience their
There is a lot to learn this week. It starts with non-technical things like going for a walk to refresh your mind and finishes with how to prevent reverse XSS attacks in forms.
But it doesn’t matter whether you learn how to build self-contained web components using the new specification or to maximize the efficiency of your Angular 2 app or just how you can write less code. What matters is that you keep asking questions and that you try to get better and smarter at your craft.
The months of sweat and tears have passed and the stakeholders have finally signed off. Your new website design is about to go live – but how do you announce a new website launch? How do you get people to care about a new website? How do you get the most traffic and conversion you can out of a new website launch?
1. Send out a Press Release
First of all, target local business publications and anyone who you feel would be interested in the new site. Then move on to utilizing the press release process as a link-building exercise. If you write up a professional press release and use a resource like Press Release Jet to get the press release spread far and wide for the purpose of gaining links back to the site.
Unless you’re a very big company, serious news sources won’t make a big deal out of your launch but it doesn’t mean you can’t use the opportunity to get on some cool sites and possibly promote it there. Press Release Jet and other services distribute your press release to the press release section of local news stations websites around the company so you can even promote those articles once they get published – and they do get published on very credible sites that can make you and your company look good. Just make sure your press release takes an angle that would be interesting to your prime demographic and isn’t just navel-gazing.
2. Schedule a couple posts for every social media account you have
Use the post scheduling tool Buffer or Hootsuite to set up well-written posts on all your social accounts, but make sure you have them set for the hard launch, not the soft launch. Let’s be real, the first day any website launches there are usually some tweaks that need to be made and things that are getting squared away. I generally suggest waiting a week to really make the big announcement. But at that point, announce it 2 or 3 times (especially on high volume platforms like Twitter), and include an image of your website in all its glory or even a gif of someone scrolling through the site showing it’s best features. Here’s an example of clothing store Maurice’s showcasing their new WordPress blog developed by Minneapolis Web Design with a gif in a tweet.
3. Emphasize new features and promote a tweet and Facebook post.
If there are new features that your customers or clients will love, take a little video of someone using them and showing the feature in action and promote it in a Facebook post or tweet. Not everyone is going to intuitively know to go check every nook and cranny of your site and find why it’s so cool, so you might need to give a nudge or two to let them know you’re trying to serve them better. Promoted posts and tweets are a great way to get the information about new features out there more quickly.
4. Create a blog post about what’s changed and any refocusing you’ve done on the site.
This one is a no-brainer. You just spent a ton of time working on a site to better showcase your products or services and now it’s time to share why the new site is better. It’s also a good idea to do a write-up because people really do search “Company Name Website Redesign” in search engines hoping to find out what’s been changed and why. In a recent re-launch people were landing on the post from 2 years before when the last iteration was launched, so we did a write-up really quickly and redirected the traffic that was coming to the old post to the new post – as it was clear that’s what they were looking for.
5. Send out an email telling your existing customers and fans about what’s changed.
E-mail is still one of the most visible digital marketing tactics we have in our arsenal so don’t underestimate its power.
According to Mailmunch, if you have 2,000 people in your e-mail list, 2,000 people who like your page on Facebook and 2,000 people who follow you on Twitter – on average:
435 people will see your email and open it
120 of the people who like your Facebook page will see your post
40 of the people who follow you on Twitter will see your tweet
Yes the mediums are different, but these are compelling reasons to dip into your e-mail list on a website launch.
6. Create a game around a hidden easter egg on the new site.
You can drop the word “serendipity” on the website somewhere and give a $25 gift card to anyone who finds it and sends you a screenshot. You could really hide anything you’d like, but the idea is to incentivize finding it and encourage people to explore the site your team worked hard on.
Don’t worry your easter doesn’t have to be as dope as Kanye West’s easter egg in the code of his website:
7. Edit your email signature and add “Check out our new website!”, linking to the new site.
Speaking of the effectiveness of e-mail, try the drip method by adding the announcement to your e-mail footer and every routine e-mail you send helps spread awareness. You might not feel comfortable sending every contact the announcement normally, but subtly in your email signature can let them know without being pushy.
8. Recognize that “new” is relative, and keep playing it up for a month or so.
You may be tired of your new website before it even launches (because it was a lot of work to create content for, coordinate people to complete, etc) but other people haven’t seen it yet. So don’t spend one day letting everyone know it’s launched and then give up. A couple posts on each social network, an e-mail, a press release, a blog post, and some promoted posts or ads around the launch can linger for at least a couple weeks to make sure the news of the launch is spread far and wide. At most, you can spend a month tactfully sharing the new website launch and new features on it – try to take a new angle each time you do, and people will be less likely to get tired of it.
The following is a guest post by Declan Rek, who works as a developer at De Voorhoede, a front end tech agency. A version of this article was originally published on their blog. Declan asked about republishing here, and as it is jam-packed with real world case study performance stuff, I was into it.
At De Voorhoede we try to boost front-end performance as much as possible for our clients. It is not so easy to convince every client to follow all of our performance guidelines. We try to convince them by talking to them in their own language, and explain the importance of performance for conversion or compare their performance to their main competitors.
Incidentally, we recently updated our site. Apart from doing a complete design overhaul, this was the ideal opportunity to push performance to the max. Our goal was to take control, focus on performance, be flexible for the future and make it fun to write content for our site. Here’s how we mastered front-end performance for our site. Enjoy!
Design for performance
In our projects, we have daily discussions with designers and product owners about balancing aesthetics and performance. For our own site, this was easy. We believe that a good user experience starts with delivering content as fast as possible. That means performance > aesthetics.
Good content, layout, images, and interactivity are essential for engaging your audience, but each of these elements have impact on page load time and the end-user experience. In every step, we looked at how we could get a nice user experience and design while having minimum impact on performance.
Content first
We want to serve the core content (text with the essential HTML and CSS) to our visitors as fast as possible. Every page should support the primary purpose of the content: get the message across. Enhancements, meaning JavaScript, complete CSS, web fonts, images and analytics are inferior to the core content.
Take control
After defining the standards we set for our ideal site, we concluded that we needed full control over every aspect of the site. We chose to build our own static site generator, including asset pipeline, and host it ourselves.
Static site generator
We’ve written our own static site generator in Node.js. It takes Markdown files with short JSON page meta descriptions to generate the complete site structure with all of its assets. It can also be accompanied by a HTML file for including page-specific JavaScript.
See below a simplified meta description and markdown file for a blog post, used to generate the actual HTML.
# A case study on boosting front-end performance
At [De Voorhoede](https://www.voorhoede.nl/en/) we try to boost front-end performance...
## Design for performance
In our projects we have daily discussions...
Average bytes per page by content type for July 2016 from httparchive.org
WebP
WebP is a modern image format that provides superior lossless and lossy compression for images on the web. WebP images can be substantially smaller than images of other formats: sometimes they are up to 25% smaller than their JPEG counterpart. WebP is overlooked a lot and not often used. At the time of writing, WebP support is limited to Chrome, Opera and Android (still over 50% of our users), but we can degrade gracefully to JPG/PNG.
element
Using the picture element we can degrade gracefully from WebP to a more widely supported format like JPEG:
We use picturefill by Scott Jehl to polyfill browsers not supporting the element and to get consistent behaviour across all browsers.
We use the as a fallback for browsers not supporting the element and/or JavaScript. Using the image’s largest instance makes sure it still looks good in the fallback scenario.
Generate
While the image delivery approach was in place, we still had to figure out how to painlessly implement it. I love the picture element for what it can do, but I hate writing the snippet above. Especially if I have to include it while writing content. We don’t want to bother with generating 6 instances of every image, optimising the images and writing elements in our markdown. So we:
generate multiple instances of the original images in our build process, both in the input format (JPG, PNG) as in WebP. We use gulp responsive to do so.
minify the generated images
write in our markdown files.
use custom written Markdown renderers during the build process to compile conventional markdown image declarations to full blown elements.
SVG animations
We chose a distinct graphic style for our site, in which SVG illustrations play a major role. We did this for several reasons.
Firstly, SVG’s (vector images) tend to be smaller than bitmap images;
Secondly SVG’s are responsive by nature and scale perfectly while always staying super crisp. So no need for image generation and elements;
Last but not least we can animate and alter them by CSS! A perfect example of designing for performance. All our portfolio pages have a custom made animated SVG that is reused on the overview page. It serves as a recurring style for all our portfolio items making the design consistent, while having very little impact on performance.
Check out this animation and how we can alter it with CSS.
Before diving in, here’s a short primer on browser behaviour regarding custom web fonts. When the browser comes across a @font-face definition in CSS that points to a font not available on the user’s computer, it will try to download this font file. While the download happens, most browsers don’t display the text using this font. At all. This phenomenon is called the “Flash of Invisible Text” or FOIT. If you know what to look for, you will find it almost everywhere on the web. And if you ask me, it is bad for the end-user experience. It delays the user in reaching their core goal: reading the content.
We can however force the browser to change its behaviour into a “Flash of Unstyled Content” or FOUT. We tell the browser to use an ubiquitous font at first, like Arial or Georgia. Once the custom web font is downloaded it will replace the standard font and re-render all text. If the custom font fails to load, the content is still perfectly readable. While some might consider this a fallback, we see custom fonts as an enhancement. Even without it, the site looks fine and works 100%.
On the left a blogpost with the custom web font, on the right a blogpost with our “fallback” font.
Using custom web fonts can benefit the user experience, as long as you optimise and serve them responsibly.
Font subsetting
Subsetting is by far the quickest win in improving webfont performance. I would recommend it to every web developer using custom fonts. You can go all out with subsetting if you have complete control over the content and know which characters will be displayed. But even just subsetting your font to “Western languages” will have a huge impact on file size. For example, our Noto Regular WOFF font, which is 246KB by default, drops to 31KB when subsetted to Western languages. We used the Font squirrel webfont generator which is really easy to use.
Font face observer
Font face observer by Bram Stein is an awesome helper script for checking whether fonts are loaded. It is agnostic as to how you load your fonts, be it via a webfont service or hosting them yourself. After the font face observer script notifies us that all custom web fonts are loaded, we add a fonts-loaded class to the element. We style our pages accordingly:
We also set a cookie to remember that all fonts are loaded, and therefore live in the browser’s cache. We use this cookie for repeating views, which I will explain a bit later.
In the near future we probably do not need Bram Stein’s JavaScript to get this behaviour. The CSS Working Group has proposed a new @font-face descriptor (called font-display), where the property value controls how a downloadable font renders before it is fully loaded. The CSS statement font-display: swap; would give us the same behaviour as the approach above. on the font-display property.
Lazy load JS and CSS
Generally speaking we have an approach of loading in assets as soon as possible. We eliminate render blocking requests and optimise for the first view, leveraging the browser cache for repeated views.
Lazy load JS
By design, we do not have a lot of JavaScript in our site. For what we do have, and what we intend to use in the future, we developed a JavaScript workflow.
JavaScript in the blocks rendering, and we don’t want that. JavaScript should only enhance the user experience; it is not critical for our visitors. The easy way to fix the render blocking JavaScript is to place the script in the tail of your web page. The downside is that it will only start downloading the script after the complete HTML is downloaded.
An alternative could be to add the script to the head and defer the script execution by adding the defer attribute to the tag. This makes the script non-blocking as the browser downloads it almost immediately, without executing the code until the page is loaded.
There is just one thing left, we don’t use libraries like jQuery and thus our JavaScript depends on vanilla JavaScript features. We only want to load JavaScript in browsers supporting these features (i.e. mustard cutting). The end result looks like this:
<script>
// Mustard Cutting
if ('querySelector' in document && 'addEventListener' in window) {
document.write('<script src="index.js" defer></script>');
}
</script>
We place this little inline script in the head of our page detecting whether the vanilla JavaScript document.querySelector and window.addEventListener features are supported. If so, we load the script by writing the script tag directly to the page, and use the defer attribute to make it non-blocking.
Lazy load CSS
For the first view the biggest render blocking resource for our site is CSS. Browsers delay page rendering until the full CSS file referenced in the is downloaded and parsed. This behaviour is deliberate, otherwise the browser would need to recalculate layouts and repaint all the time during rendering.
To prevent CSS from render blocking, we need to asynchronously load the CSS file. We use the awesome loadCSS function by the Filament Group. It will give you a callback when the CSS file is loaded, where we set a cookie stating that the CSS is loaded. We use this cookie for repeating views, which I will explain a bit later.
There is one ‘problem’ with loading in CSS asynchronously, in that while the HTML is being rendered really fast it will look like plain HTML with no CSS applied, until the full CSS is downloaded and parsed. This is where critical CSS comes in.
Critical CSS
Critical CSS can be described as the minimum amount of blocking CSS to make a page appear recognisable for the user. We focus on ‘above the fold’ content. Obviously the location of the fold differs greatly between devices, so we make a best guess.
Manually determining this critical CSS is a time consuming process, especially during future style changes. There are several nifty scripts for generating critical CSS in your build process. We used the magnificent critical npm module by Addy Osmani.
See below our homepage rendered with critical CSS and rendered with the full CSS. Notice the fold where below the fold the page is still sort of unstyled.
On the left the homepage rendered with only critical CSS, on the right the homepage rendered with the full CSS. The red line representing the fold.
The Server
We host de Voorhoede site ourselves, because we wanted to have control over the server environment. We also wanted to experiment how we could boost performance by changing server configuration. At this time we have an Apache web server and we serve our site over HTTPS.
Configuration
To boost performance and security we did a little research on how to configure the server.
We use H5BP boilerplate Apache configuration, which is a great start for improving performance and security for your Apache web server. They have configurations for other server environments as well.
We turned on GZIP for most of our HTML, CSS and JavaScript. We set caching headers neatly for all our resources. Read about that below in the file level caching section.
HTTPS
Serving your site over HTTPS can have a performance impact for your site. The performance penalty is mainly from setting up the SSL handshake, introducing a lot of latency. But — as always — we can do something about that!
HTTP Strict Transport Security is a HTTP header that lets the server tell the browser that it should only be communicated with using HTTPS. This way it prevents HTTP requests from being redirected to HTTPS. All attempts to access the site using HTTP should automatically be converted. That saves us a roundtrip!
TLS false start allows the client to start sending encrypted data immediately after the first TLS roundtrip. This optimization reduces handshake overhead for new TLS connections to one roundtrip. Once the client knows the encryption key it can begin transmitting application data. The rest of the handshake is spent confirming that nobody has tampered with the handshake records, and can be done in parallel.
TLS session resumption saves us another roudtrip by making sure that if the browser and the server have communicated over TLS in the past, the browser can remember the session identifier and the next time it sets up a connection, that identifier can be reused, saving a round trip.
We don’t have a server side language, just a static Apache web server. But an Apache web server can still do server side includes (SSI) and read out cookies. By making smart use of cookies and serving HTML that is partially rewritten by Apache, we can boost front-end performance. Take this example below (our actual code is a little more complex, but boils down to the same ideas):
The Apache server side logic are the comment looking lines starting with <!-- #. Let’s look at this step by step:
$HTTP_COOKIE!=/css-loaded/ checks if no CSS cache cookie exists yet.
$HTTP_COOKIE=/.*css-loaded=([^;]+);?.*/ && ${1} != '0d82f.css' checks if the cached CSS version is not the current version.
If evaluates to true we assume this is the visitor’s first view.
For the first view we add a tag with a render blocking . We do this, because we will load in the full CSS asynchronously with JavaScript. If JavaScript would be disabled, this would not be possible. This means that as a fallback, we load CSS ‘by the numbers’, ie. in a blocking manner.
We add an inline script with functions for lazy loading the CSS, an onloadCSS callback and set cookies.
In the same script we load in the full CSS asynchronously.
In the onloadCSS callback we set a cookie with the version hash as cookie value.
After the script we add an inline stylesheet with the critical CSS. This will be render blocking, but it will be very small and prevent the page from being displayed as plain unstyled HTML.
The statement (meaning the css-loaded cookie is present) represents the visitor’s repeating views. Because we can assume to some degree that the CSS file is loaded previously we can leverage browser cache and serve the stylesheet in a blocking manner. It will be served from the cache and load almost instantly.
The same approach is used for loading in fonts asynchronously for the first view, assuming we can serve them from browser cache for repeating views.
See here our cookies used to differentiate between first and repeated views.
File level caching
Since we depend heavily on browser caching for repeating views, we need to make sure we cache properly. Ideally we want to cache assets (CSS, JS, fonts, images) forever, only invalidating the cache when a file actually changes. Cache is invalidated if the request URL is unique. We git tag our site when we release a new version, so the easiest way would be to add a query parameter to request URLs with the code base version, like `https://www.voorhoede.nl/assets/css/main.css?v=1.0.4`. But.
The disadvantage of this approach is that when we would write a new blog post (which is part of our code base, not externally stored in a CMS), cache for all of our assets would be invalidated, while no changes have been made to those assets.
While trying to level up our approach, we stumbled upon gulp-rev and gulp-rev-replace. These scripts helped us to add revisioning per file by appending a content hash to our filenames. This means the request URL only changes when the actual file has changed. Now we have per-file cache invalidation. This makes my heart go boom boom!
Result
If you’ve come this far (awesome!) you probably want to know the result. Testing how performant your site is can be done with tooling like PageSpeed Insights for very practical tips and WebPagetest for extensive network analysis. I think the best way to test your site rendering performance is by watching your page evolve while throttling your connection insanely. That means: throttle in a probably unrealistic manner. In Google Chrome you can throttle your connection (via the inspector > Network tab) and see how requests are slowly being loaded in while your page builds up.
So see here how our homepage loads on a throttled 50KB/s GPRS connection.
Network analysis for the site and how the page evolves for the first visit.
Notice how we get the first render at 2.27s on a 50KB/s GPRS network, represented by the first image from the filmstrip and the corresponding yellow line on the waterfall view. The yellow line is drawn right after the HTML has been downloaded. The HTML contains the critical CSS, making sure the page looks usable. All other blocking resources are being lazily loaded, so we can interact with the page while the rest is being downloaded. This is exactly what we wanted!
Another thing to notice is that custom fonts are never loaded on connections this slow. The font face observer automatically takes care of this, but if we wouldn’t load in fonts asynchronously you would be staring at FOIT for a while in most browsers.
The full CSS file is only loaded in after 8 seconds. Conversely, if we’d loaded the full CSS in a blocking manner instead of having critical CSS inline, we would have been staring at a white page for 8 seconds.
If you’re curious how these times compare to other websites with less of a focus on performance, go for it. Load times will go through the roof!
Testing our site against the tools mentioned earlier shows some nice results as well. PageSpeed insights gives us a 100/100 score for mobile performance, how awesome is that?!
When we look at WebPagetest we get the following result:
WebPagetest results for voorhoede.nl.
We can see that our server performs well and that the SpeedIndex for the first view is 693. This means our page is usable after 693ms on a cable connection. Looking good!
Roadmap
We are not done yet and are constantly iterating on our approach. We will focus in the near future on:
HTTP/2: It’s here and we are currently experimenting with it. A lot of things described in this article are best practices based on the limitations of HTTP/1.1. In short: HTTP/1.1 dates from 1999 when table layouts and inline styles were super awesome. HTTP/1.1 was never designed for 2.6 MB webpages with 200 requests. To alleviate our poor old protocol’s pains we concatenate JS and CSS, inline critical CSS, use data URL’s for small images, et cetera. Everything to save requests. Since HTTP/2 can run multiple requests in parallel over the same TCP connection, all this concatenation and reducing of requests might even prove to be an antipattern. We will move to HTTP/2 when we are done with running experiments.
Service Workers: This is a modern browser JavaScript API that is run in the background. It enables a lot of features that were not available for websites before, like offline support, push notifications, background sync and more. We are playing around with Service Workers, but we still need to implement it in our own site. I guarantee you, we will!
CDN: So, we wanted control and hosted the site ourselves. Yes, yes, and now we want to move to a CDN to get rid of network latency caused by the physical distance between client and server. Although our clients are mostly based in the Netherlands, we want to reach the worldwide front-end community in a way that reflects what we do best: quality, performance, and moving the web forward.
Thanks for reading! Please visit our site to see the end result. Do you have comments or questions? Let us know via Twitter. And if you enjoy building fast websites, why not join us?
A/B testing (also known as split testing) is generally used to test different elements of a website where improvement of a measurable goal can be seen. Unfortunately, A/B testing is too often overlooked by designers as a way to improve the overall design and development of a website.
A/B testing is a powerful way to really increase your conversion rate when done right. It’s important when you A/B test you take your time, have a hypothesis in place, and analyse results over a 7 to 10-day period for the best possible data collection and conclusion to which website design version is best and which one drives in more conversions.
So what are the top ways this testing method can improve your conversion rate?
1) A/B testing measures your website’s performance
While A/B testing, you’ll have the ability to analyze key metrics which give you an overall view of how your website design is currently performing, versus how it may perform with any new planned and improved potential changes. When using tools such as Google Analytics, you’ll typically have the ability to access three different basic metrics to measure the overall performance of your website design:
Basic metrics
Unique page views: measured by the number of page-views that are completed by a single individual visitor during their session on the overall website.
Page views: the number of times a single page has been viewed. This can be any page including but not limited to product pages, blog posts, contact pages etc.
Users: refers to the number of unique visitors to the website or a certain webpage.
Mobile: records the number of mobile users who are visiting the website through different mobile devices. This shows you whether you need to target the design to your mobile audience more than desktop users.
Medium/Source: shows which channels have helped in directing visitors to your website or webpages.
Location: refers to where your visitors are coming from so you can create more targeted content or advertisements.
Engaging metrics
Average time on page: shows you how engaging the website design is by giving you an average time a visitor is staying on a webpage.
Pages/Session: shows you how many pages a single user visits while they’re on the website.
New vs returning: shows you how many new or returning visitors you have, giving you indication on whether your site is engaging enough to bring visitors back.
Referral traffic: shows the amount of websites that link and share content that’s on your site.
Conversion metrics
Lead generation
Goal conversion rate: gives you the overall total of individual goal conversion rates. This is calculated by dividing both the total amount of completed goals by the number of sessions.
Goal completions: tells you how fast you’re reaching your goals and whether you need to adjust your marketing and A/B testing efforts accordingly.
Sales
Transactions: shows the percentage of revenue and how many transactions your website design is achieving.
Time to purchase: gives you an idea of the time it takes a single user to purchase from the newly designed website. This can lead over days or weeks.
Assisted conversions: gives you an indication on what was involved in assisting the final decision for the user to make a purchase.
2) A/B testing helps you spot problems on your site
A/B testing has an uncanny way of showing you which areas of your website design may be lacking or need improvement to boost overall sales. In addressing these areas, you have the ability to really improve the website design greatly while increasing conversion rates. Upon A/B testing your website design, you may find one or more of these areas lacking:
Images: unfortunately, many designers don’t use high quality images. This can really impact sales and the overall reputation of the business you’re developing for.
Calls to action (CTA): another area where many designers struggle. The idea of a call to action is to encourage people to connect through different portals and networks. Whether the conversion is a sale, subscription, or a download, you need to have an enticing and well-designed call to action to really connect and motivate visitors. Examples of good and bad calls to actions include: – Bad/Average: “Call Now”, “Sign Up Here”, “Call Today”. – Good/Great: “Join The Pride”, “Join An Exclusive Club”, “Be A Part Of The Future”.
Contact details: many designers tend to create an ordinary and sometimes sloppy contact page. Instead look into creating a contact page which features links to social media, opt-ins, inquiry forms, and the company’s phone number and address.
Navigation: website navigation can also be lacking depending on your layout and design. A/B testing the navigation will enable you to see whether you can improve your visitors onsite experience. Website navigation should be easy to navigate without confusing your visitors, provide minimal click through pages, be clearly labelled so visitors know what they’re clicking into to find what they’re looking for.
Website navigation can make a big difference whether you have a high or low bounce rate, so don’t disregard A/B testing in this area because you may just be pleasantly surprised with your ROI.
3) A/B testing allows you to experiment
A/B testing opens up an abundance of opportunities to change and analyze areas of your website design to see what people like and don’t like. Some areas testers can try include (but isn’t limited to):
Visitor flow: how your visitors reach point B from point A.
Layout: the layout of menus, button sizes, forms etc.
Text: headlines, descriptions, call to actions, and content itself.
Visual Elements: images, colors, videos, brand logo etc.
Some best practices to implement when A/B testing to increase conversion rates through a more favorable site includes:
Eliminating distractions which may be distracting visitors from reaching the end goal of a conversion. This may be navigation areas throughout the checkout process.
Focus on call to actions as some text has the ability to resonate with certain people differently over other audience members.
Be consistent when A/B testing and do one element change at a time.
A/B test with the aim to enhance the overall website’s popularity and not just individual page goals alone.
In creating a website that the audience likes, you have a higher chance of increasing the overall conversion rate. Pushing your website design changes through data analyzed from A/B testing can really help to drive home a wider audience margin.
4) It increases the marketing potential of your site
A/B testing is a great way to be able to hone in and redefine your website design into a powerful and more profitable marketing tool. With careful analysis of the data collected from split testing you can change key areas or elements of the design that can drive home the conversions you’re looking to achieve. The best ways to improve conversions is to leverage all you can from split testing, and here are some ways you can achieve this:
Target metrics: before A/B testing it’s a good idea to setup the target metrics you wish to achieve when you split test to determine the success of the test.
Feedback: try and ask your visitors for feedback through surveys and other forms. This will help you to decide on key areas of your website design that need addressing.
Choose high traffic pages: before testing random pages, to create a powerful marketing tool out of your website design you need to work on the high traffic pages first. High traffic pages are being seen by more people and tend to bring in more visitors. Generally landing pages are key pages which should be A/B tested for better data collection and analysis. Split testing landing pages enables you to: convert more sales and revenue; lower your bounce rate; unveil any pitfalls that your landing page has; increase the conversion rate; eliminate guesswork and assumptions; gain better leverage over your competition.
Graphic and web designers know the problem: projects have to be approved by the client or discussed with the rest of the team. This results in plenty of comments, change requests, and questions. CuePin provides an effective, and easy to use collaboration tool that lets you present your drafts for websites and other projects to other people very easily, while giving them the opportunity to add notes directly to the draft.
Upload a Design, Send Invitations
Working with CuePin is very simple. After registration, set up a new project and upload your drafts. Common image formats such as JPG, PNG, and BMP, as well as PDF documents are supported. Sort your images into different folders, and name them accordingly, creating a clear structure for your project.
To give customers or team members access to your project, either share it via URL, or send email invitations. If the invited people are not registered at CuePin yet, they will have to sign up first. Afterwards, all participants have the option to actively participate in the project.
Placing a Pin and Commenting in the Corresponding Place
Annotations or comments can be created directly within the draft. To do so, place a pin at any position within a design or document, and enter a comment. This way, it is evident what the annotation is referring to. This saves time and prevents misconceptions and confusion.
By the way, the username of the author is displayed for each comment. Thus, you’ll always know who wrote it.
Chat for Quick Communication
Additionally, all comments are displayed in a clear chat history, which can easily be displayed on the right border of the user interface. That’s also where you get to write general comments that don’t refer to a pin within the displayed design or document.
Chat History for Real-Time Communication
The chat also allows for real-time communication with all participants. This makes exchanging ideas very easy. The chat history tells you who wrote a comment at what time. If a comment refers to a pin placed on an image, this will also be displayed.
Save Progress Via Versioning
Another of CuePin’s feature is the option to keep a version history of designs and documents. Especially in the outline stage, there will be a lot of refined designs that need to be discussed with the rest of the team. To do so, simply upload the refined image files or PDF documents, and allow the other participants to place annotations.
However, previous files are not overwritten. Thanks to the integrated version control, all previous versions are available as well. This makes it easy to trace back how a design or document has evolved. Discarded ideas are not lost, but can be accessed again at any time. In the course of a design process, it’s not uncommon that you’ll realize that a previously discarded idea was not that bad after all.
Simple and Clear Controls
Overall, CuePin impresses with its clear interface, and its simple controls. The amount of new comments is still displayed when you hide the chat history. You’ll also receive information on the amount of new comments via the page’s favicon. Now you can visit other websites in the browser, while still being informed about news on your project at CuePin.
Clear Project Management and the Option to Share it With Others
Your designs and documents are presented very generously, and obviously, they are the main focus. For detailed outlines, there’s the option to zoom in using a virtual magnifiying glass. CuePin allows for the display of items in maximum size. Then, your designs will fill the entire browser window.
Those that use CuePin to work on multiple projects at once will also like the Approve feature. This lets you mark all finished projects. An accordingly concise notification will tell all other team members that the project is completed.
Now, you and all others will always stay on track as to which projects are closed, as well as which ones are still being worked on.
Conclusion and Costs
A free 30-day trial of the full version of CuePin is available. That means that you get to send out invitations, and work with others on a project. However, for long-term work with the service, it is required to book a paid plan.
The plans and prices are very clear. There are three plans which allow you to set up five, 20, or 50 projects, respectively. The costs are either ten, 30, or 60 Dollars a month, depending on the plan. The amount of team members, as well as the amount of files that you can upload, is unlimited. As a paying subscriber of the service, you will also receive unlimited support via email.
CuePin makes collaborative work a lot easier. If you have already tried to discuss designs or documents using a simple chat, you’ll know that this often takes longer than necessary, and leads to misunderstandings quite easily.
The CuePin collaboration tool does a good job at combining options to present, versionize, and comment on drafts. The flexible price range attracts freelancers with a low amount of projects, as well as larger agencies.
Positioning itself in the world of web design and development, Sketch is a perfect pick for designers and techies looking to speed up the design workflow. A well-acknowledged name in the web design industry, Sketch is constantly attracting designers with it’s features. Overview With the latest released versions, Sketch 2 and 3 which bring
