Frank Goossens' Twitterless twaddle
Archive for the ‘Web development’ category
Google likes fast! Visitors like fast! So why don’t you go make your site really 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!
- 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).
- 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.
- 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)
- 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
- 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.
- default Wordpress (on a Linux VPS with 320Mb RAM memory): 6.5 seconds
- (1) with PHP APC activated: 4.1 seconds
- (2) with WP Super Cache: 3.1 seconds
- (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!
A short followup on my previous post about iframes; as I happen to like simple drop-in solutions, I updated the javascript that handles the ‘blank 2nd page in an iframe bug’ to automagically work upon inclusion in the html.
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.
Iframes have always been frowned upon by web-purists (confession: myself included). But things are never black and white and sometimes iframes can be the best solution for a problem (you could substitute “‘iframes” with “Flash” in the previous 2 sentences, but that’s another discussion). So here are 5 quick tips which might lessen some of the SEO- and usability-problems associated with the use of iframes;
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.
PPK of Quirksmode-fame it at it again, this time badmouthing iPhone-centric web development. A lot of people seem to take issue with his point of view, but aside from the (typically Dutch?) in-your-face bluntness, I do think he makes some very valid points. The web is about broad accessibility, about allowing as many people as possible to access your information/ application and the same should indeed be the case for mobile web development.
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!
With all the discussions about the place of Flash on the ever-evolving web and the excitement following Google’s announcement about YouTube going HTML5, one would almost forget that YouTube is only at the very start of their “open video” endeavor. The limitations of the current implementations are numerous; there’s no OGG (damn), no ads (yeah!) and no embedding either (damn) for example.
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 
Last week’s prediction about Flash becoming irrelevant was pretty controversial, and some of you Flashheads had interesting remarks and -rhetorical- questions both in the comments and on Twitter (a big shout-out to Clo Willaerts for sharing). So without further ado, here’s my follow-up.
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.
In a good old-fashioned rant, Sam Johnston, an Australian cloud computing specialist and technology lobbyist, took offense with Mozilla’s stand against webdb in the W3C html5 webapp spec working group. On Twitter he was even more candid, writing “The anti-SQL nazis are apparently causing some real problems for offline-enabled webapps”. Although there is a lot more to Mozilla’s objections then just “developers don’t want to do SQL”, he off course is right that the decision to freeze standardization-work on webdb and to look into an alternative (web simple db) is a serious slowdown.
That’s the bad news, but let me share some good news with you as well; you can do cross-browser persistent data storage right here, right now! All you need to build a html5 webdb-alternative is old-fashioned javascript arrays and objects and related functions, some json and last but not least Paul Duncan’s persistjs (don’t download it there though, use the more recent version in the repository instead), a little javascript library that goes a long way to provide precious cross-browser persistent storage.
Simplified, your offline-enabled webapp would have to;
- store data in an array (or in objects in an array)
- do CRUD using your standard javascript functions (you could turn to something like jlinq to do more advanced things)
- use JSON.stringify (native or from json2.js) to turn the ‘repository’ into a string
- store the resulting JSON-string with persistjs’s store.set
- close tab or browser
- retrieve JSON-string when user returns with store.get
- use JSON.parse to turn the string into an array
- go back to step (2)
As code is better then a numbered list, I’ve created TrappistDB, a -very simple- demo that can do CRUD on a small persistent dataset of beer Trappist-related information.
So there you have it, basic cross-browser (*) persistent data storage without html5 webdb. Just sprinkle some appcache-magic (adding Google Gears LocalServer-support is trivial) on top to store html, js, css, … in your browser and you have a fully offline-enabled webapp.
(*) tested successfully in Firefox 3.6b5, Safari 4.0.3, Chrome 3.0.195.38, IE8 and MSIE6 (with and without Gears), IE7, the Android 1.5 browser on my HTC Hero and in iPhone’s Mobile Safari. I’ve got some weird bug in Opera 10.10 that I can’t seem to iron out though, but feel free to tell me what stupid mistake I made.
