You’ve spent many hours trying to improve your web performance and have got it to a good speed. What happens next? How do you ensure it remains in good shape especially if you’re working in a team with diverse backgrounds and level of coding.
\n\nI truly believe web performance shouldn’t be an item in your backlog, rather part of acceptance criteria on each story. That said, having discipline is hard when it comes to web performance. Each member of the team should be aware of dos and don’ts so that they can right code which doesn’t add a few seconds to current page load time, or user’s interactivity with the page.
\nIn order to do so, you need to constantly monitor the performance of your application and when is a better time to do it than your CI/CD pipeline or when creating a pull request to get the code merged in (it’s worth mentioning having a CI/CD pipeline is not necessary to have a high quality, well written and performing site).
\nIn addition to all of that, your site performs differently from your localhost, so you need to ensure you’re testing close to your actual environment.
\nLighthouse CI is a set of commands that make continuously running, asserting, saving, and retrieving Lighthouse results as easy as possible.
\nThis is a great tool which allows you to run audits on your code base using command line, and raise an alert when someone unintentionally downgrades the performance.
\nThere are countless metrics on which we could focus on. Some are user centric like time to interact, some are resource centric such as the size of your JavaScript or CSS files. Lighthouse CI allows us to easily focus on the size of the files. You can create two types of budgets:
\n1- Number of given resource: This will help you to for example enforce having only 3 JavaScript and 1 CSS file.\r\n2- Size of a given resource: This budget will enforce that a given resource is of certain size, e.g. only 500kb.
You’re probably wondering how does Lighthouse CI know what to measure and when to raise an alert. This **||is done via a JSON file which is usually named budget.json, but you can choose any name you prefer.
The content of this file is an array of objects representing the budgets for a path. The content will look like below if you only have one path to assert:
\n[\r\n {\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n }\r\n]Within the resourceSizes and resourceCounts arrays, you can add individual objects that specify the resourceType and its budget. The budget can be any positive integer and the resourceType can be any of the following:
| Resource type | \nDescription | \n
|---|---|
| script | \nJavaScript files | \n
| document | \nHTML documents | \n
| image | \nImages | \n
| stylesheet | \nCSS files | \n
| font | \nWebfonts | \n
| media | \nOther media | \n
| other | \nAny other resource which doesn’t match the above, e.g. data transfers over Websocket connections | \n
| third-party | \nAll resources from a third-party domain | \n
| total | \nAll resources combined | \n
For example, the following file will set a 200Kb budget for all scripts, a 500Kb for all images, and a 500Kb for all other resources. Then it sets the total network requests to be 25.
\n[\r\n {\r\n \"resourceSizes\": [\r\n {\r\n \"resourceType\": \"script\",\r\n \"budget\": 200\r\n },\r\n {\r\n \"resourceType\": \"image\",\r\n \"budget\": 500\r\n },\r\n {\r\n \"resourceType\": \"total\",\r\n \"budget\": 500\r\n }\r\n ],\r\n \"resourceCounts\": [\r\n {\r\n \"resourceType\": \"total\",\r\n \"budget\": 25\r\n }\r\n ]\r\n }\r\n]As of Lighthouse 5.3 you can add a path property to select which pages the budget should apply to. This is very handy because it allows you to have a centralised budget file for all your pages.
[\r\n {\r\n \"path\":\"/*\",\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n },\r\n {\r\n \"path\":\"/blog\",\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n },\r\n {\r\n \"path\":\"/contact\",\r\n \"resourceSizes\": [\r\n ...\r\n ],\r\n \"resourceCounts\": [\r\n ...\r\n ]\r\n }\r\n]Finding the performance budget is not an easy task since it will depend on your application’s structure and bundling style. However, you can use this useful tool called Performance Budget Calculator to have a starting point. You might have to run the tool multiple time to each to a point where you’d be happy with the result. You don’t want to be too aggressive and also too complacent either.
\nYou can install the CI locally with:
\nnpm install -g @lhci/cliIt also has a dashboard which shows you the historical runs, compares reports and store their results.
\nnpm install @lhci/serverBefore running the CI, you need to have a configuration file to tell the tool what to test and where to find the budget file (you could also pass those individually without a config file, but it’d be a pain):
\n// lighthouserc.json\r\n{\r\n \"ci\": {\r\n \"collect\": {\r\n \"numberOfRuns\": 2,\r\n \"startServerCommand\": \"yarn serve\",\r\n \"url\": \"http://localhost:8080\"\r\n },\r\n \"preset\": \"lighthouse:recommended\"\r\n }\r\n}Then you can run the tool on your local web server by first running:
\nlhci autorun --config=./lighthouserc.jsonand then:
\nlhci assert --no-lighthouserc --budgetsFile=budget.jsonAnd you will get a result similar to below based on your app’s performance:
\n2 result(s) for http://localhost:8080/\r\n\r\n × resource-summary.script.size failure for maxNumericValue assertion\r\n Keep request counts low and transfer sizes small\r\n Documentation: https://developers.google.com/web/tools/lighthouse/audits/budgets\r\n\r\n expected: <=102400\r\n found: 2416174\r\n all values: 2416174, 2416174\r\n\r\n\r\n × resource-summary.total.size failure for maxNumericValue assertion\r\n Keep request counts low and transfer sizes small\r\n Documentation: https://developers.google.com/web/tools/lighthouse/audits/budgets\r\n\r\n expected: <=512000\r\n found: 2437694\r\n all values: 2437694, 2437694\r\n\r\nAssertion failed. Exiting with status code 1.I am focusing on GitHub using actions here. But you can apply this technique to Azure DevOps, CircleCI, TeamCity, or any other tool you’re using. For this to work you will need to have a GitHub flow in your git repository defined.
This article’s focus is not to teach you how to create a workflow, but here is the bare minimum you will need to have. Create a .yaml/.yml file in the .github/workflows folder, you can name it whatever you want. I usually name them after what’s their purpose, e.g. lighthouse.yml or lhci-performance-bot.yml.
But before we get to the content of our yaml file, let’s see what we need to do on each PR:
For this to work, we need an application. So I just spun up a new Vue application using Vue CLI, then added my workflow to it and pushed it to a new GitHub repo.
\nHere is how my workflow looks like:
\nname: Lighthouse CI\r\n\r\non:\r\n pull_request:\r\n branches: [master]\r\n\r\njobs:\r\n lighthouse:\r\n runs-on: ubuntu-latest\r\n\r\n steps:\r\n - uses: actions/checkout@v2\r\n - name: Setup Node 12\r\n uses: actions/setup-node@v1\r\n with:\r\n node-version: 12.x\r\n - name: Yarn Install and Build\r\n run: |\r\n yarn\r\n yarn build\r\n \r\n - name: Waiting for 200 from the Netlify Preview\r\n uses: jakepartusch/wait-for-netlify-action@v1\r\n id: waitFor200\r\n with:\r\n site_name: \"lighthouse-ci-pr\"\r\n\r\n - name: Audit URLs using Lighthouse\r\n uses: treosh/lighthouse-ci-action@v2\r\n with:\r\n urls: |\r\n $DEPLOY_URL/\r\n $DEPLOY_URL/about\r\n runs: 3\r\n budgetPath: ./budget.json\r\n env:\r\n DEPLOY_URL: ${{ steps.waitFor200.outputs.url }}What is happening is that I am just creating an action on each PR. In this action, we need to pull down the code, install node, run yarn and yarn build to build the application, wait for Netlify to deploy our PR into a preview site, then get the URL and inject it into the next step.
I’m just using wait-for-netlify-action, but it’s not that hard to implement this part. Then we will be using the lighthouse-ci-action to run our audit on the paths we have specified.
Notice I am not using a Lighthouse configuration file in this workflow because it’s not needed. You can pass the parameters directly to the action like I’ve done above. I am just auditing the home and about pages since I’ve only got these two pages.
\nYou can pass as many URL’s to this as you like, but if there are many of the, it makes more sense to add the config file back.
\n\n\n💡 Remember to setup Netlify for your site and set it to create a deployment for every PR. Then get the site id and pass it to the
\nwait-for-netlify-actionaction.
Pro tip: When you setup your Vue CLI generated application which is using Vue Router, the non default routes won’t work if the user types them in the browser URL bar and hits enter. That’s because that route is handled on the client side and server doesn’t know about it. To fix that you need to add a URL rewrite rule to return your index.html for all legitimate routes.
In case of Netlify, just create a file named _redirects inside your public and add the following line to it.
/* /index.html 200I created a branch and pushed it up. Then created a PR and voila, the action kicked in and failed, since I have a large image on the about page.
\n