Part of the Intro to SVG Reading List

While the 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 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:

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 version,id, xlink (if unused), x, y, width andheight, 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:

  • The width and height of the SVG illustration will be determined by CSS on the webpage.
  • xlink is 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.

A simple optimized SVG illustration

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 id values from each object, but it’s more useful to leave them in, retaining the possibility of manipulating them with CSS and JavaScript later.

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 sodipodi and inkscape namespaced attributes: 

inkscape:label="Some label"

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 : 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.