After using drop-in .htaccess file in a few of my projects I realized that people have problems with it because their Apache doesn’t have the modules enabled.

Then I realized that apache doesn’t have any of those three modules (mod_deflate, mod_rewrite and mod_expires) enabled by default.

It means I found a first project that needs some “Fast by default” treatment!

If someone knows some Apache developers, please let me know, otherwise I’ll just send email to a mailing list (their Bugzilla is down, at the moment).

Release 0.6 is packed with new stuff – first of all, smoothing that was originally implemented in JavaScript was too slow and got moved to server side in PHP code so now results are still smooth, but not clogging down the browser.

Front-end performance is always a priority for ShowSlow project and all performance-related bugs have high priority so this was time to use SVN Assets. It means that all static assets will now have unique URLs based on their versions in Subversion. Make sure you look into config.sample.php and set $baseAssetURL variable accordingly (simplest approach is to set it to $showslow_base). Also make sure you have mod_rewrite, mod_expires and mod_deflate enabled in your apache.

We also got some look and feel update and you can see uniform header and footer across all pages. You might notice a registration page, stay tuned for more news there. You probably also noticed that http://www.showslow.com/ got buttons for following on Twitter @showslow and like button from Facebook – don’t wait, please show your pride and help spread the word!

And last, but not least, now you can run WebPageTest.org tests right from details page. This feature was hacked together originally and had to be removed because of compatibility issues, but now it’s a solid integration using WebPageTest’s automation API! You can also configure it to run your own instance.

It’s a lot of changes and I hope you have no troubles upgrading, but if you do, don’t forget that you can always ask question on our mailing list here: http://groups.google.com/group/showslow

It’s very important to speed up your web sites so you don’t loose the users.

That being said, many tasks in the checklists from Yahoo or Google are quite complex and are hard to grasp for people who didn’t work all their life configuring Apache or digging deep into the depths of HTTP.

To help this, I created a drop-in .htaccess file that will enable gzipping and long term expiration (helping with unique URLs for your assets).

<IfModule mod_deflate.c>
# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

# Don't compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip
</IfModule> 

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^(.*)\.(\d+)(_m_\d+)?\.([^\.]+)$    $1.$4    [L,QSA]
</IfModule> 

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/vnd.microsoft.icon "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/x-javascript "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType text/javascript "access plus 1 year"
</IfModule>

Gzip-ing and infinite (1 year is long enough) expiration are enabled right away.

In order for you to not have problems with cached items (infinite expirations are good, not bad), you’ll have to change URLs of all your static assets next time you change them. All you need to do is to add .XXX in front if file extension and URL will be unique (still pointing at your file, thanks to mod_rewrite rules above).

So, for example, if you have logo.png, all you need to do next time you change it is to link to it as logo.1.png and next time logo.2.png and so on, this way cache will not be used and you will no longer have cacheing problem:

    <img src="/logo.2.png" alt="Company Logo"/>

Go ahead and put it in the root of your site and let me know how it works for you.

P.S. it assumes that you use Apache 2.x and your hosting company configured apache to have mod_rewrite, mod_gzip and mod_expires modules, if they did not, just ask them, they should be able to do that easily.

Great news for Semantic Web, Facebook announced that they are going to use more structured metadata in shared web pages then just their original meta tags.

There are two parts to it – first they are going to provide storage about all things withing Facebook and on the internet in JSON format so people can write applications that use this data.

For example, public information about me on Facebook can be seen at this URL:
https://graph.facebook.com/sergey.chernyshev

And here how it looks:

{
   "id": "504972292",
   "name": "Sergey Chernyshev",
   "first_name": "Sergey",
   "last_name": "Chernyshev",
   "link": "http://www.facebook.com/sergey.chernyshev"
}

This way all you need to know is ID, which in my case is sergey.chernyshev or 504972292.

Another side of this is that Facebook is going to also store data from pages that were shared using their share button or added to interests or in any other way loaded into facebook’s system. They will be extracting this data using RDFa format and interpret it using a vocabulary that they call Open Graph Protocol (I will be calling it RDfb).

<html xmlns:og="http://opengraphprotocol.org/schema/">
<head>
<title>The Rock (1996)</title>
<meta property="og:title" content="The Rock" />
<meta property="og:type" content="movie" />
<meta property="og:url" content="http://www.imdb.com/title/tt0117500/" />
<meta property="og:image" content="http://ia.media-imdb.com/images/rock.jpg" />
...
</head>
...
</html>

