Google likes fast

Suppose you just bought yourself hosting and you just installed WordPress for blogging or lightweight-CMS-purposes, how can you improve your site’s performance in that case? Easy!

1. speed up PHP: use a caching optimizer (I use APC) to significantly speed up PHP performance (don’t bother  signing up for shared hosting with a company that doesn’t offer PHP with acceleration).
2. cache dynamic output: install the “WP Super Cache” WordPress plugin. Configure and then forget about it; if you create/edit a blogpost, impacted pages are automatically removed from cache.
3. optimize CSS and JS: install the “CSS JS booster” WordPress plugin, which (amongst other things) grabs all CSS and JS from WordPress and Plugins and outputs it in one CSS- and one JS-file (some plugins, e.g. Sociable and WordPress Mobile Pack, might need tweaking of the css media-attribute though)
4. avoid calling 3rd party javascript: tracking (e.g. Google Analytics, which I removed), widgets (e.g. Twitter badges) or other 3rd party gadgets (e.g. AddToAny, which I removed) can slow down your site’s performance significantly
5. optimize images: fire up your favorite photo editor and make that image just a bit smaller, use an acceptable level of compression (I end up between 70 and 80% for JPEG’s, depending on the image) and upload to smushit.com to squeeze out the last optimization-drop (example; I used a 20KB picture from Flickr, resized it to 80%, saved it with 77% compression and smushed it to end up with a mere 6KB).

The impact of a number of these steps can be measured easily; below are the response times of my blog’s homepage (the  html including css, js and images) as measured by Pingdom Tool’s Full Page Test.

1. default Wordpress (on a Linux VPS with 320Mb RAM memory): 6.5 seconds
2. (1)  with PHP APC activated: 4.1 seconds
3. (2) with WP Super Cache: 3.1 seconds
4. (3) with CSS JS Booster: 1.3 seconds

So there you have it, from 6.5 to 1.3 seconds in only 5 easy steps! WordPress specific, but easily applicable to other platforms as well. Now go and make your site fast! And then go and make it even faster!

Possibly related twitterless twaddle:

• blog.futtta.be going mobile with WPtouch
• AddToAny removed-from-here
• Google Webmaster Tools Irony

So if you happen to have problems with the positioning of 2nd (or later) pages in iframes (due to the top part of the iframe not being visible in the ‘viewport’), just upload frameMagic.js to your webserver and add the following to the head of your html to ease your iframe-blues;

<script type="text/javascript" src="path/to/frameMagic.js"></script>

Optionally you can specify which iframes are to be treated this way (excluding the other ones) by doing

<script type="text/javascript">
var fM_conf="iFrame1,iFrame3";
</script>

You can find more information and examples on http://futtta.be/frameMagic.

Possibly related twitterless twaddle:

• 5 tips to tackle the problem with iframes
• HTTP upload MIME type hell
• AddToAny: removing the “spy” from the share-ware

1. Google loves doesn’t hate iframes done right!

Although Google is rather vague about the subject, iframes and SEO do not have to be mutually exclusive. But you will have to make sure it’s your main page that shines in search results, not the iframe-content. The main page (where the iframes are defined) has to be more then a mere placeholder for one or more iframes. Migrate as much information (titles, description and other text) from the iframe-content to your main page, which should describe what goes on in the iframe(s). Use the iframe title-property and insert alternative content between opening and closing iframe-tags. A quick example:

<h2>Calculate your mortgage rate</h2>
<p>Calculating your mortgage rate was never easier; just enter the loan-amount and the duration below!</p>
<iframe src=”http://page.url/iframe-container-page1″ …  title=”Calculate your mortgage rate here”>Your browser does not seem to handle frames properly, but you can calculate your mortgage rate <a href=”http://page.url/iframe-container-page1″>here</a></iframe>

2. Own the stage

Avoid visitors viewing the iframe-content out of the context of the main page (e.g. because they followed a link in search-results). Add javascript to the iframe-content to check if it is accessed stand-alone and redirect to the main page (or explain and provide link to the main page) if that is the case.

if(self.location==top.location) top.location.replace('http://contain.er/page-url/here');

3. Don’t draw blanks

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no? The (hackety-hack) solution; tell the browser to scroll to the top of the iframe each time a new page in it is loaded, by calling the function below (with the iframe id as parameter) when the iframe’s onLoad event fires:

