SLO-JS and how to speed up widgets

This Thursday I gave a talk at NY Web Performance about third-party content and topic proven to be quite hot with many people in the audience, good Q&A and group discussion afterwards. We talked about ad banners, widgets and tracking “pixels” and overall theme was lack of control and heavy reliance on 3rd parties.

Ads and tracking pixels, unfortunately are quite complex and changing their behavior is hard, but widgets are a bit simpler to deal with and can probably be improved.

Working on my MediaWikiWidgets.org project, I saw quite a few widgets and over time I started to realize that sales people’s magical promise of “easy integration with single line of JavaScript” which you can see on any site that provides widgets (and especially those that rely on widgets as primary method of distribution) is fundamentally flawed.

While it’s a great sales promise and simplifies integration, maintenance and gives a lot of control over user’s information, it brings slowness and introduces SPOFs to publisher’s sites.

To make people think about performance when they hear the magical sales pitch of Single line of JavaScript, I decided to abbreviate it to SLO-JS which gives a very clear impression about the performance quality of this solution.

Now, next time when you see the magical words in vendor’s proposal, there is no need to explain or complain, just abbreviate it and this will hopefully give the right impression and make people think about testing the performance of the 3rd party source.

Solutions

It would’ve been pointless if there was no alternative to the SLO-JS, but in reality, it is not the only way to include code, it’s just the oldest and there are other, more reliable and fast alternatives. All we need to do is to explain how they work and make it easy for vendors to provide these alternatives to sites that care about performance.

First alternative is quite simple – instead of copy-pasting a SLO-JS snippet, just let people copy-paste a mix of HTML, CSS (optional) and async JS call that will create a reasonable placeholder until data is loaded and will not block the rendering for the rest of the site.

A few vendors are already do that – DISQUS, for example, provides the following code:

<div id="disqus_thread"></div>
<script type="text/javascript">
  (function() {
   var dsq = document.createElement('script');
   dsq.type = 'text/javascript'; dsq.async = true;
   dsq.src = 'http://mediawikiwidgets.disqus.com/embed.js';
   (document.getElementsByTagName('head')[0]
      || document.getElementsByTagName('body')[0])
         .appendChild(dsq);
  })();
</script>

Notice that it gives you a div tag with disqus_thread id to insert into your page (in this case the placeholder is just empty) and then uses asynchronous script tag to load the data without blocking the rest of the page.

Transforming your code to take advantage of this probably requires a couple hours of work at best – just replace document.write with static HTML wrapper (with specific ID or class) and build additional DOM elements within the code, then use wrapper’s ID to insert the DOM tree and use the async tag to load all your JS code.

Use this pattern for good widget development, suggest similar approach to vendors that give you the most grief, and we’ll have faster web pages pretty soon.

Another alternative I proposed at the Meetup is to download content on the back-end and insert it right into HTML with optional JavaScript used only for data load.

Most of the time content doesn’t change for each request and can be cached for minutes, hours or even days at a time. In some cases it never changes, especially for embeddable content like YouTube videos or Flickr photos.

Andrew Schaaf proposed a name for it – Fetch and store JavaScript with great “superhero” abbreviation of FAST-JS.

It is quite easy to implement them in the language of your choice and probably worthy of Open Source project that will enable appropriate caching mechanism and make it easy for people to implement fast solutions to SLO-JS.

It’s a bit harder to do then async widgets and requires some backend coding, but will allow reducing front-end complexity and amount of extra JS on the page to zero.

ShowSlow 0.7: dynaTrace beacon, list pagination, removing local URLs

A few changes were made to ShowSlow in a past couple months so it’s time for a new release – welcome ShowSlow 0.7!

