Custom Metric Beacon allows every instance of ShowSlow to configure metrics it wants to record in addition to YSlow and PageSpeed ranking.

Once metric beacon is configured, simple GET/POST requests can be sent to the beacon with some numeric value which gets recorded and displayed over time on a graph.

You can also click on “Custom Metrics Beacon” on beacon list page (e.g. http://www.showslow.com/beacon/ for public instance) to see interactive form for manual submission.

Custom Metrics can vary depending on your needs, good examples include:

• bounce rate on the page (from your analytics software)
• amount of results on search page (from system configuration)
• server load (from backend monitoring tool)

All these metrics are specific to your needs and you have to write some tools to collect them, but ShowSlow will be able to aggregate them all along with the rest of the data.

For configuration docs, see Installation page on the wiki.

A few people on the list asked me how to automate Show Slow monitoring and dug up all the magic I used on my monitoring farm and try to summarize it here:

Here are a few steps you’d want to follow:
Set up separate browser profiles – one for Google Page Speed and one for YSlow.
To learn how to set up a profile, take a look at Mozilla’s documentation: Managing profiles

Install extensions in respective profiles
Install Firebug for both profiles and Page Speed and YSlow in their respective profiles (extensions are installed and configured separately for each profile).

Set default Firebug tab
In each profile, set up it’s particular extension to be a default Firebug tab.

To do that, you need to set extensions.firebug.defaultPanelName property to:

• pagespeed for Page Speed
• yslow for YSlow

Configure autotesting
Configure to run measurements automatically when browser starts

• extensions.PageSpeed.beacon.minimal.autorun = true for Page Speed
• extensions.yslow.autorun = true for YSlow

Run Firefox periodically
Next step is to create a list of URLs you’d like to test on a regular basis and run Firefox periodically.

You can use a simple script I bundle with Show Slow:
http://code.google.com/p/showslow/source/browse/trunk/showslow.sh

If you’ll have any troubles, please feel free to post your questions to the discussion group and I’ll be happy to answer them:

http://groups.google.com/group/showslow

I’m planning to add better URL management to Show Slow itself so your automation scripts can fetch a list of URLs to process right from your Show Slow instance and some other tools can post URLs to be monitored.

There is probably more to be done to simplify this automation – from better shell scripts to additional Firefox extensions. More stuff will come along eventually.

I decided to extend Google Page Speed support in Show Slow to keep track of metrics the same way it’s done for YSlow.

You can see results at showslow.com – here’s example with Page Speed results only:
http://www.showslow.com/details/?url=http://start.ubuntu.com/8.04/

And here’s the example for both Page Speed and YSlow together:
http://www.showslow.com/details/?url=http://www.mozilla.com/en-US/

Version 0.3 is released and can be found in SVN here:
http://showslow.googlecode.com/svn/tags/REL_0_3/

Please upgrade and send your comments and questions to the support group here:
http://groups.google.com/group/showslow

I’m working on HowDoable for a few months already and it’s been a fun ride and main challenge is to go towards the goal.

I’m using Pivotal tracker for my agile needs and i have a long backlog which I’m adding to more stuff over time, rearranging the list and so on. What I noticed that rearranging gets a pattern during hard times – I tend to avoid some kind of tasks – those that are not very natural for me, like writing some texts in English or just regular startup problems like writing business plan or think about the product from user’s perspective.

What I tend to push up the list is something I’m comfortable doing, like coding new features or playing around with new colors, logo, some other things, but definitely not those that bring me closer to the release.

Many words are said about shipping the product early and why it can be vital to business so I’m not going to repeat them here, but I never found a good recommendation about how exactly do we do that. One thing that I heard lately is a paradigm of “minimal viable product” which is about the set of features to include that will make the product stand out, but no more.

What it doesn’t describe is how do you do that in agile environment when so many backlog items come up when you start and reprioritization happens very often and requires constant attention. So I struggle to find that feeling that I can catch and follow during the periodic reordering of my task list / backlog to make sure that things that need to be done to be successful don’t get pushed down by things that I just feel like doing.

Some time ago I read a good quote from Reid Hoffman of LinkedIn – “If you’re not embarrassed by your first release, then you launched too late.” and it stuck with me as a great description of the problem of over-polishing the product which is not even seen by users yet.

So I though to myself – if I look at it from agile perspective and treat each iteration’s or even day’s product as a final product (thing that you want to have in your agile world) then embarrassment is exactly the feeling that needs to guide you when you’re picking the next thing to do.

What I mean is that if you thinking of moving some task down to replace it with some other task, think if this other tasks’ completion is going to help you avoid some potential embarrassment and if so, then stop right there! – what you’re doing is trying to feel better about the product and not bringing the product to the state that will benefit the business.

Unfortunately these are two different things and extreme perfectionism tha arises from trying to “polish the torpedo” never did any good and many projects and businesses were ruined by “unfinished torpedoes with shiny casing”.

So now what I do and urge all the strartupers to do (or open source developers for that matter) is to follow the path of the most embarrassment – when you feel that you have a choice of doing something to reduce the embarrassment, turn around and go into the opposite direction because you’re trying not to hurt your feelings. What you need to do instead is to go towards the business goals that I hope you had time to define and didn’t just jump into development, right.

Hope this insight helps and if you feel I’m wrong, let me know in the comments.

Steve Souders wrote a post about people mispronouncing his name.

Obviously, I’m an emigrant which makes it different, but in my case people usually can’t finish pronouncing my last name and stumble somewhere in the middle ;)

I even thought about borrowing a nickname from Ernesto Guevara, so it’s easier to remember like Sergey “Che” Chernyshev, but wasn’t sure if I really wanted to be associated with communism ;)

It’s hard to translate this joke to English, but I felt like posting it anyway – it describes what people feel when they actually try to pronounce my name:

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…

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, WebPageTest.org 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.

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: http://www.showslow.com/beacon/events/

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):

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.