<script>
var firstrun = new Object();
function frameMagic(el) {
if (typeof firstrun[el] === ‘undefined’) { firstrun[el]=true; }
else { document.getElementById(el).scrollIntoView(); }
}
</script>
<iframe id=”iframe” onLoad=”frameMagic(‘iframe’);”>

4. Your users really do need scrolling=”auto”!

Help your visitors access all iframe content no matter what configuration they’re using: don’t disable the iframe scrollbars! Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size). Instead define a reasonable iframe-width and height, make the iframe-content width flexible (fluid) and let the browser decide if a vertical scrollbar is needed.

5. Smart sizing without scrollbars

If you really really really don’t want scrollbars, if you want your iframe to adapt to the size needed by the iframe-content automatically and if you’re not afraid to experiment; there are some nifty javascript-solutions that allow the iframe-content to communicate the required height to the main page. Check out Framemanager (stand-alone, has some issues though) and the JQuery-postmessage iframe-example (which does everything in javascript, which isn’t really ideal from an accessibility point of view).

Conclusion: iframes aren’t necessarily evil (either), but you’ll have to make a small effort to render them somewhat SEO- and user-friendly.

Possibly related twitterless twaddle:

• Fix iframe-positioning problem with frameMagic.js
• 5 valuable Cufón tips
• Embedding YouTube HTML5-video with newTube

Anyway, I showed him IE8 and Firefox 3.5 (both were installed as well) and he recognized Firefox as the browser he was most familiar with. So I uninstalled Chrome, hid IE8, upgraded him to FF 3.6 and also installed the “Vacuum Places improved” and NoScript add-ons.

“Vacuum Places improved” cleans up the places sqlite database where Firefox stores bookmarks and history and which can become very big over time.  When tweaking the options (“hide icon” and “auto-vacuum every 20 browser starts”) it was a great way to invisibly tune browser performance, but it turns out Firefox 3.6 vacuums places.sqlite automatically (when  idle, every 1 to 2 months). So Pierre, if you ever read this; remind me to uninstall “Vacuum Places improved” next time!

NoScript is a whole other beast; it is a add-on for the security-conscious tech-head, which by default disables javascript, flash, java, … It’s a great add-on, but it is very disruptive and as such totally unfit for novice users. Unless you change the configuration off course, because modifying these options makes NoScript a must-have addon for both you and your grandma;

• General: check “Scripts Globally Allowed (dangerous)”
• Embeddings: uncheck the 8 “Forbid” options, check both “untrusted” and “trusted” for Clearclick protection
• Appearance: uncheck “Status bar icon”, “Status bar label” and “Contextual menu”
• Advanced/XSS: check “Sanitize cross-site suspicious requests”

Although the first option specifically claims it is dangerous to do so, these changes render NoScript into an add-on that provides a lot of extra security (protecting against clickjacking, cross-site scripting and implementing support for x-frame-options and Strict Transport Security) without bothering users with new UI-elements containing incomprehensible questions, messages or options.

Because web security is not only about protecting against threats, but also about not breaking novice users’ expectations of how your secured browser (and the web) looks and behaves.

Possibly related twitterless twaddle:

• Google inadvertently kills Talk badges with x-frame-options
• Browser enforced web application security; IE8 safest?
• Warning: your computer might be infected!

var a2a_config = a2a_config || {};
a2a_config.no_3p = 1;

These two lines of javascript, which have to be placed in front of the http://static.addtoany.com/menu/page.js script-include, should disable all current and future 3rd party tracking. I hope the web-guys from e.g. deredactie.be and standaard.be (and there are many others) implement this as soon as possible!

So now we can opt-out from having our visitors being spied upon by media6degrees, what more could one want? Well, since you’re asking, here’s a small list of things AddToAny could really should do;

• transparency; tell users that their visitors’ information will be shared with 3rd parties (in all relevant places)
• documentation: show them how to “remove the spy” on the AddToAny api page (“no_3p” isn’t there)
• ease-of-use: allow the tracking to be disabled with a simple checkbox in the WordPress and Drupal plugins

The opt-out code is a important first step and I’m sure concerns such as those voiced on the WordPress-forums will help AddToAny to further make the right decisions!

Possibly related twitterless twaddle:

• AddToAny removed-from-here
• Enhanced privacy for embedded YouTube
• Speed up your (WordPress-)site!

Sexy as a iPhone-UI mimicking webapp (based on e.g. iUI or JQTouch) might seem, it does have a number of important shortcomings:

