Skip to main content

Select and configure build tools based on best practices.


Today launches a new initiative called It is a website that provides web developers with an overview of the features supported by a selection of popular build tools. We created this site to help you choose the right build tool for your next project, decide whether it is worth migrating from one tool to another, or find out how to incorporate best practices into your code base and tool configuration. Tools have different areas of focus and are tailored to a different set of needs, which means that selecting and configuring tools involves compromise. With, our goal is to explain these tradeoffs and document how to follow best practices with any given build tool.

It sounds exciting? Visit to start exploring, or read on to learn more about why and how we developed this site.

On GoogleChromeLabs, we have created web applications like
Squoosh and Proxx, as well as websites such as Chrome Developer Summit 2019. As with any web development project, we usually start by discussing the infrastructure of the project, such as the hosting environment, frameworks, and our build tool settings. That infrastructure is updated as the project progresses: new plugins are added to accommodate the frameworks or techniques we adopt, or the way we write code is changed so that our build tools better understand what we are trying to achieve. Throughout this process, we have often come to realize that the tools we select end up getting in our way.

Our team is focused on providing the best web experience for users, which often results in fine tuning of how our frontend assets are assembled and delivered. For example, if a main thread script and a web worker script have shared dependencies, we would like to download the dependencies once instead of bundling them twice for each script. Some tools support this out of the box, some require significant customization effort to change the default behaviors, and for others, it is completely impossible.

This experience led us to investigate what different construction tools can and cannot do. Our hope was to create a feature checklist so that the next time we start a new project, we can evaluate and choose which tool is best suited for our project.

Our focus

How can we evaluate and compare different construction tools in one place? We approach it by writing test cases.

Our team discussed and designed test criteria that we believe represent best practices for web development. We specifically focus on how to deliver fast, responsive, and fluid user experiences, intentionally excluding testing related to developer experience to avoid measuring two unmatched results.

Once the test list was created, we went ahead and wrote a build script for each tool to check if the tool can meet the test success criteria. As an initial set, we decided to investigate webpack v4, Rollup v2, and Parcel v2. We also tested Browserify + Gulp as a large number of projects still use this setting. For a test to pass, only publicly documented functions of the tool or a plug-in for the tool can be used. After writing the initial set of tests, we work with the build tool authors to ensure that we use their tools correctly and represent them fairly.


On many teams, there are people dedicated to maintaining the building infrastructure, and other team members may never be able to make a decision when it comes to construction tools. We hope this site continues to be useful to you, too, as a way to set expectations for the tools you trust. For each test, we have included an explanation of why the test is important along with additional resources. And if you want to adopt a best practice with the tool of your choice, the test configuration in our repository contains the necessary configuration files to do so.

Can I contribute to the site?

If you think a currently missing function should be tested, please propose it in a GitHub issue to start the discussion. Our goal is to encapsulate real-world use cases, and any further testing that better evaluates these results is welcome.

If you'd like to write tests for tools that we didn't include in the starter set, we welcome that too! Please watch for more information.