SVG Optimisation: The Basics

While the SVG format is extremely efficient in expressing 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 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 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:

• The best optimization workflow to use in Adobe Illustrator and Inkscape, including export options for Adobe Illustrator CC;

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>

This SVG file lacks the hallmarks of being heavily processed in a vector editing program: if it had, there would be even more code. We’ll deal with that possibility in a moment. For right now, there are several improvements we can make to the existing code:

• Remove the SVG version,id, xlink (if unused), x, y, width andheight, enable-background, and any namespaced attributes.

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

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