Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: amp

  • How Mobile is AMP?

    How Mobile is AMP?

    There are pros and cons of using AMP, the biggest being Alex Kras’ discovery that Google is kinda stealing your mobile traffic with AMP. But since WPBeginner lays out the pros and cons really well, I’m going to skip over that and discuss something else.

    Responsive Themes

    The concept of a ‘mobile only’ theme is one I generally deride. After all, if you’re on a website in 2017, it should have been written with the concept of mobile first. Most people design a site for their computer/browser of choice, and then add in resizes for mobile. Contrasting this is the idea that you build out your website for mobile browsers first, and then go back in and add in the larger views. That is Mobile First.

    It’s an ideal, I agree, and while I love it (and Carrie Dils who made the beautiful Utility Pro Theme as a mobile first them), it can’t always be achieved. Some websites are written to be ‘apps’ and they’re intended to be used as a browser app.

    In general, I support the use of a responsive theme, be it mobile first or not. This kind of theme will react based on browser size, or operating system type. But a mobile ‘only’ theme? I dislike them a great deal. They create headaches with caching (ask anyone who’s had their cache catch the mobile page for everyone!) and they can be difficult to jump back from, if someone is perhaps on a tablet that can handle the ‘full’ site. They also double your work.

    AMP

    AMP is a project by Google. The concept is a super light, ultra-fast mobile page for your sites. AMP is fast, it’s simple, and it’s a stripped down version of your normal site. How it works is that When Google searches your site and adds it to their big giant database, they can can see “Aha, this site has AMP! I will use it for mobile!” And then, when someone surfs to your site via a Google search, Google would notice “This user is on mobile! I will show it AMP displays!”

    The downside you might have noticed is that the AMP pages only get called when you’re doing a Google search. That means if you go to a website on your phone, you get the mobile responsive site anyway. Which is what Paul (and I) think you should be doing. And right away, you might think “Hey, I should make all my mobile visitors go to AMP!” and you may come up with code like this:

    function amp_redirect() {
    	if ( wp_is_mobile() ) {
    		$url = trim(  $_SERVER['REQUEST_URI'], '/' );
    		if ( substr( $url, -3) != 'amp' ) {
    			$url = $_SERVER['REQUEST_URI'] . '/?amp';
    			wp_redirect( $url );
    			exit;
    		}
    	}
    }
    

    That looks great, doesn’t it? It’s smart enough to check if the URL ends in ‘amp’ and, if so, not redirect. Plus it uses ?amp which means if the page doesn’t have an AMP URL, it won’t fail an ugly 404 death.

    There is, however, a big problem with AMP. You end up having two sites. Paul Bakaus talks about the pitfalls of a separate mobile site, and how you should keep a responsive theme for your site, and not use AMP for Mobile. This is not a good thing in the long run.

    A RESTful Alternative

    So let’s think about this differently and not in the simple “Mobile vs Non-Mobile” way. Let’s ask ourselves the real questions. “What is this site doing?” and “How will people be using this site?” Because the crux of the matter is really how is the data from the site being consumed!

    Recently, with the advent of the REST API, WordPress has as new way for people to eat your data. Much like I’ve talked about before, using the REST API to power an Alexa app or a plugin, the REST API can be used to power mobile apps! Yes, people are running iOS apps with the REST API. This lets you display the content however you want, even audio only, and yet power it fully with WordPress.

    In a way, you’re still making two sites, the app and the theme, but… You’re not making a generic theme that fits all users. You’re making a real application that fits the specific use case.

    What’s The Answer?

    Let’s break this down.

    1) Your theme should be responsive for mobile. Period.
    2) AMP is great for Google searches.
    3) The REST API can, and should power your apps.

    That’s it. Three steps to amplifying your site.

    Oh, and please don’t use that code I showed you. It’s sad.

  • Can AMP and SVGs Be Friends?

    Can AMP and SVGs Be Friends?

    Spoiler: Not at the moment, no.

    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.

    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" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
    

    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="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 28 28"
    	 enable-background="new 0 0 28 28" xml:space="preserve">
    <switch>
    	<foreignObject requiredExtensions="&ns_ai;" x="0" y="0" width="1" height="1">
    		<i:pgfRef  xlink:href="#adobe_illustrator_pgf">
    		</i:pgfRef>
    	</foreignObject>
    	<g i:extraneous="self">
    		<g>
    			<defs>
    				<rect id="SVGID_1_" width="28" height="28"/>
    			</defs>
    			<clipPath id="SVGID_2_">
    				<use xlink:href="#SVGID_1_"  overflow="visible"/>
    			</clipPath>
    			<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
    				[...]
    				C26,20.651,25.234,20,24.286,20"/>
    			<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
    				C28,16.447,27.553,16,27,16"/>
    			<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
    				c-1.5,0.732-3.956,0.732-5.456,0L9.728,0.265c-1.5-0.732-3.042,0.07-3.427,1.781L4.29,10h19.42L21.699,2.046z"/>
    			<polygon clip-path="url(#SVGID_2_)" fill="#231F20" points="23.935,11 4.066,11 3.167,15 24.833,15 			"/>
    		</g>
    	</g>
    </switch>
    <i:pgf  id="adobe_illustrator_pgf">
    	<![CDATA[
    		eJzVfelCMsuu6H0B3gFUBGTqidGZyQkVxXlCkFb5RMAG1trf+XGf/aaq56G6qxs859y99nJBd5FUpVKpJJVUopFWO73fH/fENJ9hwqFotCqJ3dlYKofx0/DRcDifziT0KH6ZCLOFDAON9o+KHaXhjShNB+NRGb1i8csG+nX8eCz9DV92J59dcZgIxxPw4mowG4rwajr5m5n03xMqNvh5rTuDN3y2mGWFcL4slMKtU/S6O/qnO50O/[...]==	
    	]]>	
    	<![CDATA[	
    		k3D32Uw5IYV5ef6oHOpoLUjz3J9shIS0J71kk7fOSM8qidXrybCJkYaiFrTT1Zd8hYT0cOeiMLpxRiok7pKbb+enTkhD0elK40XQ0VqQMo3KyR4BaX51bSQltglI71+YxvtZGyMFHrOMdeUgsrXOHneuHJEeHHJXRPJyDztXrxgpsH2vriNF62Vzeis9zXeaCG3CPqvxe/5xyCYAqTC2stJzk1HJ24rFLEhzue/OBCMNRS1oEdKO9Pw5uiIg3evmC4011hHpy+7rpRPSUBTP6hof33xyGqskbUWep6uf4qUz0otqYudn7bvphDS5OSzvYKRIWlrHml9d/Zk/[...]==	
    	]]>	
    	<![CDATA[	
    		dcrskeHXSl9Zs0fmmNYjE7Jee2ZNHFkrryzktsCJTQbLwl96jj3t62SdzndBkZ6zVmZj/odmsSu/jxf2yKA0NKvjIcB9Ssf+PTJOGakoDW1RjwzOzrPccReQMDna5Bz1vnFCsMsxMT3HV3KOdspTbs2seai711GPaBoaZRl0udXFcxJPKCIZtFubPKyWycki94aZd+TyRXzxoTmE7OkeRUoOLV9EqEIXTPxpuxMSzTlNMLBnXp0xaNZ6N5SPvDofsesEKwkRhiqFxDMWA9GmQMXJlGHrcYdz1Lb3fX10Z2UU+XA09/[...]++foLQ
    	]]>
    </i:pgf>
    </svg>
    

    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:

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

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

    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.

    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.