In this article

• Introduction
• Installation
• FAQ
• Changelog
• Discussion

Introduction

I always wanted to implement one thing since I started the blog: a simple inclusion of Amazon items. I didn’t want to search through results that existing plugins provided. When I wrote about something like a book, I already used machine tags to identify the subject! So I found the inspiration to write my first real WordPress plugin: Amazon Machine Tags.

Here’s what it does:

1. It identifies any tag in the machine (or triple) tag form book:isbn=1234567890 or amazon:asin=1234567890. That works with native tags from WordPress 2.3 and later, Bunny’s Technorati Tags, Jerome’s Keywords, or as inline text (see below).
2. Then it gets the item information and a thumbnail image from the Amazon Web Services API. That’s the real thing including prices and such, no cheap RSS feed.

3. The item(s) are displayed in the sidebar or in a blog article with a link to the visitor’s best match (if the ip2country plugin is installed) or a default Amazon shop of your choice. See examples in the sidebar.

   The “best match” is based on the visitor’s location. If she is from one of the six countries where Amazon has shops, that locale is chosen. If he is from Europe, the preferred language is matched to either France, Germany, or UK, with UK as default. If it’s neither a locale nor Europe, amazon.com is the default. Based on your location, do you think that’s a reasonable approach?

   Note that some items, like books in any language other than English, are only available from certain locales, so a visitor from the UK might not see German books you recommend.

4. If you are an Amazon Associate for that locale, your Associate ID is included automatically.

You can edit the server-side, semantic and valid XHTML output via XSLT, change the CSS, or translate the admin interface through .po files. Actually Amazon loads the XSLT file from your server and processes it on theirs, so you shouldn’t block HTTP access to the plugin directory, and localhost doesn’t work either.

Results can be cached for anything between one second and one hour, so you don’t need to worry even when you run an extremely popular blog.

The YUI Connection Manager is included to verify the Access Key in the admin interface via REST and unobtrusive AJAX.

I hope this little piece of software serves you well and you like it.

Installation

1. Get the latest version of the plugin from the WordPress site.
2. Upload the whole amazon-machine-tags folder into the /wp-content/plugins/ directory.
3. Activate the plugin through the “Plugins” menu in WordPress.
4. Get an Amazon Web Services Access Key.
5. Create a wp-content/cache/ directory with permissions set to 755, or 777 if you create the directory as root user.
6. Put <?php AMTAP::get_items(); ?> in your sidebar and start using machine tags.
7. Edit amtap-blog.css if you like.
8. If you want to use tags in a blog article, write [amtap book:isbn=1234567890] or [amtap amazon:asin=1234567890]. Thanks to paulinepauline for that idea.

Frequently Asked Questions

Does it work in the sidebar on Pages, too?

Posts have tags, pages don’t, so it doesn’t work on those by default. But there’s a plugin called tags4page that enables tags for pages. Works like a charm.

Is there a limit of how many items can be requested?

Yes, Amazon has a limit of 10 items per request. Since they are separate requests, you can use a maximum of 10 items in the content plus a maximum of 10 in the sidebar.

Would it be possible to cache the images?

Technically it wouldn’t be a problem, but the Amazon Web Services license explicitly forbids caching of images (see 5.1.10). Sorry.

I need to a larger thumbnail (medium), but can’t seem to find a place to edit the size of the image being requested.

The image size can be edited in the XSLT. The original result is a XML file that is transformed by Amazon using your local copy of amtap-html-sidebar.xsl and amtap-html-content.xsl, respectively. Replacing every occurance of .//aws:TinyImage with .//aws:MediumImage should do the trick.

You can view the original XML when you activate the “debug” option in the admin interface so that the request string is printed as a comment in the sidebar’s source code. XSLT is a very powerful tool, and there’s a lot more in the XML, for example customer reviews.

Are all options really required?

No. The only required field is the Amazon Web Services Access Key. You can leave the others, they are set to defaults then.

Changelog

• 3.0 (2009-07-31): Added signed requests for the new Amazon authorization requirement. Updated the API version to 2009-07-01 (please note: if you use your own XSL files, you must update the version in the XML namespace URL). Updated links.
• 2.0 (2008-07-18):
  1. Added fields for editing the sidebar headline, link target, and displaying rating stars.
  2. Added an error message if the plugin is run from a private IP address space like localhost.
  3. Changed priorities for price selection, they are now: LowestNewPrice, ListPrice, first offer, LowestUsedPrice.
  4. Added support for the display of an artist name.
  5. Added rating stars.
  6. Fixed EAN numbers with a dash.
  7. Fixed cutting of titles after a period.
  8. Changed CSS and XSL files. Take care when you edited those.
