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 it’s 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.

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 (http://www.etsy.com/) on June 16th.

Just a few days ago I wrote first version of ShowSlow and then released it Open Source.

But progress is unstoppable and Yahoo! released long-awaited YSlow 2.0 so it’s time for ShowSlow 0.2.

This means that I’m sitting down and analyzing Beacon parameters to make sure ShowSlow can collect data properly – so here’s the list of parameters that YSlow 2.0 is sending with the beacon (actual set of y* parameters depends on the profile used – ydefault sends them all):

• w – size of the page in bytes (v1 sent size in kilobytes)
• o – overall YSlow grade calculated for the profile used
• u – URL of the page tested
• r – total amount of requests with empty cache
• s – page identifier for yahoo pages (like yahoo music, sports, etc), blank on non-yahoo pages
• i – testing profile used:
  • ydefault – YSlow (V2)
  • yslow1 – Classic (V1)
  • yblog – Small Site or Blog
  • or custom profile’s title with dash-encoded spaces
• ynumreq – Make fewer HTTP requests
• ycdn – Use a Content Delivery Network (CDN)
• yexpires – Add Expires headers
• ycompress – Compress components with gzip
• ycsstop – Put CSS at top
• yjsbottom – Put JavaScript at bottom
• yexpressions – Avoid CSS expressions
• yexternal – Make JavaScript and CSS external
• ydns – Reduce DNS lookups
• yminify – Minify JavaScript and CSS
• yredirects – Avoid URL redirects
• ydupes – Remove duplicate JavaScript and CSS
• yetags – Configure entity tags (ETags)
• yxhr – Make AJAX cacheable
• yxhrmethod – Use GET for AJAX requests
• ymindom – Reduce the number of DOM elements
• yno404 – Avoid HTTP 404 (Not Found) error
• ymincookie – Reduce cookie size
• ycookiefree – Use cookie-free domains
• ynofilter – Avoid AlphaImageLoader filter
• yimgnoscale – Do not scale images in HTML
• yfavicon – Make favicon small and cacheable

Once again, to configure YSlow to send your data to a beacon, you need to set a couple configuration parameters on about:config page of your browser:

for YSlow 1.x

• extensions.firebug.yslow.beaconUrl = http://www.showslow.com/beacon/yslow/
• extensions.firebug.yslow.optinBeacon = true

for YSlow 2.x

• extensions.firebug.yslow.beaconUrl = http://www.showslow.com/beacon/yslow/
• extensions.firebug.yslow.optinBeacon = true

Where beacon URL is either public: http://www.showslow.com/beacon/yslow/ (your measurements will be shown to public so please make sure you’re OK with it before you use it) or private URL on your instance which you can get here: http://code.google.com/p/showslow/source/checkout.

OK, ShowSlow is taking shape and I decided to follow “Release Early, Release Often” motto so now it’s open source: http://code.google.com/p/showslow/

Current version accepts YSlow beacons and you can configure your browser to post to public showslow.com beacon or install your own instance if, for example, you want to hide the results from others.

Sample screenshot (amazon.com):

After talking to Steve Souders about local events at Web2.0Expo in San Francisco, I realized that New York is missing Web Performance optimization event. I went ahead and saved 75% using Meetup.com discount code (Web2SF09 – graciously provided by Derek Odegard of Meetup team) and now you’re welcome to join New York Web Performance Workshop meetup.

Our first even is planned for May 12 and I’m looking for location at the moment, talking to a few companies I had preliminary OK from. In the first part of the event, we’re going to talk about current state of tools for web performance analysis and optimization and in the second part we’re going to look at the real-life sites and what can be done to improve their performance.

Yesterday, I talked about Web Performance at New York Web Standards Meetup hosted by theMechanism.

Thanks to all attendees for coming to the presentation, I hope it was informative and worked as a call to action.

If you have any questions or need help with your performance optimization project, feel free to post your comments here or contact me directly if you want, I’ll be happy to help.

HTML Slides with meta-data embedded using RDFa are available here

If you’d like to watch more presentations on performance (already have about 30 of them), you can visit TechPresentations: http://www.techpresentations.org/Performance

Including a couple presentations about YSlow and related tools: http://www.techpresentations.org/YSlow

Once again, thank to all attending, asking interesting questions and volunteering for YSlow treatment ;)

Sergey

Some time ago I created MediaWiki Widget for TypePad Connect:
http://www.mediawikiwidgets.org/TypePad_Connect

While editing a wiki page and going to different versions of it, I noticed that Comments widget has a well known issue – it has no idea which comments should be displayed on the page if page has different URLs (ad campaign tracking codes will probably be a main commercial issue, but also editing interfaces in MediaWiki and other CMS softwares and so on) – you can see example of what I’m talking about on these two pages:

• http://www.mediawikiwidgets.org/TypePad_Connect
• http://www.mediawikiwidgets.org/w/index.php?title=TypePad_Connect

which represent the same content page with different URL.

Other frameworks like JS-Kit, for example, solve this problem by allowing to pass URL or ID of the page to the widget, but I just had an idea about new approach to this issue.

The thing is that Google, Yahoo! and Microsoft just announced a new tag in order to fight SEO spam (and I already installed MW extension from Wikia):

<link rel="canonical" href="http://www.mediawikiwidgets.org/TypePad_Connect"/>

The idea is very simple – they just need to know all the pages that legitimately think that they are copies of page X so their smart algorithm that fights page duplication spam will have more clues.

But the side effect is that tools like TypePad Connect or JS-Kit can automatically, on the fly identify the pages they should serve content for. All you need to do is to write a simple jQuery code like this (my first line of jQuery) :

var canonical = $('html:first > head:first > link[rel=canonical]').attr('href');

I think all of us will benefit if widgetized tool providers like TypePad will push for this as solution to the page identity problems.

I hope this will be included into a list of high priority issues and TypePad Connect will get improved first (I actually enjoyed creating widget for it – it was much-much easier then with other vendors).

I’ve done some integration of OpenID selector into MediaWiki OpenID extension and some fixing/improvements of the latter.

You can see changes on TPr, MWW and SharingButtons.

Next week will take a look into checking it back in. Still need to figure out if I can check in BSD code (selector) into MW tree or need to write something similar (I’m even thinking about creating something like SharingButtons, but for OpenID providers) and release with GPL.

Did some maintenance on my projects – added OpenID support to wikis:

• http://www.sharingbuttons.org/Special:OpenIDLogin
• http://www.techpresentations.org/Special:OpenIDLogin
• http://www.mediawikiwidgets.org/Special:OpenIDLogin

Also working on embedding OpenID selector – check Sharing Buttons OpenID login page (still needs some work, but quite promising).

Also changed all wikis and blogs to use memcached instead of APC for cache storage – it seems to be much more efficient.