While the SVG format is extremely efficient in storing illustrations, vector files can become just as bloated as their bitmap kin. SVG code is often riddled with unnecessary elements, attributes, and spaces, while editors such as Adobe Illustrator and Inkscape add even more to the file with custom namespaced tags.
There are an increasing number of automated processes for optimizing SVG files, but those tools can sometimes go too far (or not far enough) in optimising the file, and in some cases – especially simple illustrations – it may be quicker to edit the file by hand. It’s also a best practice to approach the creation of a vector illustration in a tool like Illustrator or Inkscape with the goal of achieving optimization in SVG. Finally, it’s good to know just what’s going on and why in an SVG optimization tool, and where an automated process might go wrong.
Because of the many ways SVG files may be generated, I’ll use several articles to discuss the SVG optimization process:
- This article, which introduces the concepts and discusses hand-editing SVG code for optimization;
- Optimizing SVG files server-side
- The best optimization workflow to use in Adobe Illustrator and Inkscape, including export options for Adobe Illustrator CC;
- Finally, a guide to SVG optimization tools and resources.
Optimising by Hand
Let’s take a typical simple uncompressed SVG file to start (extra points have been removed from the paths for brevity):
<?xml version="1.0" encoding="utf-8"?> <!-- Generator: Adobe Illustrator 16.0.4, SVG Export Plug-In . SVG Version: 6.00 Build 0) --> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="612px" height="502.174px" viewBox="0 65.326 612 502.174" enable-background="new 0 65.326 612 502.174" xml:space="preserve"> <g> <g> <ellipse id="shading" fill="#C6C6C6" cx="283.5" cy="487.5" rx="259" ry="80"/> <path id="bird" d="M210.333, 65.331C104.367,66.105-12.349, 150.637, 1.056, 276.449c4.303, 40.393, 18.533, 63.704… fill=”#000000"/> </g> </g> </svg>
There are several improvements we can make to the existing code:
- Remove any unnecessary comments
- Delete the xml prolog and doctype
- Remove the SVG
enable-background, and any namespaced attributes.
- Remove any unneeded groups
- Simplify colors to hex shortcuts
- Remove extra spaces and carriage returns from the code
Following all of these steps except for the last one, in order to keep the changes clear, the SVG code becomes:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 65 612 502"> <ellipse fill="#C6C6C6" cx="283" cy="487" rx="259" ry="80"/> <path d="M210.333, 65.331C104.367, 66.105-12.349, 150.637, 1.056,276.449c4.303, 40.393,18.533, 63.704,52.171, 79.03 c36.307” … fill=”#000"/> </svg>
These changes make several assumptions:
heightof the SVG illustration will be determined by CSS on the webpage.
xlinkis not being used (ie, there are no linked elements).
- Groups are not being used for any particular purpose: there are no transforms moving collections of objects, for example.
You’ll also notice that I’ve cleaned up the
viewBox values and the position of the ellipse, rounding to the nearest whole number. SVG can be extremely precise, detailing the position of vector points to several decimal places… but when you’re measuring in pixels, decimal points don’t make a lot of sense.
We could make similar changes to the points on the path, but that’s usually too arduous a routine to go through by hand, and one that is open to error. I’ll discuss cleaning up complex vector information with automated processes in subsequent articles.
Technically, we could also remove the
Removing Custom Code
As a general rule, XML namespaced code in an SVG file is solely for the use of an editor, and can be safely removed from the file for the purposes of display. In Inkscape, these will commonly be
inkscape namespaced attributes:
While you can easily remove a few of these added attributes by hand, a file that has been heavily edited in a vector illustration application will be rife with them, forcing another approach, which will be covered in a future article.
Backup Your Work!
Just as with bitmap images, you should retain a fully namespaced copy of the SVG file in an originals folder, as the extra information allows the appropriate application greater control over the code during the editing process. It’s entirely possible to work backwards from an optimized SVG file in an editor, but why give yourself the extra work?
Quality Control & Validation
Ultimately, the only quality control question you need to worry about is “does the optimized file display in the browser?” That, of course, is very easy to check: just throw the file into a browser window. It’s also nice to know that the code validates: SVG code can be validated just like any other, and doing so is a useful final step before turning to optimization of SVG on the client and server.
Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.