• 1.1.3: Changed amtap-admin.css and amtap-admin.inc.php to make the admin interface look prettier with WordPress 2.5.
• 1.1.2: Fixed a bug in amtap.php when there are no other tags but default tags.
• 1.1.1: Fixed the sort order of inline items, a bug for returning an error message when the cache file is not writable, and added Amazon’s limit of 10 items per request.
• 1.1.0: Fixed the display of inline tags on the home page. Improved regular expression for filtering inline tags.
• 1.0.6: Fixed a bug introduced through the new default items function when there were no items to be displayed in the sidebar.
• 1.0.5: Added an option for default items on every page. Changed amtap-html-sidebar.xsl to sort items in the order of the request.
• 1.0.4: Bugfix for replacement of dollar characters in content. Also content items are now cached separately.
• 1.0.3: Fixed the display of inline tags on category pages.
• 1.0.2: Changed the plugin path from amtap to amazon-machine-tags for consistency with the file structure in the zipped file.
• 1.0.1: Bugfix for native WordPress tags.

The traditional focus of performance optimization has been on the backend, i.e. system efficiency. But comparing a number of high profile websites, the Yahoo! team found that frontend performance is responsible for 80-98% of the perceived response time. Therefore doubling the frontend performance gains more than doubling the backend performance. In case studies Yahoo! Search became 40-50% faster, the Yahoo! Mail web application gained 70-100%. Of course there are ways to increase backend performance without throwing in more hardware, but better frontend performance reduces traffic and saves resources.

Saving resources on the client side, particularly CPU usage, also pays off in speed. Event delegation is faster than a large number of event handlers. Likewise we know that reducing the number of HTTP requests through techniques like CSS sprites, sliding doors, or file aggregation increases speed. The reason is the limit of two parallel requests per host imposed by HTTP 1.1. That results in a download queue of two requests at a time, increasing the perceived response time of a page. By configuring additional host aliases for your server you can increase the number of parallel requests — but more than 2-4 also increase DNS lookups resulting in higher CPU usage and slower response times.

I wonder when Yahoo! will present us another impressive calculation how many gigawatts have been preserved by reducing CPU usage in client PCs and in their data centers, as one participant asked in the Q&A part. Energy efficient servers are the next big thing, but are there any concrete suggestions for greener programming? Is AJAX destroying the ozone layer?

Environmental issues aside, here’s the list of rules. I’ll keep it short where I have written about it in my previous article. See the examples and testcases by Steve Souders.

1. Make fewer HTTP requests: This also affects cookies. Eliminate unnecessary cookies, keep them small, set them at granular domain levels (e.g. finance.yahoo.com instead of .yahoo.com), and set an appropriate Expires date.
2. Use a content distribution network (CDN) like Akamai where your (static) content is served from distributed data centers located nearer to your client. Even if your website is not as big as Google you can profit from faster response times by using the YUI library’s own CDN.
3. Add an Expires header not just for images, but also for JavaScript and stylesheet files.
4. Enable gzip: 90%+ of browsers support compression, and gzip is better supported and compresses more than deflate. Gzip HTML files, CSS, scripts, XML, JSON — no images or PDFs.
5. Put CSS at the top, avoid @import as it loads last, even after the images!
6. Move scripts to the bottom as they block parallel downloads even across hostnames and block rendering of any code below them.
7. Avoid CSS expressions as they execute many times and cost CPU.

8. Use external JavaScript and CSS files. Inline CSS is apparently faster for a user’s start page, but not on subsequent pages. After the page has finished loading, use the time to preload scripts to speed up secondary pages.

   1. window.onload = downloadComponents;
   2. function downloadComponents() {
   3. var elem = document.createElement("script");
   4. elem.src = "http://.../file1.js";
   5. document.body.appendChild(elem);
   6. }
9. Reduce DNS lookups for the reasons stated above. Use 1-4 hosts and the keep alive setting.
10. Minify JavaScript with JSMin — inline scripts, too.
11. Avoid redirects as they are the worst form of blocking. Set Expires headers for redirects to enable caching.
12. Remove duplicate files: this is self-explanatory, but it can happen in large teams with many scripts and stylesheets.

13. Mind the ETag: Now this was something I never paid attention to. ETags are unique identifiers to distinguish files that share a URI. They are transmitted in the HTTP header. The default server setting uses the INode, the bytesize and the modification date of a file to calculate a unique ID. Unless servers in a cluster are identical, ETags differ, therefore the files are not cached. Fortunately ETags can be configured in Apache, so it should be possible to match them across different servers.

    1. FileETag MTime Size

    Note that the ETag is also relevant for RSS feeds. For example, currently the W3C talks feed is more or less unusable: some feed readers and services apparently regard the ETag, the feed is mirrored on many servers, so the same news entry from a different server is shown as new and unread multiple times every day…

14. Make AJAX cacheable and small. Some data like a user’s address book or buddy list change infrequently and should be requested via GET, cached, and set with a Last-modified timestamp and gzipped.

These are a lot of rules, and they will be published in a O’Reilly book by Steve Souders and Tenni Theurer in September 2007. Anyway, don’t be overwhelmed by their mass, instead you can start with the easy things: “harvest the low hanging fruit.” Enable caching with the Expire date setting and reduce the number of HTTP requests. You can deal with the rest later.

Finally Nate Koechley announced a Yahoo! performance tool called YSlow as a plugin for the indespensible Firebug extension. He also recommended the commercial IBM Page Detailer, and LiveHTTPHeaders to visualize what’s happening in your browser.

