Month: May 2010

Show Slow now automatically monitors your URLs!

I’ve been dreaming about this for a while now and then Aaron and I were working on different parts of the system which allowed that to happen and now it’s possible!

Please welcome automated YSlow and Page Speed monitoring using Show Slow!

Now all you need to do is to register an account and enter your URL and the rest will be taken care of. Show Slow will fire YSlow and Page Speed at your site and collect statistics on a daily basis so you can just sit back and enjoy the graphs!

You can see the results on Alexa Top 100 tab that I also added to ShowSlow.com showcase performance for most popular sites of the internet.

Due to limited resources, ShowSlow.com allows for only one URL per user account to be monitored, but I’m looking for ways to remove or at least increase this limit.

I hope you’ll enjoy the automation and please forward it to everyone around you!

Concepts: Automated site speed-up service. Really!

First, a short intro – I’ve been thinking of what to do with all the ideas I’m coming up and I’d like to try posting blog entries under “Concepts” category. I’ll accept comments and will write additions to the concept there as well. We’ll see what it’ll be like ;)

On my way home today, I was thinking again about asset pre-loading (example, example with inlining) after page on-load event (for faster subsequent page loads) for ShowSlow and realized that it can be created as a very good “easily installable with one line of JavaScript” service!

I think all the key components to this technology already exist!

First we need to know what to pre-load and here comes Google Analytics API and it’s Content / ga:nextPagePath dimension that will give us all the probabilities for next pages that users visit.

Now, when we have page URLs, we need to understand which assets to load from those pages and that can be solved by running headless Firefox with Firebug and NetExport extension configured to auto-fire HAR packages at beacons on the server.

HAR contains all the assets and all kind of useful information about the contents of those files so tool can make infinitely complex decisions regarding picking the right URL to pre-load from simple “download all JS and CSS files” to “only download small assets that have infinite expiration set” and so on (this can be a key to company’s secret ingredient that is hard to replicate). This step can be done on a periodic basis as to run it in real time is just unrealistic.

The last piece is probably the most trivial – actual script tag that asynchronously loads the code from the 3rd party server with current page’s URL as parameter which in turn post-loads all the assets into hidden image objects or something to prevent asset execution (for JS and CSS).

So, all user will have to provide is site’s homepage URL and approve GA data import through OAuth. After that, data will be periodically re-synced and re-crawled for constant improvement.

Some additional calls on the pages (e.g. at the top of the page and at the end of the page) can measure load times to close feedback loop for asset picking optimization algorithm.

It can be a great service provided by Google Analytics themselves, e.g. “for $50/mo we will not only measure your site, but speed it up as well” – they already have data and tags in people’s pages, the only thing left is crawling and data crunching that they do quite successfully so far.

Anyone wants to hack it together? Please post your comments! ;)

Fast Apache by default

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: redesign, server-side smoothing, SVN-assets and WebPageTest.org testing

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.

SVN Assets logoFront-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.

ShowSlow redesignWe 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.

Running WebPageTest.org tests directly from details page

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

Speed up your site – drop in .htaccess file

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.