Loading states still get the same advice across the WordPress ecosystem: throw a GIF on it. I open a client site most weeks and find a 2MB transparent raster image spinning away while the actual content fights for bandwidth behind it. The user watches a blank screen, and the SVG Loaders they should be looking at are nowhere in the markup.
Pixels versus math
Vector against raster is not an aesthetic question. It is a question of what the browser has to do with the data. A raster image, whether GIF or PNG or JPG, is a grid of physical pixels, so the browser decodes every pixel of every frame. That costs network bandwidth and main-thread time. Scale one up and it goes soft, which shows immediately on a Retina display.
SVG Loaders are instructions rather than pixels. As I put it when writing about SVG CSS custom properties, a vector tells the browser how to draw the shape. There is no reason to ship a 50KB pixel map when 400 bytes of math draws the same spinner. The browser does the work and the network stays quiet.
Inlining an SVG costs zero requests
The HTTP request is the bottleneck here. Every <img src="loader.gif"> makes the browser open another connection. An SVG can be pasted straight into the HTML or the PHP template, so there is no request to make. The loader exists the moment the DOM is parsed.
<!-- The Naive Approach (Slow) -->
<img src="https://example.com/wp-content/uploads/spinner.gif" alt="Loading...">
<!-- The Professional Approach (Fast) -->
<svg class="bbioon-spinner" width="24" height="24" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
<style>
.bbioon-spinner { animation: rotate 2s linear infinite; }
@keyframes rotate { to { transform: rotate(360deg); } }
</style>
<circle cx="12" cy="12" r="10" fill="none" stroke="currentColor" stroke-width="3" stroke-dasharray="31" />
</svg>Inlining also kills the race condition where the content finishes downloading before the loading image does. That matters for animation performance, since the animation can start on the first frame instead of whenever the asset lands.
Control from CSS and JS
An SVG lives in the DOM, so the tools you already use work on it. Change the stroke color when the user prefers dark mode, or slow the animation down while the application sits in a particular state. Doing the same with a GIF means exporting a dozen versions of the file.
I once had to fix a loader that felt disconnected from the rest of a client’s brand. Using adaptive SVG symbols we built one that changed shape depending on which section of the site was active. A raster format cannot do that at all. Simpler still, CSS currentColor lets the loader inherit its parent’s text color, so it follows the theme without any extra work.
If this is eating your dev hours, I can take it over. I have been wrestling with WordPress since the 4.x days.
What vector gets you
- It stays crisp at any screen size instead of pixelating.
- The files are tiny, and inlined there is no extra network request at all.
- You can put
<title>and<desc>tags inside the SVG code for screen readers. - CSS animation runs at 60fps without the CPU cost of decoding GIF frames.
Raster loaders were the right answer in 2012. If your theme still ships them, that is a refactor worth scheduling. Best practices for SVG animations is a good sanity check that you are not bloating the code while trying to trim it.