• it is sub-optimal for the web, even on iPhones, as the context is very different (e.g. in terms of responsiveness)
• the iPhone-UI-approach does not make a lot of sense on non-iPhone high-end touch devices
• it will probably not work on mid- and lower-end phones at all

So yes, web-developers should try to build mobile sites that render on as many devices/ browsers possible, as we do on the non-mobile web. Unless you’re willing to invest in several sites for different handsets, building for one specific device is a bad choice, however good the browser might be (and Safari Mobile indeed is great).

That’s why I decided to switch from the iPhone-centric WPTouch (which I installed only 3 months ago) to “WordPress Mobile Pack” for this blog. WMP offers great mobile functionality out of the box;

It includes a mobile switcher to select themes based on the type of user that is visiting the site, a selection of mobile themes, extra widgets, device adaptation and a mobile administration panel to allow users to edit the site or write new posts when out and about.

When running the MobiReady test to assess how “mobile-ready” my blog is, I get a great score of 4.35/5 (page size being the main remaining issue). So thanks for ranting PPK!

Possibly related twitterless twaddle:

• Facebook mobile websites face-off
• HTC-dude, where’s my keyboard?
• Facebook drops iphone in favor of touch

After looking into ways to call the YouTube mp4-file from within a Video for Everybody html-block (which is not possible, Google protects raw video-files using what seems to be a session-based hash that has to be provided in the URL), I decided to take another (dirty) approach; faking it!

The solution is entirely javascript-based and is as un-elegant as it is simple; create a html-file with a script include of http://futtta.be/newTube/newTube.js and a div with “id=newTube” containing a link to a YouTube-page and the script automagically takes care of the rest. Check out http://futtta.be/newTube/ to see it in action.

The result is an embedded YouTube player which will display the HTML5-version if you’re running a browser which supports mp4/h264 playback (i.e. a recent version of Chrome or Safari) and if you enrolled in the beta. If either of these preconditions aren’t met, you’ll just see the plain old Flash-player.

Don’t get your hopes up, in reality newTube is probably pretty useless (for reasons I’ll get into in a follow-up post, when I have some time to spare that is). You’ll have to wait for someone (YouTube, Dailymotion, Vimeo, … are you listening?) to offer real embeddable html5-video (with support for both mp4/h264 and and ogg/theora).

But I did have fun creating the very first html5-capable embedded YouTube-player

Possibly related twitterless twaddle:

• Firefox 3.5 and tinyvid.tv do Ogg/Theora
• Google loves html5 (in Android 2.0)
• Bridging the gap between html5 and Gears

Enabling the “enhanced privacy” option just changes the URL in the embed code from youtube.com to youtube-nocookie.com;

<object width="560" height="340"><param name="movie" value="http://www.youtube-nocookie.com/v/FuGJfVAgiTM&hl=en_US&fs=1&rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube-nocookie.com/v/FuGJfVAgiTM&hl=en_US&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="560" height="340"></embed></object>

The change has no impact whatsoever on the user experience, so I immediately tweaked the code of the Smart YouTube Wordpress plugin on my server and I asked the developer to add the option to his plugin as well.

Yet another small step in the fight against Google’s omniscience!

Possibly related twitterless twaddle:

• Mozilla rethinking extensions with Jetpack
• Embedding YouTube HTML5-video with newTube
• Firefox 3.5 and tinyvid.tv do Ogg/Theora

Apparently the AddToAny Wordpress-plugin was initiating the call:

1. add-to-any requests http://static.addtoany.com/menu/page.js (which is rather big but gzipped & cache-able)
2. page.js in turn contains tracking (near the end of the file), by requesting an 1X1 pixel image at http://map.media6degrees.com/orbserv/hbpix?pixId=2869&curl=<encoded URL of page>
3. media6degrees then sends the pixel and … sets multiple cookies in the process
   

And what’s media6degrees business you ask? Maybe they’re just providing the add-to-any author with statistics? Well, not exactly. This is what media6degrees writes on their website: “We deliver scalable custom audiences to major marketers by utilizing the online connections of their consumers.” So by using AddToAny, you’re providing media6degrees with data about your site’s visitors, which they can use to sell targeted communication to their customers.

If visitors of small-time blogs like mine would be the only ones affected by this, the damage would be limited. But AddToAny is also implemented on large local news-outlets such as deredactie.be or De Standaard Online and no doubt on some big international sites as well. Somehow I doubt those organizations know they’re feeding their visitors to media6degrees and I bet some of them would even strongly disagree.

I’m not happy about this, that much is clear. AddToAny offers great functionality, but:

