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


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 = '';
      || document.getElementsByTagName('body')[0])

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.

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

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 showcase performance for most popular sites of the internet.

Due to limited resources, 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).