Forem: Jaime Vega

Making the website "fast": optimizing the page critical rendering path.

Jaime Vega — Thu, 12 Sep 2019 20:08:14 +0000

One of the main objectives I had when I started building jvega.dev was to make sure it followed all the best practices in the industry. In a previous post, I explained how I aimed to get top-of-the-class security, and now, during the next few posts, I will explain which techniques or design decisions I have taken to make the website as fast as possible.

Before I enter into more details, let me say two things:

I am sure there is room for improvement. So if you any suggestions or you see any mistakes, please let me know. The code is all public an available in this repository.
Some of the features I am adding to the site could definitely be considered overkill. But I am using the site to learn and practices things I have learned during the last 10 years. And for self-promotion :).

From the beginning, I have tried to keep the PRPL pattern always in mind and make sure the page remains "fast". However, defining when a website is "fast" is not as easy as it might seem. Traditionally, the performance was measured using only metrics like page load time or DOMContentLoaded but these metrics are not effective for two reasons:

They are very unreliable as a page might not be fully loaded when those events are triggered.
And more importantly, these values might not match with the user experience of your visitors.

To explain the second point, let's take a look first to this comparison:

(Measured with WebPageTest.org using a Motorola G4 device)

The optimized and not-optimized version contains exactly the same amount of code and functionality. But as you can see, in the optimized version the content is progressively loaded. In the not-optimized one, even though it loads faster, it shows no progress until is fully loaded, so the perceived performance might actually be worse, as users might think that website is broken and nothing is happening.

This is the key idea behind user-centric performance metrics, make sure the user has the perception that your page loads faster.

However, measuring performance is always a hard task. But luckily, Google made Lighthouse, a tool that allows measuring the performance of any site, giving you user-centric values with just one click. It even gives you recommendations on how to improve the results.

Important!. To measure performance using Lighthouse or any other tool, make sure you use your browser in Incognito mode or use a profile with no extensions, as they can have a significant impact on the results.

My ideal goal is to keep a performance score over 80, as close as possible to 100. Now I am going to explain which process did I follow to optimize the site.

The idea is to think which content from your site is more important to your user, and try to optimize the loading of that area as much as possible (critical rendering path) to show it to the user as fast as possible. And defer the rest. To put another example, Youtube loads the video first, and the comments and other sections later.

So for my site, I made the following decision:

To optimize the critical rendering path I did the following:

Even though the site is made with ReactJS, I made the conscious decision of building the critical section in pure HTML+CSS only. In that way, I could delay loading react and related libraries for later.
I am also lazy loading the icons within the critical section.
I am using Babel to compile ES6+ to ES5, but I chose to don't use async functions in the entry point so the regenerator-runtime polyfill is not needed.

This is an extract of the code that bootstraps the page:

import 'core-js';
import './Theme.css';
import './main.css';

function loadApp() {
  import(
    /* webpackPreload: true, webpackChunkName: 'ReactApp' */ './components/App');
}

function loadCriticalPathResources() {
  Promise.all([
    import(
      /* webpackPreload: true, webpackChunkName: 'email-icon' */ '../static/icons/email.svg'
    ),
    import(
      /* webpackPreload: true, webpackChunkName: 'home-icon' */ '../static/icons/home.svg'
    ),
    import(
      /* webpackPreload: true, webpackChunkName: 'linkedin-icon' */ '../static/icons/linkedin.svg'
    ),
  ]).then(function onSvgIconsLoaded([
    { default: emailIcon },
    { default: homeIcon },
    { default: linkedinIcon },
  ]) {
    document.getElementById('emailIcon').src = emailIcon;
    document.getElementById('homeIcon').src = homeIcon;
    document.getElementById('linkedinIcon').src = linkedinIcon;

    // Continue loading with the rest of the resouces
    setTimeout(loadApp, 100);
  });
}

// Bootstrap
// Delay loading icons as are not critical for the user experience. I aim to reduce the time to first content paint.
setTimeout(loadCriticalPathResources, 20);

(Link to code)

I mentioned before that one easy way to evaluate that your site is fast is to use Lighthouse and make sure the score is over 80. But in addition, it is also a good idea to set up a performance budget for your site so, for example, check that the bundle size of your entry point and other assets do not go over a certain threshold.

A good value to set as maximum entry bundle and assets size is 170KB, and you can easily configure Webpack to break the build if you go over that value by setting the following settings:

module.exports = {
   // ...
  performance: {
    maxAssetSize: 170000,
    maxEntrypointSize: 170000,
    hints: 'error',
  }
}

I hope this gives you a few techniques you can use when building your next site/app. There are many more :). Make sure you check some of the reference sites that I list at the end of this post.

Ah! The current Lighthouse score for the site is...

The challenge of optimizing the critical rendering path and CSP

One important optimization I did not apply is to inline in the index.html the JavaScript and CSS that belongs to the critical path. This is important because reducing to the minimum the number of HTTP requests needed to load the site is very important.

Unfortunately, the Content Security Policy with the recommended values do not allow having inline <script> or <style> tags in the site. There are options you can use to allow that to happen in a secure way, but that requires the index.html and the HTTP headers to be dynamic values per request. And as I am hosting the site in Netlify and that makes it impossible. And between slightly worse performance and better security, I chose the latter. In a future post I will explain how.

Resources

I chose the wrong color palette because they were not accessible. This is how I fix that.

Jaime Vega — Sun, 01 Sep 2019 15:45:43 +0000

So when I decided to build a new website and resume, I made the decision to use the same design in both. As I wanted to start applying for jobs and the first thing it is always asked is the resume, I decided to do that first.

