Displaying just one pie chart on a corporate site—such as a breakdown of sales by business unit or survey response ratios—is a common client request. Yet time and again when taking over existing sites, we find full-fledged charting libraries like Chart.js or ApexCharts loaded solely for this "single chart." Transporting tens of kilobytes to over 100 KB of JavaScript on initial page load just for one static pie chart delays mobile rendering and penalizes Lighthouse scores.
If a pie chart needs to update dynamically based on live data or display rich interactive tooltips, a library is the right choice. However, if all you need is to display static breakdown ratios with fixed values, you can render it using pure CSS conic-gradient(). This article outlines how to use CSS pie charts in client development as a tool for lightweight, robust data visualization, and examines from a production perspective where CSS is enough versus when you should hand off to a library.
Why defaulting to charting libraries becomes technical debt
The reflex of immediately installing a library the moment a chart is requested comes back to haunt projects in three ways.
First is bundle size. General-purpose charting libraries are feature-heavy—supporting line, bar, and scatter plots—meaning you ship the entire suite for a single pie chart. Even when code-split and loaded lazily, chart rendering cannot execute until that bundle arrives.
Second is version upgrade maintenance. The moment you introduce a library, it becomes an ongoing maintenance dependency. Major version bumps bring API breaking changes, creating a situation where a single chart incurs yearly maintenance costs. After delivering a client project, that solitary chart continues to bloat maintenance estimates.
Third is rendering flicker. Because drawing to a canvas via JavaScript executes after HTML is displayed, the chart appears with a noticeable delay. A static breakdown ratio should ideally be visible from the very first frame.
Rendering with conic-gradient() adds zero JavaScript, introduces no bundle bloat, and displays the chart the instant HTML renders. Using new CSS features as tools to "lighten pages by shifting behavior to declarations" is a direct extension of the strategy discussed in our article on creating JS-free animations with CSS offset-path.
Basics of rendering pie charts with conic-gradient
conic-gradient() creates a color gradient rotated around a center point. By specifying sharp angles without color blending, the gradient transforms into clean, solid sectors—in other words, a pie chart.
For example, to create a three-part breakdown of 40%, 35%, and 25%, you write it like this:
.pie {
width: 200px;
aspect-ratio: 1; /* 正円を保つ */
border-radius: 50%; /* 角を落として円にする */
background: conic-gradient(
#176B87 0 40%, /* 0%から40%まで */
#64CCC5 40% 75%, /* 40%から75%まで（=35%ぶん） */
#DAFFFB 75% 100% /* 残り25% */
);
}The key point is to write each segment's start and end percentages side by side. Setting the previous color's end percentage to match the next color's start percentage creates clean, sharp division lines. When ratios change, simply update these numbers—no image regeneration, no JavaScript recalculation.
To hollow out the center for a donut chart, you can either overlay a smaller circle matching the background color or mask out the center with mask. Using mask preserves the cutout effect even over transparent backgrounds.
.donut {
/* .pie と同じ conic-gradient を指定したうえで */
mask: radial-gradient(circle, transparent 55%, #000 56%);
}Where CSS suffices and where to hand off to libraries
The decision criteria is simple: "Is the chart static or dynamic?" Categorizing charts encountered in client development along this axis yields the following:
| Chart characteristics | Recommended approach | Rationale |
|---|---|---|
| Fixed breakdown ratios (sales mix, survey percentages) | CSS conic-gradient | No JavaScript needed for static visuals |
| Displaying details on hover | CSS + minimal JavaScript | Render in CSS, decorate with JavaScript |
| Dynamic values, multi-series data, zooming / linked legends | Charting library | CSS breaks down |
In short: use CSS for "static charts" and libraries for "interactive charts." Client projects predominantly call for the former—static breakdown ratios displayed in company profiles or case studies. Implementing those with heavy libraries saddles you with all three forms of technical debt mentioned above.
From an accessibility perspective, it is important to remember that charts drawn with CSS are purely visual and appear as "mere decorative elements" to screen readers. Provide the same numerical values alongside the chart as a table or text. Letting the HTML carry the actual values while CSS handles only the presentation—this separation of concerns ensures that the data visualization is communicated to assistive technologies as well. The underlying philosophy aligns with the principle of "always providing visual information in text as well," which we covered in the Practical Web Accessibility Guide.
What worked when we replaced it in client projects
On an industry association website where our company took over maintenance (keeping the association's name confidential), there was a single donut chart showing member breakdown on the top page, and a chart library of around 90 KB was being loaded across all pages solely for that chart. It was completely static, with its numbers updated only once a year after the general meeting.
We replaced this chart with about a dozen lines of conic-gradient + mask and removed the library load. We placed the numerical values in a table beside the chart and set up operations so that the CSS % matched the values in that table. As a result, the top page's JavaScript transfer size was reduced by that entire amount, and the behavior where the chart appeared with a momentary delay on initial render also vanished. Annual update tasks were reduced to simply modifying two places—the CSS % and the numbers in the table—eliminating the ongoing homework of tracking library version updates.
What worked best in this project was deciding at the outset not to use dynamic tools for things that do not move. When people hear data visualization, they instinctively reach for libraries, but if you first ask whether the chart will ever need dynamic behavior in the future, CSS is sufficient more than half the time.
Where to begin
If there is a spot on an active website where a chart library is loaded for a static breakdown, that is your prime candidate for replacement. If the values are fixed and require no hover or zoom interactions, you can produce the exact same look with a few lines of conic-gradient and zero JavaScript. By housing the numbers in an HTML table and securing both CSS styling and accessibility right there, it reaches production-ready quality.
If you are dealing with slow page loads caused by carrying heavy libraries for a single chart, annual maintenance overhead from tracking library versions, or the challenge of balancing lightweight performance with accessibility, feel free to reach out through GleamHub's contact form. We will review your current website's data visualizations, separate what can be made lightweight with CSS from what truly requires a library, and rebuild them into a lightweight, easily maintainable format.