This will allow sites to add a few lines of code to their pages to get them recognized as meaningful data instead of just human-readable documents – this will allow smart agents like search engines, mobile applications, embedded systems and just simple widgets to make sense of this data and help people see it in the context that is most usable for them.

I have a feeling that Facebook being a great driver for many business decisions related to promotion and marketing through social media, this change is going to be a best thing that happened to Semantic Web so far, might be even bigger then Yahoo’s and Google’s efforts in universal search.

P.S. Such a great present for my presentation about RDFa tonight ;)

Many people were frustrated with the graphs ShowSlow was showing as rankings and other measurements change too frequently if your pages are dynamic in nature and show different content on every request.

ShowSlow v0.5 is using rolling average to smooth the graphs, hope it’s going to be easier on your eyes and will help you get more meaning from the graphs.

Go ahead and download new version:
http://www.showslow.org/Installation_and_configuration#Getting_the_code

or just type “make” if you installed from Subversion.

WebPageTest.org is getting more and more popular, it was included in Google’s epic announcement that site performance is now part of ranking!

So, this Thursday, April 15th, get ready for WebPageTest.org Demo by Nicholas Tang at New York Web Performance Meetup!

If you haven’t RSVPed yet, now is your chance! If you can’t attend please update your RSVP as well to let others in.

http://www.meetup.com/Web-Performance-NY/calendar/12915226/

After I presented ShowSlow at Velocity Online Conference two weeks ago, I got a lot of suggestions regarding the software or a public instance and one of them was from Steve Souders who recommended creating a comparison page where people can see rankings for different sites compared over time.

It immediately resonated with me (G vs. Y! spirit) as I always try to create thought provoking features within ShowSlow that can help business people and developers ask new kinds of questions about their systems. In this case, the question is obvious – “Am I better then my competitors?“.

You can click “Compare rankings” tab on ShowSlow.com to see who is better – Google, Yahoo or Amazon?

Or you can just enter the URLs you’d like to compare and ShowSlow will display rankings graph for YSlow or PageSpeed (granted that data for these URLs was collected).

Each instance of ShowSlow can have it’s own it’s own set of URLs configured to link from “Compare rankings” tab so you can have your own competition (external or internal) measured.

Send me your fight stories or effect this tool had on your business folks, I’m very interested to see if this thing sparks the interest in performance project you’re running.

Thanks Steve!

I’d like to welcome Aaron Kulick to ShowSlow team!

Aaron was active user and contributed a few patches and then started to actively contribute documentation to the project wiki: showslow.org.

Now Aaron is a full-blown contributor with SVN access and his first contribution is solving the most common problem – how do we automate YSlow and PageSpeed in a headless mode.

He created an automation section in the repository, feel free to check out his code and share your experience: http://code.google.com/p/showslow/source/browse/#svn/trunk/automation.

In two words, all you need to do is:

• Run a memory framebuffer server (Xvfb)
• Then configure Firefox profile(s) with different settings disabling some features that require user intervention and enable autorunning the extensions and beacons
• Then you just create a list of URLs to test and feed it to test_harness.pl script that will launch Firefoxes appropriately

monitor.sh is a simple shell wrapper around the harness script that you can simply run from the cron job.

For more information read the README file and I hope we’ll have more documentation on showslow.org as well!

Please join me in thanking Aaron for this important tool!

Also, just a reminder, if you are not subscribed to a mailing list / google group, you can do that here:
http://groups.google.com/group/showslow

Useless requests
There is a fundamental problem with static assets on the web pages, like images, CSS files and most importantly JavaScript files – they are requested from the server over and over again even if they were not modified between page requests. This slows down page rendering and in case of JavaScripts quite dramatically as JavaScript downloads block downloads for the rest of the assets by default.

Infinite Expiration
Setting infinite Expires headers is a great solution to the problem – this way everything downloaded from the server will be just kept in a browser’s cache! It is very effective and ranked 3rd on best practices lists provided by Yahoo! Exceptional performance team and even first on Google PageSpeed’s list.

You can clearly see the difference on this graph below:

Scripts and CSS in the headers load from cache eliminating rendering delay and images load from cache as making document load event happening much sooner.