I got inspiration from some websites online (as I am not a designer) and I decided to keep it simple: one accent color, two shades of gray and a light color for text. So I chose these ones:

html {
  --accent-color: #5addf3;
  --page-background-color: #191919;
  --content-background-color: #525659;
  --text-color: #ffffff;
}

So this is how my resume would look like:

I know many companies still print resumes for interviews etc., so I decided to create a printer-friendly-version as well. Trying to be as environment-friendly as possible:

I know what you are thinking: how could you chose those colors, it is pretty obvious that there is no enough contrast!!! And yes, I suspected that but I didn't pay so much attention to it until I started building the website and started checking accessibility... You can do that very easily in your browser dev-tools:

Firefox web dev tools

Chrome dev tools

Yeap, too bad :(. Does Microsoft Word have any tools to check the accessibility of your document? I have no idea but maybe they should.

So I guess better late than never, so, unfortunately, I would have to make changes in the color palette and change my resume to use the new ones.

Searching on the Internet I came across this really useful website:

Grid Contrast by Eighshapes

And it really really really helped. You set the color and background colors and show you how it looks and the contrast score:

After spending some time choosing the colors I realized that I would have to extend the palette to add one additional color, as a darker blue would not work with a gray background. And I made a compromise not targetting 100% AAA contrast and settling only in AA. One of the ideas I have is to provide multiple themes for the website, so I might introduce later a high-contrast theme to hit AAA. I settled on this color palette for now:

html {
  --accent-color: #5addf3;
  --accent-backgroud-color: #0B8296;
  --page-background-color: #191919;
  --content-background-color: #525659;
  --text-color: #ffffff;
}

New colors

And...

Of course, this is just the beginning. My goal is to make sure the final website keeps the same score.

Making the website secure by adding additional HTTP headers in Netlify (and Zeit Now)

Jaime Vega — Mon, 12 Aug 2019 10:57:39 +0000

When I started thinking about building my new website, I wanted to make sure that even though its content is not sensible or private, I wanted to make sure it follows the best-in-class security practices.

In this first iteration, I didn't want to bother also managing the back-end infrastructure, so I decided to host the website in a third-party hosting provider. There are excellent options out there, but I decided to stick with Netlify for the time being, I am not using any custom feature so it would be straightforward to migrate between services.

My goal is to get the top score in the Security Headers. If you have never used this website, it is brilliant; it gives you a score and recommendations on how to improve it.

This is the score you get with the default configuration in Netlify:

Not great, isn't it? But the site informs you about what is missing and give you links to understand more:

The cool thing about Netlify is that allows you to set your custom HTTP headers effortlessly. You need to add a file named _headers with the headers.

Make sure the file ends up in your built folder if you use Webpack or any build tool.

This is the content of the _headers file for an A+ score:

/*
  Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self';
  Feature-Policy: accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';
  X-Frame-Options: DENY
  X-XSS-Protection: 1; mode=block
  Referrer-Policy: no-referrer
  X-Content-Type-Options: nosniff

And this is how I got an A+ score:

I will explain how did I come up with these values:

X-Content-Type-Options: nosniff should always be set with that value.
X-XSS-Protection: 1; mode=block this one is to provide XSS protection in older browsers that do not support the Content Security Policy (CSP) standard.
X-Frame-Options: DENY this one is also added to protect browsers that do not support the CSP standard. The value should always be set to DENY unless you are planning to show your site in an iframe on another website. This is very important to protect against Clickjack attacks.

The CSP value requires more explanation. I am not going to explain the whole CSP standard; I will focus on how do I approach setting the value.

I always start with denying any resource loading by default with:

Content-Security-Policy: default-src 'none';

And then I start adding only the necessary exceptions for the site to work. This approach is the most secure way as you don't need to fully know all the current directives available (CSP is a living standard; new directives are added regularly).

In the first iterations of this website, I only needed to be able to load scripts and images, so I add an exception for both to allow loading them only from the same domain. This means all content comes from my server and should be secure:

  Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self';

As the development of the website evolves, I will continue to add more directives. For example, at some point, I will have to allow loading styles, so I will have to change the policy to be like:

 Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self'; style-src 'self';

EDIT: There is an issue with prefetch requests. As part of CSP v3, a new directive will be introduced to define their behavior prefetch-src but it is not available in any browser, yet. But if you set default-src to none, prefetch queries are all blocked by default. Why? :(. So that gives me two options only: or don't use prefetch at all, or set the default to self... And I guess is not that bad as setting default to self is okay, but what if I have to make a prefetch to another domain, do I need to whitelist all requests to that domain?

For the Feature-Policy I followed the same approach: I disallow all the features by default, and I will start enabling them as I need them. Unfortunately, the current standard does not support denying all by default hence the length of the value.

And last but not least, I disabled the referred information Referrer-Policy as I do not need it for now. I might enable it later if I need it for Analytics purposes.

Bonus: How to add custom headers to Zeit Now.

Zeit Now also supports adding custom HTTP headers. This is the content of the now.json file to achieve the same as in Netlify:

{
  "version": 2,
  "name": "jvegadev",
  "routes": [
    {
      "src": "/.*",
      "headers": {
        "Content-Security-Policy": "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self';",
        "X-Frame-Options": "DENY",
        "X-XSS-Protection": "1; mode=block",
        "X-Content-Type-Options": "nosniff",
        "Referrer-Policy": "no-referrer",
        "Feature-Policy": "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';"
      }
    }
  ]
}

Interesting links: