Google Page Speed support now in ShowSlow

Google PageSpeed 1.2 is now able to send data to a beacon (see bug #58) so I added some minimal support for it into ShowSlow that you can get from the trunk.

Support is minimal and I only display PageSpeed’s overall rank and page load time (which looks like only initial request load) and it seems that there is no way to lunch the test automatically. But it’s a great first step and that I might need to rewrite the whole thing for generic beacon API…

ShowSlow, Mozilla Cesium and new beacons from YSlow and Page Speed

In early July, Mozilla team released a new project similar to ShowSlow in it’s concept, it’s called Cesium – their goal is to help people monitor what’s going on with their performance.

Ryan Doherty who’s running the project and I agreed to join forces to the degree possible and started to work with YSlow on improving the beacon support there, we also followed up on a bug I filed with Google Page Speed project to implement the beacon and it looks like first version is coming up in v1.2 of Page Speed.

Ryan also created a page on Cesium wiki to document beacons and we’re working together on it to make sure we reflect the state of beacons there.

Even Faster Web Sites

Even Faster Web Sites
I’m done with my copy of Even Faster Web Sites.

It’s definitely a book worth reading if you’re well into web performance optimization and want to step even further when all simpler optimizations don’t bring any more improvements.

JavaScript sections from Ajaxians and Nicholas Zakas are quite interesting but definitely for most complex 2.0 apps with tons of JS and front-end processing.

Flushing early and CSS selector performance are important too, Steve was talking about it at Web 2.0 @ SF – CSS is a bit beyond my comprehension unfortunately, but flush is easy to comprehend for those who made at lease a single IO app, especially networked.

One thing among tools – in my opinion, was given less credit then it deserves – it’s connection view (next to the waterfall) and content breakdown chart as well as empty/primed dual run definitely bring it high in the “packet sniffer” section and not only “analytic tools” section. And I agree with Steve that it’s availability through the web give it a huge value in the eyes of developers and business decision makers. It’s very possible though that that section of the book was done when most of these features were added.

If you didn’t read Even Faster Web Sites, you probably should. As well as its prequel – High Performance Web Sites.

Custom events on ShowSlow

OK, next step in ShowSlow was to make measured data to be a little bit more useful for analysis – previous change of adding rule grades was useful, but simply replicates YSlows functionality and you should be using YSlow itself to get this data.

This time I’ve added something that almost no analytics systems have for some reason – custom events reported directly on the main graph (originally this idea came from building of custom web analytics software).

So, how does this work? First , you can report any event that happened to the site during some time frame (or at specific moment). To do so you can use a beacon located under /beacons/events/ in you installation – see it in action here:

You can use a simple web form to add data or you can write an automated script that will send events there automatically.

When submitting events, make sure you specify URL prefix to have your events being reported only for sites that these events actually affect (I assume that you’ll be running it locally for just a few sites and not whole internet). In addition to event title, you can also add resource URL that will link to the page related to the event (e.g. blog post, updated file in your Subversion repository or Bugzilla page that describes fixed bug).

You can also add “type” field to distinguish between the events (e.g. “blog post”, “svn” or “bug”) – hope to have those colored differently in the future.

So, when after you have events in your system, they will be displayed on a timeplot chart as vertical lines or areas (if it was a continuous event where you specified end date/time). When you hover over the event, it gets orange border and when you click on it, note bubble pops up with event title (and link if it was provided):

ShowSlow events

So feel free to automate the event gathering process – looks like I’m going to set up CSS/JS changes to be reported there as first thing on my internal instance.

“Tools of the trade” meeting was a good start!

Meeting last night was a good start!

Thanks to everyone who attended, I hope you enjoyed it.

I think it was important to see that front-end performance is a very important topic among the community, but still there are some topics of traditional back-end performance/load-testing/scalability/reliability that a worth have some events dedicated to; maybe we’ll even have some joint event with some operations meetup for those.

Next time I’ll also try not to forget my camera so I can share photos with you, but feel free to take and post yours. Also, if you’re going to blog about the event, please send links to the mailing list or the message board (even if your post is not favorable ;)).

We already have two events scheduled in June and July, but feel free to send me your suggestions regarding the topics you’d like to discuss or present at the meetup!

Once again, thank you to Nicholas Tang and Interactive One for hosting us and I’ll see you on our next meetup at Etsy ( on June 16th.