Matrix of supported browsers in BlueMars projects

Parsing JavaScript freezes the browser. Therefore put CSS in the head and JavaScript near to the </body> so that it is parsed when the page has been rendered.

The arch enemy of performance are HTTP requests. Many browsers still can’t handle more than two or four requests at a time. Keep the number of files down, your website will be faster.

There are several techniques with the aim to reduce the number of files:

1. “A single large file is fastest.” (Nate Koechley) That’s why Yahoo! apparently has such an amount of inline CSS. They found out browser caching is not as effective as they thought, in particular not on a user’s start page. So they deliver “inline” CSS. Actually writing inline CSS is a maintenance nightmare, but delivering CSS content inline doesn’t mean the files can’t have separate lives on the server: concatenate the files with a server side technique of your choice.

   Update: A couple of months later Nate explained that further: when your page is likely to be a user’s start page, caching plays a minor role, thus “inline” CSS is faster. Otherwise use external files, aggregate them, and make sure they are cached (see below).

2. Enforce caching. Another IE bug prevents image caching. Add the following to your .htaccess, httpd.conf or vhost.conf settings:

   1. <IfModule mod_expires.c>
   2. ExpiresActive On
   3. ExpiresByType image/jpg "access plus 1 day"
   4. ExpiresByType image/jpeg "access plus 1 day"
   5. ExpiresByType image/gif "access plus 1 day"
   6. ExpiresByType image/png "access plus 1 day"
   7. </IfModule>

3. Reduce the number of background images with techniques like CSS Sprites or Sliding Doors. Instead of four images of rounded corners you only need one and get the mouseover state for free! The green download button on mozilla.com is based on that technique. And Yahoo! uses CSS Sprites to combine a huge number of icons.

   

   Please note this approach is only for decorational background images that degrade gracefully. It’s not for img elements. Be careful when you use it for foreground images. And if text comes as a graphical representation, it can become inaccessible for screen reader users, zoom readers, or people with stylesheets switched off. Use real text instead.

   Also note changing the background-position causes IE6 to flicker, related to the caching bug above. To avoid it, simply add the following:

   1. <script type="text/javascript">
   2. try { document.execCommand( "BackgroundImageCache", false, true); } catch(e) {};
   3. </script>

4. Aggregate files. Ed Eliot wrote a nice script to merge JavaScript or CSS files, bonus respect for the advanced versioning and caching features.

   But remember the cases when it doesn’t make sense to merge CSS files: your IE bugfixes still belong in conditional comments. If you use the @import rule to filter antique browsers from getting advanced styles, you can’t drop it. And if you want to merge stylesheets for different media (e.g. print), make sure the code is enclosed in something like

   1. @media print {
   2. /* style sheet for print goes here */
   3. }

   In an updated version Ed added JSMin to strip comments and excess whitespace. JSMin works like a charm for JavaScript files. But it cuts a few space characters too much so that the syntax of CSS selectors changes therefore for now I have abandoned the idea to compress them too. See Jens Meiert’s comment below for a recommendation to minimize CSS.

   His original code requires the C version of JSMin with PHP safe_mode turned off. If you prefer a pure PHP version, get the PHP version of JSMin and my adapted version of the script.

I’m still in awe how fast one of my own websites became! Thanks to the guys at Yahoo! for the inspiration and for most of the research this article is based upon. Even JSMin was written by an employee of Yahoo! Speaking about Yahoo! employees: Chris, I hope there are still enough topics for your Vitamin article. I wanted to write about performance anyway, and to my surprise I read yesterday that you have similar plans. See ya in Paris.

“Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web.”

Nate Koechley introduced Yahoo!’s smart concept of graded browser support nine months ago. Until then we did test a lot of browsers, but all browsers were supported equal. Now came this man who suggested distinctions, a graded instead of a boolean or binary support.

• There is a blacklist of C-grade browsers. They are antiquated, but core content and functionality should work in them. Never mind the design though, as some of them do not support CSS 2. Semantics and good accessibility are more important and tested by QA.

• Then there is a whitelist of advanced (A-grade) browsers supporting modern web standards. QA tests these browsers, and bugs are handled with high priority.

• The rest of the unknown or rare browsers are X-grade. It is assumed they support modern web standards, but it would be inefficient and impossible to test them.

That’s a very pragmatic and efficient framework since it adds scalability for QA.

Almost unnoticed were two updates of the browser matrix in August and a couple of days ago where Opera 8 got replaced by Opera 9, also support for Internet Explorer 5.5, Safari 1 and Firefox 1.0 has been discontinued because they are vanishing species. Support for Firefox 2.0 has been added, while Mozilla suite has been terminated since there are virtually no differences between Firefox and Mozilla suite.

Our own matrix includes Konqueror, but otherwise it’s more or less the same as the current Yahoo! browser matrix, although we do not test rare Windows versions like Windows 98 or 2000. Here is the adapted matrix we use in our own projects. Do you think that’s a reasonable approach?

Matrix of supported browsers in BlueMars projects