• it adds unneeded requests to my page, causing the page to finish loading later (dns-request + http-request)
• it enrolls my site visitors in a targeted communication platform without anyone knowing (or agreeing)
• none of this is communicated on the AddToAny website or on the AddToAny Wordpress plugin page

I mailed the author about this earlier this week (when i didn’t even know about media6degrees tracking cookies yet), but got no feedback up until now and I logged an issue on the wordpress.org support forum as well. And I decided to pull the plug on AddToAny off course, replacing it with sociable, making my blog render yet another millisecond faster, while at the same time protecting my visitors from this sneaky behavioral tracking by AddToAny and media6degrees.

Possibly related twitterless twaddle:

• AddToAny: removing the “spy” from the share-ware
• Enhanced privacy for embedded YouTube
• Speed up your (WordPress-)site!

Flash isn’t evil

Some people seemed all too happy to dismiss my post as being plain old Flash-bashing. Sorry to disappoint you, but I”m not saying Flash is evil or that it will (or should) disappear altogether. Next correction: I do have Flash player installed and in general I do know if a application is made in Flash or not. Heck, the web has been my job for more than 10 years now and Flash has been a point of interest for quite some time already. And yes, there indeed are innovative web applications and games that are build in Flash. That being said, I do think (because of accessibility, SEO and some more philosophical reasons) it’s best to avoid using Flash to develop a site’s core functionality if the same can be achieved with non-propriety, standard web technology.

It’s not about Flash vs HTML5

The comments on last week’s blogpost seemed to focus very much on the individual merits (or lack thereof) of HTML5, CSS3 or Canvas, as if these are islands with no history and no connections to the web mainland. This is, off course, wrong; these “new” technologies just happen to be the most recent evolutions of the core components of the rapidly evolving ecosystem that is the “open web”. Moreover, with HTML, CSS and Javascript being the brick and mortar, libraries such as JQuery, Dojo and YUI are the “prefab” building blocks of open web development, offering plug&play components to efficiently build cross-browser rich web interfaces. So the discussion is not about Flash vs HTML5, but about the choice between Flash and the powerful “open web technology stack”.

about:evolution

“The only constant is change” and that’s all the more valid on the web. Flash has an important role to play in this respect, having pushed the boundaries of  web-based UI’s for many years. But as some of the cutting-edge features that once were only available in Flash, can now be created more efficiently using non-propriety technology, there’s a shift towards the use of those open web components (e.g. the Flash carousel on National Geographic website that was shown in the Adobe video from my previous post has been replaced by a JQuery implementation).

I believe (and that’s what the previous post was about) this trend will continue in 2010 because of features of HTML5, CSS3, canvas, … becoming available to a wider audience either natively (in new browsers) or through libraries that provide cross-browser compatible implementations. And yes, I’m afraid that in my book that means Flash will become less relevant (“irrelevant” in my previous post being an obvious hyperbole).

Loose ends & examples

• The <video> codec problems Serge fears can -and should- be easily hidden from end-users (as Apple does for example). Moreover the patent-related codec-issue will, I predict, be solved in 2010 with Google acquiring On2 Technologies and putting at some (if not all) of the codecs (VP3 was the basis of Theora, VP6 is in Flash 8 Video and JavaFX) in the public domain
• <Canvas> is already in the wild and doing just fine, thanks for asking Stefan. Major webapps with great graphical UI’s such as 280slides, Mindmeister, Bespin, Google Maps and Yahoo Pipes depend on it. Cufon, JQuery visualize and Dojo GFX use it as well and yes, Canvas can be implemented cross-browser (even in IE6) thanks to the explorercanvas library (and with Microsoft actively participating in the discussions about the canvas-spec, one could expect MS to one day release a browser that has native canvas-support)
• Despite great efforts by Adobe, Flash on the mobile web (i.e. in a browser, non-browser implementations are irrelevant in the discussion about “open web vs flash”) remains almost non-existent. The fact that Apple continues to refuse Flash for the iPhone only makes this worse, due to the seemingly untouchable  “game-changer” status of their phone and due to the fact that more than 60% of all mobile pageviews originate from their mobile devices.

To sum it all up: when Adobe Flash evangelist Serge writes “Flash Player has it’s place on the web today and in the future” I can only agree. But I’ll bet you that place in the future will be less prominent than the one it holds today.

Possibly related twitterless twaddle:

• 2010: the year Flash became irrelevant
• Embedding YouTube HTML5-video with newTube
• WebTech news (august 2009)