How It Works

Can AMP and SVGs Be Friends?

If you’re too lazy to read, the answer is “Don’t use SVGs on AMP pages.”

Spoiler: Not at the moment, no.

Warning: Fix errors on your AMP pages Warning: Fix errors on your AMP pages

On January first, I got a scary email with that subject:

Google systems have detected that some of your AMP pages do not meet our guidelines and will therefore not show in Google Search AMP-related features.

Yikes! I ran over to Google Webmaster Tools and saw I had well over 400 pages with critical issues. Happy New Year to me, right? Looking at them, most of the problems were exactly the same:

  • The tag ‘pgfref’ is disallowed.
  • The tag ‘pgf’ is disallowed.
  • The attribute ‘i:extraneous’ may not appear in tag ‘g’.
  • The attribute ‘xmlns:x’ may not appear in tag ‘svg’.
  • The tag ‘switch’ is disallowed.

Right away, I knew this was from my SVGs. On this site, I use SVGs instead of PNGs because they look crisper on retina screens and they can be colored on the fly. Basically I really like the power of SVGs. And, as far as I could tell, SVGs worked on AMP pages. I read the details on SVGs in AMP/HTML and it’s listed there, after all.

But in reading the errors and looking at my SVGs in a text editor, I quickly saw what was wrong.

Top ↑

Most SVGs have Extra Data Most SVGs have Extra Data

I use the Block Bundle from Symbolicons for my SVGs. They’re awesome, but once in a while I have to edit them and clean up some extraneous data within. Adobe Illustrator, for example, puts in a lot of junk at the top of my SVGs:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 17.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "">

But in the case of the SVG having a problem, it had … well. This:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 17.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN">
<svg version="1.1" id="Layer_1" xmlns:x="&ns_extend;" xmlns:i="&ns_ai;" xmlns:graph="&ns_graphs;"
	 xmlns="" xmlns:xlink="" x="0px" y="0px" viewBox="0 0 28 28"
	 enable-background="new 0 0 28 28" xml:space="preserve">
	<foreignObject requiredExtensions="&ns_ai;" x="0" y="0" width="1" height="1">
		<i:pgfRef  xlink:href="#adobe_illustrator_pgf">
	<g i:extraneous="self">
				<rect id="SVGID_1_" width="28" height="28"/>
			<clipPath id="SVGID_2_">
				<use xlink:href="#SVGID_1_"  overflow="visible"/>
			<path clip-path="url(#SVGID_2_)" fill="#231F20" d="M24.286,20h-6.757c-1.229,0-2.259,0.69-2.568,1.615
			<path clip-path="url(#SVGID_2_)" fill="#231F20" d="M27,16H1c-0.553,0-1,0.447-1,1c0,0.553,0.447,1,1,1h26c0.553,0,1-0.447,1-1
			<path clip-path="url(#SVGID_2_)" fill="#231F20" d="M21.699,2.046c-0.384-1.711-1.927-2.513-3.427-1.781l-1.544,0.752
			<polygon clip-path="url(#SVGID_2_)" fill="#231F20" points="23.935,11 4.066,11 3.167,15 24.833,15 			"/>
<i:pgf  id="adobe_illustrator_pgf">

I’ve truncated the code because it’s insanely long. In fact, it’s so long that with all of it, the file is 25k larger!

Let me explain. The SVG there has ‘switch’ code. The switch code is awesome because it can change what’s displayed based on what the file detects. For example if I wanted to make different text show based on the detected system language, I would do this:

    <g systemLanguage="en-UK">
        <text x="10" y="20">I say, bravo!</text>
    <g systemLanguage="en">
        <text x="10" y="20">Arright!</text>

The problem is that AMP? Doesn’t like that.

Top ↑

AMP Doesn’t Trust SVGs AMP Doesn’t Trust SVGs

AMP really doesn’t like fancy things. This makes sense. It’s meant to be faster for mobile browsers, so it’s streamlined and simplified. Fine. It wants simple SVGs. Obviously one fix here is I could clean up all my SVGs. The other one would be to do what AMP suggests and that is to whitelist attributes. Except you can’t do it. Yet.

There is a reason for this, and it’s similar to the same reason WordPress doesn’t (yet) allow SVGs to be uploaded by default. Unlike images, SVG files contain code. An user who can upload an SVG has the ability to upload code files which can be executed in the victim’s browser. Picture this. An attacker uploads an image to a forum. If the forum links to the image with <img> then the end-user’s browsers load the SVG and run the code. Yaaaaaay.

SVGs are dangerous. And to help this, AMP says SVGs with special tags are not welcome.

Top ↑

The Fix? The Fix?

Edit your SVGs or, if you’re me, ditch the images all together. I decided to go with the ditching since I wanted the pages to load fast. It’s the point of AMP after all.