Caching problem
But there is a problem with this on the opposite side – when assets change during normal development, e.g. image gets updated or JavaScript or CSS modified to fix a bug or add a new feature, it must be pushed to user’s browser, but it is not requesting it anymore loading the ones it saved to cache. Developers are used to press Shift+Reload or Shift+F5 to force browser to refresh the page, but users don’t do that and that’s why many just don’t use infinite caching technique, they prefer peaceful development without “caching problem” paying the price with degraded user experience.

URL fingerprinting
To solve this problem, simple technique, sometimes called “fingerprinting” or “cache busting” (term usually indicates that techniques used for wrong reasons) can be used to replace Entity Tags and Conditional GET techniques both of which require server requests and will not work with infinite expiration.

The idea is simple — URL of the asset should be unique for each version of the asset, effectively changing every time you update you script or an image. This way browser will not find the asset in it’s cache and request new one from the server storing results in another cache entry and eventually pushing old one out.

Perceived as complex
The problem implementing this lies within current status quo with web servers that use file system having no idea about file versions. And to be fair, URL<->file one-to-one paradigm is just plain simple to understand helping web grow as fast as it did, but it affects knowledge for all developers and almost no systems are built with versioning in mind.

My experience with many teams shows that this technique is perceived as overly complex and people avoid it till the last moment while this quite obvious solution should be common functionality within the web servers.

Multi-layer problem
Another problem, I believe, is that this solution affects many “layers of the pie” – from asset publishing process and HTML modification by designers and front-end developers to software modifications done by backend developers to web server configuration done by system administrators. This means many groups are involved and more people involved, the harder it gets to push through and nobody wants to bring it up.

Solution: SVN Assets
Building HowDoable mostly alone, I don’t have “multi-layer” problem, more over, being a performance geek, I’m concerned with performance probably more then needed at this stage of development. So I spent some time early in the project to make sure my builds and upgrades don’t suffer from “caching problem” and still perform as good as they can with cached content.

What I did was simple – I used a basic and most obvious source of versioning info there can be – source control software, namely Subversion and made sure that my code does not insert a single asset URL into HTML without appending it’s Subversion version to it.

Since many project use Subversion and PHP for their content management, I thought I’d share it with the community and being a strong believer in open source I try to release as much infrastructure free as possible.

So, welcome SVN Assets, a set of tools to make your assets cache using Subversion and simple build process.

I’ve built it for PHP, but will be happy to see it used by developers on other platforms.

Usage is described in README file – just generate data file from Subversion and use assetURL('images/my.jpg')to insert your assets in the code. There is also a command line script that updates all CSS files to point to the proper versions of the files so you don’t have to maintain them by hand and still serve them directly from the file system.

Please, go check it out and let me know what you think about it!

You can also subscribe to a mailing list if you’d like to ask questions and discuss possible improvements:
http://groups.google.com/group/svn-assets

I gave extended presentation about ShowSlow at New York Web Performance Meetup yesterday and I hope I was able to inspire people to start tracking their web site’s performance over time and thinking about your metrics that they want to collect for their business.

There were a couple questions about automation so here’s the blog post I wrote about automation a couple months ago: Automating Page Speed and YSlow monitoring.

Also, here’s the simple script that can be used with ShowSlow:
http://code.google.com/p/showslow/source/browse/trunk/showslow.sh. By the looks of it you can tell that it’s relatively simple to do.

You might also want to look at about:config preferences for Firefox to see if any of them affect you, e.g. forcing Firebug to open and grade each page, cache storage, automatic updates of extensions and stuff like that. I hope to have it documented better in near future.

Best way to learn more about ShowSlow configuration is to read
documentation on ShowSlow.org

If you’d like to just try the DEMO instance, go ahead and configure your YSlow to post there or just use export menu in PageSpeed or NetExport.

I’d like to also thank our host Logicworks and Stephanie personally for hospitality – it’s great to be welcome!

At our next session, on April 15th, Nicholas Tang is going to demo WebPageTest.org – free, web based performance analysis site that uses AOL Pagetest open source tool developed by Patrick Meenan. This will be first in a series of “Tools” sessions where I hope we’ll cover many useful details of them all.

I hope to see you all next month!

P.S. A few slides I had are on SlideShare, the rest was a demo and is not available, unfortunately.