Before we started revamping our website, we asked ourselves: What defines us better? A website that tests our visitors’ patience? Or, a website that’s lightning fast?
We don’t like slow websites, and we know no fancy loading spinner can make up for the frustration that such a website delivers. To make sure our website load fast on your device, we leveraged these 8 effective web performance techniques.
1. We Made Our Website Static
That’s right, our website is as static as they get: it’s just plain HTML.
We ditched {your favorite PHP based CMS here} for Hugo. Hugo is a fast and modern static site generator. It’s flexible, powerful and fun!
The content you see on our website (including this blog post) live as Markdown files, separate from the theme, but in the same repository. When we want, Hugo automatically processes the content and the theme and builds exactly what you see at https://furqansoftware.com.
2. We Use a Content Delivery Network (CDN)
One of the best things about serving a static website is that you can do it from almost anywhere.
Our website lives in an Amazon S3 bucket behind Amazon CloudFront. Every time you drop by our website you are being served from a server that is closer to you than you might think.
With problems of terrible latency out of the way, moving between pages on this website feels snappier than ever.
This combination saves us from choosing between the worse and the worst web hosting plans.
3. We Optimize All Our Images for the Web
Pictures may say a thousand words, but are all of those words important? All images on our website go through an optimization phase as a part of the build process.
We optimize all PNG files with this nifty tool: OptiPNG. It compresses image files to a smaller size, without losing any information.
And, all our SVG files go through SVGO. It eliminates all of those unnecessary junk left by editors in your SVG files. These unnecessary data in your SVG files can be safely removed or converted without affecting how the SVG renders on screen.
4. We Eliminate Unused CSS Rules
How many times did you use Bootstrap in your project just for that grid system, yet included the entire 140kB CSS?
To remove all unused CSS rules from our stylesheet, we put them through PurifyCSS. This neat Node.js package looks at all of your HTML and JavaScript files and eats any CSS rule that is not used on your website.
5. We Minify (Almost) Everything
If we serve something to your browser, it’s probably minified.
Indentation, whitespace, descriptive names, etc are all fine and dandy in our code editor. Believe us, we take them seriously. Ironically, we do so only to have the build process undo all our effort.
We minify HTML using HTMLMinifier, JavaScript using UglifyJS2, and CSS using cssnano. This helps reduce the size of the files significantly, making it faster for your browser to download them.
6. We Gzip Compress Response Payloads
If your response payloads are not compressed, you are potentially losing out on one of the easiest optimization opportunities.
With CloudFront, doing this is even easier. By activating its compression feature, CloudFront compresses files of certain types that fall between 1kB and 10MB in size.
Our screen.css, which is 113kB is transferred as a mere 20kB payload. That’s 80% fewer bytes for just one resource.
7. We Allow Browsers to Cache Our Site (and Then We Bust It)
Leveraging browser cache is often one of the best ways of improving site performance for returning visitors.
Most of the resources on our site are heavily cacheable. Images, JavaScript file, CSS files, etc are all set to be cacheable for up to 2 months.
However, to make sure our visitors receive fresh content when we update our site, we cache bust using fingerprints for resources. Whenever one of the resources (e.g. something in our stylesheets) changes, so does the fingerprint, causing the browser to load the resource again. You can learn more about cache busting here.
8. We Delay Loading of External Components
Since visitors navigating to your landing page usually sees the content above the fold, it is pointless to make them wait for resources that have no impact on that part.
We delay the loading of any external components as much as we can. For example, the map at the bottom of our homepage loads only when you scroll down to that section. This means we can render the homepage without having to wait for the Google Maps resources to be loaded.
No More Loading Spinners
If your site makes your visitors stare at a loading spinner, it’s not fancy, it’s slow.
As a part of this blog post, we have put together a quick Hugo boilerplate with Gulp as the build tool. You can find it on GitHub.