Full list of changes can be seen in bug tracker, but here are the most important ones:

  1. Resolved a problem with missing mod_rewrite (#43)
    A few people complained that timeplot charts and other JS-based functionality wasn’t working on details page. This was happening because mod_rewrite wasn’t enabled for the site or wasn’t compiled into Apache at all. The fix was actually done in SVN Assets project and it will autodetect mod_rewrite now and will use query string for URL uniqueness if it’s not available.
  2. dynaTrace beacon and results on details page (#46)
    dynaTrace team is releasing beaconing functionality in dynaTrace AJAX Edition 2.0 (coming up in August, but Beta is already available) and you can now send results to Show Slow.
    dynaTrace ShowSlow menu
  3. Added Google Friend Connect support for user registration and login
    UserBase (which Show Slow uses for user management) supports Google Friend Connect for a while and I just added it to Show Slow so now users can use Google, Twitter, Yahoo!, OpenID, AIM or Netlog accounts to sign in (and Google will probably support more in the future).
    Google Friend Connect for logging in
  4. file:// and chrome:// URLs as well as local network URLs are now ignored (#55)
    I don’t know why, but people were submitting data for non-HTTP protocol URLs (file://, chrome://) and private networks (10.x, 193.168.x and even 127.0.0.x) to public instance (http://www.showslow.com/).

    I believe some of them might be pointless on private instances as well.

    So now Show Slow is configured to ignore those URLs, but you can configure your instance to accept internal IPs if you really need it (although I suggest you use internal DNS for development sites instead).

  5. Added pagination to URL listing (#23)
    Ryan Doherty submitted a patch for list pagination for URLs measured tab which was important to increase performance of the tool.
  6. Added pagination to URL listing (#60)
    I also worked on grouping of URLs so now you can configure Show Slow to group URLs on your instance for different groups within your company or just for different sites or site sections driven by different tools, for example.

Upgrading is easy – just download new version and follow upgrade instructions.

If you don’t want to wait for a packaged release, feel free to use Subversion – all you need to do is run make and it will upgrade both code and database.

If you prefer to use Subversion but stick with release code, the tag for this release is REL_0_7

As always, please report any problems with installation to the mailing list:
http://groups.google.com/group/showslow

And feel free to contribute – there are many ways to do so:
http://www.showslow.org/Main_Page#Contributing

July 2010 Meetup: Taming third-party content: ads, widgets, trackers

New York Web Performance Group Logo
Third party content slows down our site while we don’t have control over it.

Ad banners, JavaScript widgets, analytics trackers – they all contribute to site’s slowness and sometimes are biggest offender.

On July 22nd, I’m going to give a presentation entitled “Taming third-party content: ads, widgets, trackers” at New York Web Performance Meetup.

If you run a web site, you most likely have 3rd party content and it’s most likely slowing you down.
Come and let’s talk how we can solve this!

Please RSVP on Meetup.com.

Concept: Window into a virtual world

When I first visited ITP show back in 2005 or so, I realized that I am interested in physical computing and when going home from the show I came up with the idea of a project with ITP spirit – a window into a virtual world.

The idea was to use a notebook or a tablet PC with a compass and gyroscope contraption attached to it to browse 360 degree panoramas so the viewport of the panorama matches the direction of the screen. This way moving the viewport, user will be able to see the “virtual world on the other side of the portal”.

You can guess why I’m writing about this concept right now – because I couldn’t imagine back then that device like that would be available to consumers. And now I’m using it to type this post, yes, I’m talking about Apple iPad ;)

So, getting back to the concept – now there is no need for custom hardware which I was thinking is necessary 5 years ago and all is needed now is an iPad application.

OpenGL sphere with 360 panorama mapped to it as a texture plus some (probably sophisticated) logic to make device scroll the panorama based on accelerometers and compass.

Combine it with some sci-fi panoramas or with some real-estate panoramas and you have a cool product that blows peoples mind and gets all the blogging attention you need to make a first million in the app store.

Another app for real estate brokers that can go along with this one is panorama maker – just point you camera around the room (maybe in video mode) and augmented with direction and tilt data it can help automate panorama creation which broker (or “for sale by owner” enthusiast) just uploads to property’s site.

All that is a bit optimistic, obviously, as panorama creation uses some hardcore math and requires significant image processing and often manual involvement, but it can definitely be aided by dimensional data.

Let me know if anything like that already exists or if you’re interested to give it a try – I’d pay for such app for sure! Can do that in advance using kickstarter.com if you like ;)

Comments are always welcome! And don’t try to be easy on my feelings, tell me what wrong here ;)

Show Slow now Ignores non-public URLs

A few people noticed that users submitted all kinds of URLs to Show Slow including those with file:// schema and even chrome:// schema (internal schema for Firefox extension files). Some users also sent URLs with private IPs and from localhost which can not be accessed from the internet by general public.

I added some code to handle these problems and now non-HTTP URLs are not going to be accepted and private network addresses will be ignored by default too.

Show Slow displays old URLs that are being ignored with new configuration in red

You can still configure your own instance to accept private network URLs by tweaking the settings, but you probably shouldn’t remove localhosts anyway.

Don’t forget to run deleteignored.php to remove measurements for URLs that were not supposed to be tracked.