SVG Graphs Redundant Markup? Reference It With <use>

Rendering a dashboard full of SVG charts often means repeating the same groups of <rect>, <line> and <text> elements for every graph. A page displaying 50 graphs can easily balloon to nearly 6,000 DOM nodes.

That scale of markup creates real problems:

  • Large DOM trees increase memory usage, slow down style calculations and make layout reflows more expensive.
  • The client-side file size grows unnecessarily.
  • Lighthouse penalizes both performance and SEO scores.
  • Repeated code hurts maintainability, even when a templating system is in place.
  • Adding more graphs only compounds the issue.

SVG provides a mechanism for exactly this situation. The <use> element clones nodes from elsewhere in the SVG document and renders them wherever the reference appears. Rather than redeclaring the same footer lines and labels for every graph instance, define that group once and reference it repeatedly.

Getting Started With <defs> and <use>

The first step is moving shared markup, such as a graph footer group, into a hidden <svg> element. Because the element should not be rendered directly, place the group inside <defs>. Objects defined within <defs> are not drawn until they are explicitly referenced.

Place this definition in a global location, like a page header, so it is available wherever it is needed:

<!--
  ⚠️ Notice how we visually hide the SVG containing the reference graphic with display: none;
  This is to prevent it from occupying empty space on our page. The graphic will work just fine and we will be able to reference it from elsewhere on our page
-->
<svg
  xmlns="http://www.w3.org/2000/svg"
  version="1.1"
  width="500"
  height="200"
  viewBox="0 0 500 200"
  style="display: none;"
>
  <!--
    By wrapping our reference graphic in a <defs> tag we will make sure it does not get rendered here, only when it's referenced
-->
  <defs>
    <g id="graph-footer">
      <!-- Left side labels -->
      <text x="10" y="40" fill="white">400k</text>
      <text x="10" y="60" fill="white">300k</text>
      <text x="10" y="80" fill="white">200k</text>
      <!-- Footer labels -->
      <text x="10" y="190" fill="white">01</text>
      <text x="30" y="190" fill="white">11</text>
      <text x="50" y="190" fill="white">21</text>
      <!-- Footer lines -->
      <line x1="2" y1="195" x2="2" y2="200" stroke="white" strokeWidth="1" />
      <line x1="4" y1="195" x2="2" y2="200" stroke="white" strokeWidth="1" />
      <line x1="6" y1="195" x2="2" y2="200" stroke="white" strokeWidth="1" />
      <line x1="8" y1="195" x2="2" y2="200" stroke="white" strokeWidth="1" />
      <!-- Rest of the footer lines... -->
    </g>
  </defs>
</svg>

Notice the ID assigned to the group — graph-footer. This ID is the hook that <use> will target.

Each individual graph's SVG can then reference that definition instead of duplicating the markup. The resulting code for a chart instance becomes far cleaner:

<svg
  xmlns="http://www.w3.org/2000/svg"
  version="1.1"
  width="500"
  height="200"
  viewBox="0 0 500 200"
>
  <!--
    📊 Render our graph bars as boxes to visualise our data.
    This part is different for each graph, since each of them displays different sets of data.
  -->
  <g class="graph-data">
    <rect x="10" y="20" width="10" height="80" fill="#e74c3c" />
    <rect x="30" y="20" width="10" height="30" fill="#16a085" />
    <rect x="50" y="20" width="10" height="44" fill="#16a085" />
    <rect x="70" y="20" width="10" height="110" fill="#e74c3c" />
    <!-- Render the rest of the graph boxes ... -->
  </g>

  <!--
    Render our graph footer lines and labels.
  -->
  <use xlink:href="graph-footer" x="0" y="0" />
</svg>

Less Markup, Same Visual Output

The visual result remains unchanged while the DOM stays lean. Instead of every graph containing its own copy of the footer's DOM nodes, the browser handles a single declaration and clones it on demand.

This approach is similar to geometry instancing in graphics programming: declare the geometry once, then reuse it while independently controlling position, scale, rotation and colors per instance.

The benefits go beyond performance. Cutting out large blocks of repetitive markup improves the developer experience when it comes to maintaining charts, as changes to shared components are made once rather than across dozens of copies.