Web Components Basics and Performance Benefits
Quick Summary
Modern web development is heavily driven by components, and all the major browsers support native Web Components. Using Web Components provide several benefits to the client side rendered pages. Web Components don’t need any framework, such as React, making them light weight and better on performance. Being natively supported by browsers mean the Web Components can be used in any environment, such as, vanilla JS pages, React pages, Angular pages, or any other framework powered pages, making Web Components write once share anywhere components.
In this article, I will build a card component to show the Web Components basics. By the end of this article you should be able to use simple HTML markup to render this example card component. The second half of the article goes over the performance benefits of using Web Components. Let’s get started!
Web Components
Web Components is a native browser feature. And like any other browser provided features, there is a W3C specification behind the Web Components. But Web Components are not documented in a single spec, instead it is made out of three specifications: custom element, HTML template, and shadow DOM. All the major browsers Chrome, Chromium Edge, Firefox, and Safari support all three specs. The steps below use these three specifications to make the card component.
Step 1: Define Custom Element’s HTML Structure
First define the HTML markup structure for the card component. I have given tag the name content-card and it has text and image attributes. It is a requirement for custom web component names to contain a dash in order to avoid any naming conflict with future HTML elements. The below codepen only has the HTML for the card web component. At this point the browser does not know about the custom content-card tag, but because of the resilient nature of HTML, the unknown tags are skipped and empty page is rendered.
Step 2: Create and Register Custom Element
After the markup structure, the next step is to create and register the content-card custom element. Custom element spec gives us the ability to create our own custom HTML element, using the class that extends the base HTMLElement. Here I’m connecting the content-card tag to custom element class and adding to the global CustomElementsRegistry. After this step the browser now knows the class to use to instantiate element for content-card tag.
Step 3: Populate Custom Element with HTML
After registering the custom element, the next step is to populate it’s HTML structure. For that I am going to use template. HTML template is used to declare fragments of HTML that can be cloned and inserted in the document by script. This example card component, I will use a simple structure for brevity: a div parent container with image and paragraph.
In the constructor, the template content is added to custom element’s shadow DOM. The Shadow DOM feature provides an isolated DOM to the custom element, where the main page cannot see the content within the custom element. What that means is, the JavaScript on the page cannot query or modify the content within the custom element’s DOM, the CSS on the page cannot bleed into custom element’s DOM and CSS within the custom element does not bleed out to the page.
At this point running the code and inspecting the page DOM, I see the content-card custom element with the card markup in it’s shadow root.
Step 4: Consuming the Attributes
The next step is to consume the content provided through the attributes in the content-card markup. For this, I’m going to use the connectedCallback Web Components Lifecycle method. The connectedCallback method is called when custom element is inserted into the DOM. I’m getting the content of text and image attributes and assigning to image and paragraph elements inside the shadow DOM.
Running the code now, shows the card component with image and paragraph text.
Step 5: Applying the Styles
The presence of shadow DOM takes away the concerns of page level styles bleeding into the component. There isn’t any need for BEM like naming convention to isolate component styles. I can use simple selectors to style the markup in the custom element. For this card component, I’m using one row and two column grid to position image and the paragraph. There is shadow around the card container to give it perception of depth. These styles are added to the template. With this change, the template now holds both html markup and styles.
Running the code now shows a properly styled card component.
This card component example has showcased the Web Components basic concepts. There is a lot more to Web Components, for example, component composition through slots, communicating through events, exposing theming options through CSS custom properties etc. See the resources in the related resources section to learn more about Web Components.
Performance Benefits
In the second half of this article, I will cover two case studies to help you understand the performance benefits of Web Components. For the studies I’m comparing the Web Components with React components, React being the most popular framework for client side rendered pages.
Case Study 1: Web Components vs React Components
For the first case study, I have prepared two pages, both pages have the same functionality. For the exact code, you can view the page source.
- The React-based demo page has React implementation of card component, uses JSS for CSS-in-JS solution, and there are forty card components rendered on the page.
- The Web Component demo page uses vanilla JS to implement card web component, and uses HTML card web component markup to render forty card components on the page.
Both are the simple pages with multiple instances of the card component. To understand the performance, I have run the Web Page Test on both the React page and the Web Component page. For this study I’m comparing the CPU cost for the repeat view numbers. I’m skipping over the first view numbers to eliminate any variance in CPU cost coming from JS bundles download. In the repeat view, all the JS bundles are coming from HTTP cache, and CPU cost is pure code execution. The table below shows the CPU cost for median run of repeat view for Chrome in the desktop PC.
The flame chart below shows the CPU pattern for time spent in scripting, layout and painting for both React Page and Web Component page.
For both pages, CPU time spent on layout and paint operation is almost the same. But the React page is spending 7 times more CPU time in JS compared to web component page. On React page the additional CPU cost is coming from JS bundles compilation, React’s time spent on virtual DOM comparison during its reconciliation step, JSS’s time spent to convert CSS-in-JS to CSS stylesheet and insert that into the document. Whereas the Web Component implementation does not incur the cost for any framework bundles compilation, virtual DOM reconciliation cost, or any CSS-in-JS conversion cost. Compared to the React page, the web component page with its lower CPU cost, will become interactive sooner, and can respond to use action in a faster manner.
To complete the study, below is the median run repeat view result from running Web Page Test on both the React page and Web Component page on Moto G4 phone along with flame chart for CPU pattern. A similar trend is seen between the two implementations, where layout and paint cost is almost the same, but JS in the React page takes far more CPU than the web component page.
Case Study 2: React Page with Web Components vs React Components
The second case study is trying to mimic the scenario where a team is already using React framework, and it is easier to add Web Components to an existing page rather than starting from scratch. Same as the previous study, I have prepared two pages, both pages have the same functionality. For the exact code, you can view the page source.
- The React-based demo page is same as from previous case study. To recap, page is React powered, has React implementation of card component, uses JSS for CSS-in-JS solution, and there are forty card components rendered on the page.
- The Hybrid demo page is React powered, includes React, React DOM and JSS framework scripts. But the page has vanilla JS implementation of card web component, and uses React to render forty card web components on the page.
Same as previous study, I have run Web Page Test on React page and Hybrid page. I’m comparing the repeat view CPU cost and skipping over first view to eliminate variance in CPU cost coming from bundle download. The table below shows the CPU cost for median run of repeat view for Chrome in the desktop PC.
For both pages, CPU time spent on layout and paint operation is almost the same. Even though both pages have the same framework bundles, the hybrid page is spending less CPU time in the JS. This reduction in CPU time is coming from React virtual DOM reconciliation and JSS. In the hybrid page React is spending less time in virtual DOM reconciliation, because in the render cycle, React is only comparing the top level custom element as it does not know the internal structure of a web component, which helps in short circuiting the reconciliation algorithm. For JSS, the web component has CSS in the template and does not need JSS to convert CSS-in-JS to stylesheet.
For completeness, below is the median run repeat view result from running Web Page Test on both React page and Hybrid page on Moto G4 phone. A similar trend is seen, where scripting in React page takes more CPU than hybrid page.
Performance Trend
The tables below show the combined result for the above two studies. For both PC and Phone, the Web Component Page has the best performance compared to React and Hybrid page, especially on the phone, where Web Component Page’s JS cost is about 5 times less.
Summary
Modern web development is heavily driven by components. All the major frameworks, React, Angular and others have component as a first class citizen. As the Web history shows, many features start their life in frameworks and are later adopted as a W3C standard and implemented in browsers. Same is true for components. All the major browsers have native support for Web Components. This article looked into three specs of Custom Element, Template, and Shadow DOM that make up the Web Components. The article covered the Web Components basic while building the card component.
The second half of the article looked at two case studies to show the performance benefits of the Web Components. In the performance comparisons I found Web Components have less JS CPU cost, especially on the phone. Less JS cost is good for the page interactivity, and improves page responsiveness, which results in more user engagement.
Given all the major browsers native support for Web Components, combined with good performance, developers should feel encouraged to write Web Components. Companies with many teams that use different frameworks benefits from Web Components. The UI can be written once in Web Components and used in any framework, eliminating the work duplication between the teams, and providing the design system consistency across the products. Check out my GitHub repo where I have been building the Web Components for the commonly used UI components.
I want to thank to Eric Askilsrud, Paul Roy, and Amiya Gupta for reviewing this article and providing their valuable feedback.
Related Resources
The following resources will give you more detail about Web Components features.
- “Web Components” MDN web docs
- “Building Components” Google web fundamentals
- “Web Components” Modern JavaScript tutorial
- “WebComponents.dev” Web Components playground
