In my recent blog post on TDD I mentioned that I had just put together a Javascript test suite using Jasmine. In my case, I’ve used Phantom.js for headless fast tests as well as Selenium Webdriver for real browser testing (I usually use headless during development to get quick feedback and use the real browsers as a safety check before commit). Nick Gauthier’s project inspired me to share my setup.

Test suite

For this blog post, I can not share the code I already built as it belongs to my employer. Instead, I will start from scratch using the Jasmine 1.2.0 standalone release. It includes a sample test suite which will be a perfect fit for this example. It includes the main test runner (an HTML page called SpecRunner.html) and the Jasmine distribution (under the lib/ directory). It also includes example code under spec and src. If you unzip the file and load SpecRunner.html in your browser, you should see the test suite pass without errors.

Phantom.js

To run the test suite using Phantom.js, I’ve used Joshua Carver’s Jasmine runner for Phantom.js. I copied the lib directory from the project under lib/phantom-jasmine in my source tree.

Next I changed the SpecRunner.html to add an additional reporter called ConsoleReporter - which is part of Joshua’s project.

1

<script type="text/javascript" src="lib/phantom-jasmine/console-runner.js"></script>

1
2

window.consoleReporter = new jasmine.ConsoleReporter();
jasmineEnv.addReporter(consoleReporter);

Third step: patch Jasmine to get a stack trace on test failure. The current version of Jasmine (1.2.0) does not show stack traces when executed throught Phantom.js. Thanks to a tip found on Stackoverflow I was able to fix that with a very simple patch and submitted a pull request.

1
2
3
4
5
6
7
8
9
10

@@ -106,7 +106,9 @@ jasmine.ExpectationResult = function(params) {
   this.actual = params.actual;
   this.message = this.passed_ ? 'Passed.' : params.message;

-  var trace = (params.trace || new Error(this.message));
+  var err;
+  try { throw new Error(this.message); } catch(e) { err = e };
+  var trace = (params.trace || err);
   this.trace = this.passed_ ? '' : trace;
 };

Assuming that Phantom.js is installed and available in the $PATH, the test suite can be executed using the following command:

1

phantomjs lib/phantom-jasmine/run_jasmine_test.coffee SpecRunner.html

Finally, I wrapped the above command in a Rake task so that I can just type rake phantomjs to run the test suite:

1
2
3
4
5

desc "Run Jasmine tests with Phantomjs"
task :phantomjs do
  # Note: we are assuming phantomjs is installed and available in $PATH
  sh %{phantomjs lib/phantom-jasmine/run_jasmine_test.coffee SpecRunner.html}
end

This is what the output looks like:

Webdriver

In order to execute the Jasmine test suite in real browsers, I am using Selenium Webdriver. I am using the selenium-webdriver gem to interact with it. In just a minute, I will show how I have added an additional task to my Rakefile to run the tests.

Also note that a webserver is required to serve the SpecRunner.html file and its dependencies. One could setup a webserver such as Apache but I think it is too much work and creates an external unnecessary dependency for the test runner (every environment where the tests are executed would need to configure an instance of Apache). Instead, I prefer to use the service_manager gem to spin up a simple web server on demand using the python -m SimpleHTTPServer command. With Service Manager, you define services that will be automatically started when the tests begin and stopped at the end. Because Python is widely available, no extra dependencies should be required. For more information, see service_manager documentation on GitHub.

The Rakefile in the end is fairly straightforward:

• Require bundler and some gems
• Start ServiceManager which will spawn the webserver process
• Detect the browser passed as a command line argument
• Instantiate Webdriver and load the SpecRunner.html file
• Capture the output of the ConsoleReporter and display it
• Finally, check the status for success or failure

The complete Rakefile looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

require 'rubygems'
require 'bundler/setup'

require 'selenium-webdriver'
require 'service_manager'


desc 'Run Jasmine tests with Phantomjs'
task :phantomjs do
  # Note: we are assuming phantomjs is installed and available in $PATH
  sh %{phantomjs lib/phantom-jasmine/run_jasmine_test.coffee SpecRunner.html}
end


desc 'Run Jasmine tests with Webdriver'
task :webdriver do
  # Use service_manager to start a simple web server
  ServiceManager.start

  # Detect which browser we want to run
  case ENV['browser']
  when 'chromium'
    # TODO: detect chromium path? I use Linux, this is the path on my machine
    Selenium::WebDriver::Chrome.path = '/usr/lib/chromium-browser/chromium-browser'
    driver = Selenium::WebDriver.for :chrome
  when 'firefox'
    driver = Selenium::WebDriver.for :firefox
  else
    raise ArgumentError, 'Unknown browser requested'
  end

  # Finally, we load the spec runner HTML page with WebDriver
  driver.navigate.to 'http://localhost:8000/SpecRunner.html'
  status = driver.execute_script('return consoleReporter.status;')
  output = driver.execute_script('return consoleReporter.getLogsAsString();')
  driver.quit

  print output

  # Make sure to exit with code > 0 if there is a test failure
  raise RuntimeError, 'Failure' unless status === 'success'

end

To run the webdriver task, just execute rake webdriver browser=firefox. You should see Firefox start and go through the tests. This is what the output looks like:

A remaining step is that I will need to add support for browsers other than Firefox or Chromium, as well as support for remote Webdriver instances (such as Internet Explorer running in a virtual machine).

Breaking stuff

Before wrapping up, I’d like to show a failure example. Let’s break some code by commenting out line 17 of src/Player.js. Running rake phantomjs fails as expected. Notice how I can see the full stack trace which points me to line 33 of spec/PlayerSpec.js.

Wrap up

Phantom.js, Webdriver and Jasmine are a really powerful combo to test drive code. Not only that, they are also really easy to set up. Kudos to the various Open Source contributors behind these projects for providing a great developer experience!

The next step of this adventure is continuous integration. I need to integrate the tests with our Jenkins instance. Hopefully, that should be trivial since I have my tests runner command ready to go.

If you want to see the code, it’s available on GitHub.

What do you think? Do you find this technique useful? What other tips do you use for running your Javascript tests? If you have feedback on this post, feel free to comment below or to contact me via Twitter (@jphpsf).

In this post, I am trying to answer the question by analyzing real numbers from my current job. No tests were written originally and once tests were included, I became a strong advocate of the TDD methodology.

Background

I’ve been a web developer for over 10 years and in 2009 I started to hear a lot about test driven development (TDD). It was then I decided to learn more about it. At that time I had been working for my current employer for about 2 years. Fast forward to today (2012). I’ve now been with my company for 5 years and have spent the last 3 years applying TDD principles.

This is very interesting because today I can look at our bug tracker and gather statistics about the number of defects found over time and see the impact TDD has had on our code base.

A quick word about the software stack: I build a UI based on PHP and Javascript. I am the lead UI engineer, which means if there is a UI bug, I am likely to be the one responsible. The UI interacts with backend C++ services which are leveraging PLSQL code running on Oracle.

The PHP code of the UI is the only area where TDD was applied. Our Javascript code does not have tests (yet). Sadly, no other engineers in the company are practicing TDD. All the other layers of the code base are not unit or functionally tested (the testing is handled by a dedicated QA team post development).

This actually makes it really easy to look at statistics. I can look over time at the number of defects in the UI vs the entire product. That should allow me to answer the initial question, which in context can be rephrased as: does TDD adoption lead to less defects in the UI that I am responsible for?

So does TDD actually work?

The following graph is generated from our bug tracker. It is showing the ratio of bugs in the UI compared to the whole product.

There are a few interesting things to notice:

• First and foremost, we can answer the question: the amount of bugs found in the UI (in green above) has been reduced by about 50% (the UI accounted for roughly 35% of the bugs in the product and today it’s down to hovering around 15%).

• Applying TDD on a legacy code base does not magically change things overnight. I started applying TDD in Q3 of 2009. You can see the number of bugs starting to decline around Q3 of 2010 with a bigger drop in Q3 of 2011. It took nearly 2 years to achieve the 50% drop.

• The graph shows a couple of bumps (e.g. slight increase in bug count) in Q2 of 2010 and Q2 of 2011. Looking at our releases, this corresponds to a time where we added features based on 3rd party maps API that heavily relied on Javascript. As I mentioned previously, we did not have Javascript tests at the time. This also confirms that not writing tests leads to more bugs.

What’s next?

As I said earlier, I started applying TDD to the PHP side of my code. Looking at the bugs I get nowadays, I noticed they usually fall in one of two categories:

• Bugs in our Javascript code (which again is not automatically tested)

• Integration bugs (for instance where independent PHP components are passing unit tests, but are not working together properly)

This leads me to the next obvious step of my testing adventure: I need to add a Javascript test suite as well as a end to end integration testing suite.

This is what I’ve been working on over the summer. For Javascript, I’ve setup a test suite based on the Jasmine BDD framework. For end to end testing, I’ve setup Cucumber. In both cases, I can run the tests using real browsers with Selenium Web Driver or headless using the awesome Phantom.js.

We are about to start our next development cycle and I am looking forward to leveraging this new setup to build higher quality software. I am also looking forward to looking at this topic next year and seeing what impact these tools will have. It will hopefully help to reduce our bug count further.

Also, sharing those numbers with my teammates helped convince some engineers of the benefits of TDD. Engineers working on other services of our product have shown interest and are willing to investigate how they can apply TDD to their codebases. It’ll be interesting to see what kind of benefits they get out of the exercise.

Wrap up

What about you? How did TDD or BDD affect your code base? Do you have similar statistics to share? Feel free to comment below.

As usual, if you have feedback on this post, feel free to leave a note or to contact me via Twitter (@jphpsf).

However, one feature I have been missing is a data provider mechanism. I learned about that feature while using PHPUnit for PHP unit testing. The basic premise of a data provider is to feed a test with multiple test values to avoid repeating your test code over and over.

In this post, I will show you how you can leverage that data provider pattern with Jasmine.

The problem

First, let me explain the problem I am trying to solve. Imagine you have some validation code that must verify a username. A correct username matches the following requirement:

• Must be alphanumeric or underscore
• Minimum of 3 characters
• No more than 12 characters

Positive and negative test cases could look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

describe("username validation", function() {
  it("should return true for valid usernames", function() {
    expect(validateUserName("abc")).toBeTruthy();
    expect(validateUserName("longusername")).toBeTruthy();
    expect(validateUserName("john_doe")).toBeTruthy();
  })

  it("should return false for invalid usernames", function() {
    expect(validateUserName("ab")).toBeFalsy();
    expect(validateUserName("name_too_long")).toBeFalsy();
    expect(validateUserName("no spaces")).toBeFalsy();
    expect(validateUserName("inv*alid")).toBeFalsy();
  })
})

The above test is pretty straightforward: we are testing a method called validateUserName and we are making sure that it returns true for valid values and false for invalid ones.

The problem I have with the above code is the repetition of the same expectation in each of the two it blocks.

DRYing it up

Let’s look at the same 2 tests using the data provider pattern. I came up with the following syntax:

1
2
3
4
5
6
7
8
9
10
11
12
13

describe("username validation", function() {
  using("valid values", ["abc", "longusername", "john_doe"], function(value){
    it("should return true for valid usernames", function() {
      expect(validateUserName(value)).toBeTruthy();
    })
  })

  using("invalid values", ["ab", "name_too_long", "no spaces", "inv*alid"], function(value){
    it("should return false for invalid usernames", function() {
      expect(validateUserName(value)).toBeFalsy();
    })
  })
})

Basically, I wrap each it block with a using block. The using block specifies what values to pass to the it test.

The using function is really easy to implement:

1
2
3
4
5
6
7
8
9

function using(name, values, func){
  for (var i = 0, count = values.length; i < count; i++) {
    if (Object.prototype.toString.call(values[i]) !== '[object Array]') {
        values[i] = [values[i]];
    }
    func.apply(this, values[i]);
    jasmine.currentEnv_.currentSpec.description += ' (with "' + name + '" using ' + values[i].join(', ') + ')';
  }
}

The using function takes 3 arguments:

• name: that is the name describing the set of values
• values: array of values to use for the tests (note that each element in the array can be a simple value or an array of multiple values)
• func: function wrapping the it block

The last line enhances the test description with the name associated with the values (first argument of the using block). It also adds which value has been used for a given test. This will make troubleshooting easier in case of a test failure.

Demo

A demo is usually better for understanding than a long explanation with code samples so I pushed a demo to my GitHub account:

• see the demo
• see the code

Here is a screenshot of the Jasmine output:

Wrap up

I did some research prior to setting this up and I could not find an existing solution. The data provider functionality is standalone and can easily be added to the spec helper file in your project.

What do you think? Do you find this technique useful? What other tips do you use for DRYing up your tests? If you have feedback on this post, feel free to comment below or to contact me via Twitter (@jphpsf).

If you care about web performance, you are likely to know and use tools such as WebPagetest, HTTP Archive, YSlow, Boomerang, etc. Whether your level is novice or expert with these tools, using them is only one side of the coin. What about contributing back to them? Those tools are open source which means you - whether you are a novice or an expert - can help out.

Open source represents one aspect of the web performance community. User group (meetups) focused on web performance are another.

In this post, I will explain how you can get started and get involved in our continuously growing community.

Open Source Contributions

There are many ways one can contribute to performance open source projects. The first common step is usually to find the source repository. This information is typically found on the project’s official website. Look for links such as “Contribute”, “Source Code” or “Fork me on GitHub”. For instance, see the YSlow website, which includes a link to the “Source” in the top navigation as well as a “Fork me on GitHub” banner in the top left corner:

Most open source projects nowadays are hosted on GitHub or Google Code. Here are the repositories for some of the most popular web performance related ones:

• WebPagetest
• HTTP Archive
• Boomerang
• YSlow
• ShowSlow

1. Contribute code:

Now that you’ve located the repository, it’s time to contribute! Do you have an idea for a new feature? Did you find a bug or see an issue in the bug tracker that you can resolve? Implement the new functionality or create a fix and send a patch back to the author (or submit a pull request if the project is on GitHub).

2. Testing and bug reports:

Not a developer or don’t think you have the coding chops? Not a problem. There are other ways to contribute. If you encounter a bug as you use the software, make sure to report the issue in the bug tracker. Chances are that if you encounter a problem, others might as well, but make sure to search the bug tracker first. In addition to bugs, you can submit feature requests or enhancement suggestions. As an example, this is the bug tracker for the HTTP archive project.

3. Help with user support:

Users might encounter issues and in turn will have some questions. A first place to look is the issue tracker. If you see an issue for which you know the solution, feel free to give an answer to the original poster. Other places to look at are mailings lists or IRC channels. Here is some user feedback for the ShowSlow project.

4. Contribute to the documentation or website:

As you read the documentation, report any error you might find. If you have writing skills, maybe you can help? Do you see any mistakes or missing information? Do you have suggestions for new howtos or guides? Write them! Often projects are using wikis which make it easy to add or edit content. If the documentation is not available in your native language, consider translating it. The same can be done for the project’s website: you can help maintain it with new content, corrections, translations, etc. For instance, this is the YSlow user documentation wiki.

5. Give financial support:

Open source projects are often run by individuals on their spare time and personal money. If you want to support the project, donate some money (look for a “Donate” link) or have your company offer to sponsor the project.

6. Live instances:

What about providing hosting? Do you have bandwidth and/or hardware available? Tools like WebPagetest or ShowSlow provide live instances hosted all over the world. Do you have a hosting location to offer? Get in touch! You’ll find the contact information on the project’s website. The following page for instance, gives details about hosting a WebPagetest instance.

7. Thank yous:

A very simple gesture, yet really appreciated by open source developers: express your appreciation and thank them. It’s as simple as a @mention on Twitter, but why not send a nice email or a post card?

These are a few ideas to get started with open source. Still not sure where to start? Just ask where you can help! I am sure the project owners will be happy to indicate where help is needed.

Meetups

Open source projects are an important element of the performance community. Meetups are another great way to participate. There are quite a few performance meetup groups already. Check them out!

Don’t see one close to you? You could start one. I’ve seen three different formats so far. First, the classic tech talk with Q&A: a speaker gives a presentation on performance followed by a Q&A session. Second, the Meet 4 Speed: an open format where attendees can show their work on performance or bring a problem and get help from others. Finally, the drink up: meet over a performance enhancing pint (I shamelessly stole that line from my good friend Aaron) and talk shop with performance people.

Are you or your company working on really cool performance projects? Do you have some results or metrics to share? I love when companies are sharing their success stories (“We implemented the following web performance tweaks and we increased our sales by X%”!). Propose a talk to your local meetup. As an organizer myself, I am always looking for people that have interesting things to share on web performance.

Other suggestions

There are a couple of other suggestions that I think are worth mentioning.

The first is blogging: you can share your knowledge with others on your own blog or as a guest blogger (see the Performance Calendar for instance).

And let’s not forget forums: one example is the forum hosted by the WebPagetest project . This is a good place to find some help on performance or help others.

Wrap up

This is what the Speed Awareness Month is about. Share the #webperf love: evangelize performance best practices, raise awereness and help improve the invaluable tools from our web performance toolbox.

Do you have feedback on this post? Feel free to comment below or to contact me via Twitter (@jphpsf).

Being passionate about web performance optimization, I decided to “eat my own dog food” and look at how I could improve the load time of my blog.

Baseline

I’ve measured the homepage of the blog with my usual weapon of choice, WebPagetest. Using Firefox and Chrome roughly yielded the same results:

• DOM ready fires at about 1.2 seconds.
• The page is fully loaded between 2.8 and 3 seconds.
• There are 21 HTTP requests for a total of 244KB.

Optimizing Javascript

The first obvious improvment is with javascript. The default Octopress installation will load 4 javascript files as shown in the screenshot below:

This is bad because browsers usually have a limit in the number of concurrent downloads they can perform at the same time. While this limit has been increased in the recent years, it is still a good practice to concatenate all the Javascript resources into one file. I created a file under source/javascripts/all.js in which I combined all 4 files. While I was at it, I minified all.js to make it smaller and moved the file from the head to the bottom of the page.

Then I removed the 3 script tags from source/_includes/head.html:

1
2
3

<script src="{ { root_url } }/javascripts/modernizr-2.0.js"></script>
<script src="{ { root_url } }/javascripts/ender.js"></script>
<script src="{ { root_url } }/javascripts/octopress.js" type="text/javascript"></script>

And I added the following to source/_includes/custom/after_footer.html:

1

<script src="{ { root_url } }/javascripts/all.js" type="text/javascript" />

The load time did not change: still around 2.8 seconds. However something broke: the sidebar fails to load my recent tweets because that code depends on some that were moved to the bottom of the page (as explained above). I fixed the dependency and merged all the twitter JS code into all.js. The twitter JS code can be found in source/_includes/asides/twitter.html:

1
2
3
4
5
6

<script type="text/javascript">
  $.domReady(function(){
    getTwitterFeed("jphpsf", 5, false);
  });
</script>
<script src="{ { root_url } }/javascripts/twitter.js" type="text/javascript"> </script>

Disclaimer: this last change might need to be applied to other plugins or sidebar modules. Twitter is the only one I used and after this last change, my recent tweets were back.

Trying to improve the load time further, I decided to load the all.js file asynchronously. The blog content does not depend on any javascript, so it is ok to defer the load to later. I used the same pattern as the Google Analytics snippets, eg. in source/_includes/custom/after_footer.html I now have:

1
2
3
4
5
6
7

<script type="text/javascript">
(function() {
  var all = document.createElement('script'); all.type = 'text/javascript'; all.async = true;
  all.src = '{ { root_url } }/javascripts/all.js';
  s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(all, s);
})();
</script>

This last change brings the DOM ready event to now fires at 0.8 seconds.

Brandon Mathis (the creator of Octopress) mentioned on Twitter his plans to integrate a JS preprocessor (in the same way than Octopress uses compass for CSS preprocessing). I would hope this could include the optimizations mentioned above.

After this change:

• DOM ready fires at about 0.8 seconds (improved by 0.4 seconds).
• The page is fully loaded between 2.8 and 3 seconds (no changes).
• There are 17 HTTP requests for a total of 237KB (saved 4 requests and 7KB).

Optimizing @font-face

Octopress includes the PT Sans font as a default and is including it on the page using @font-face. I noticed a flash of invisible content (see screenshot below). The issue is even more noticeable on mobile devices, which tends to be slower. This is something I noticed on other websites using @font-face as well (Octopress blogs or not).

Paul Irish explains the problem in this 2009 blog post. The flash of invisible content is actually here to avoid a flash of unstyled content (at least for WebKit browsers). When using @font-face, the browser needs to download the font file. If the file arrives late during the page load, then the browser first shows the content without the font applied and switches to using the font as soon as it arrives. This is called a flash of unstyled content (FOUC for short). To work around this issue, WebKit engineers make the content text invisible until the font is loaded. This is better than the unstyled flash, but it is still an issue. To minimize it, the key is to load the font as fast as possible. Removing the @font-face all together is a solution (the fastest font is the one you don’t have to load) but for now I wanted to keep using a custom font, so I started digging.

The first thing I discovered was that I was actually loading 2 fonts (Ubuntu Condensed for the headers and PT Sans for everything else). That’s 25KB and 59KB. One was loaded from my domain the other from Google’s webfont CDN. I removed the Ubuntu font as PT Sans was looking just fine for the headers. Also, PT Sans leverages Google’s webfont CDN. The load time dropped to 2.2 seconds. The DOM ready event fires now at 0.6 seconds. Great! Can we make it even faster?

Looking at my waterfall revealed that the font was loaded late after the DOM ready event. The font download finished at around 1.6 seconds. I am assuming that means the content is invisible until then (more on that later).

Paul Irish’s blog post mentioned another technique: inline the font in the CSS file using data URI. This is a good idea because it removes 2 extra requests (Google’s webfont CDN loads one CSS file and then the font file). Also, a CSS file can be gzipped which can lead to additional savings.

I removed the font face include tags from the source/_includes/custom/head.html and added the following to the sass/custom/_styles.scss file (note: I did not include the actual base 64 content of the font).

1
2
3
4
5
6
7

@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: normal;
  src: local('PT Sans'), local('PTSans-Regular'),
    url('data:application/x-font-woff;base64,[BASE64 FONT CONTENT GOES HERE]') format('woff');
}

DOM ready happens slightly later at 0.8 sec but at this point the font is downloaded. Previously the font was ready at 1.6 seconds. This should improve the flash of invisible content problem.

Are we done with @font-face? No. I noticed an issue in Internet Explorer where the font seems to never load. It turned out to be a great hint for the next step. Data URI length is limited to 32KB in IE8 (according to caniuse.com). Could I find a smaller font? A quick search for PT Sans lead me to Font Squirrel which had the same font as Google webfont. However, it was smaller: 18K instead of 59K. I am not sure where that difference came from. The only difference I could see was visually: while very similar, the Google’s webfont seemed to be more condensed than the Font Squirrel equivalent. In the end, I think the font is fine so I went ahead and added it to the CSS file.

To verify the impact of these optimizations we can use the comparison feature of WebPagetest which includes a film strip view as well as a video comparison service. The film strip screenshot below shows that the optimized version at the bottom, as expected, loads about 1 second faster:

You can view WebPagetest video comparison by following this link.

After this change:

• DOM ready fires at about 0.7 seconds (improved by 0.1 seconds).
• The page is fully loaded in about 2 seconds (improved by 1 second).
• There are 15 HTTP requests for a total of 172KB (saved 2 more requests and 65KB).

Optimizing with Cloudflare

Another thing I wanted to investigate was CloudFlare. I am running this blog behind CloudFlare’s security and performance proxy and was wondering about how the various settings could affect the load time and if CloudFlare was helping my blog to load faster.

I’ve enabled the performance proxy of CloudFlare since day one, so this blog should already benefit from CloudFlare optimizations. To determine the gains, I decided to disable the performance proxy and measure the page speed. I lost about 0.5 seconds on my load time doing so. The main difference appeared to be the size of downloaded content. It grew from 172KB to 248KB. The difference comes from gzipping/minifying assets such as CSS or Javascript. When bypassing the performance proxy, I hit Heroku’s server directly and because I haven’t configured Heroku to gzip or minify assets, it serves unoptimized content. CloudFlare’s performance proxy shaves 0.5 seconds off of the load time, that’s not bad.

WebPagetest pointed out that I was not setting the far expire header properly for my assets. CloudFlare actually takes care of that. The default value is pretty low, it is set to 4 hours. I tweaked it to use the recommended 30 days which improved my caching score on WebPagetest.

Another benefit is the CDN: the assets of my blog are deployed on CloudFlare’s CDN. This is totally transparent to me (I did not have to make any changes to my blog’s code) and is great for performance. The CDN stores content closer to the user hence allowing faster delivery. I am running out of time here, but I guess the impact could be verified with Webpagetest. One can pick various test locations and compare the performance with and without CDN.

The last feature I played with is Rocket Loader. It’s a pretty clever Javascript loader. From what I’ve seen it speeds up a website in two ways. First it makes any javascript files load asynchronously. Second it caches them in the browser’s local storage. Unfortunatelly, when I activated the feature, the comments powered by Disqus stopped working. Rocket Loader is currently under beta, so I guess there are a few things still left to iron out. In the end, I’ve already done some optimization to my blog’s Javascript (previously explained) so I disabled Rocket Loader.

Conclusion

I started with 21 HTTP requests for a total of 244KB and a page loading in about 3 seconds. After optimizations, the page is down to 15 requests for a total of 172KB. The page now fully loads in about 2 seconds.

This experiment was very interesting. The big take away was learning more about @font-face performance implications. I think barebone Octopress out of the box performance is not bad at all: the load time of my blog prior to the changes was decent. Yet, I was able to squeeze a little more speed with a few simple changes. I will contact Brandon Mathis (the creator of Octopress) to see if he would be interested by some of these tweaks. With Octopress being open source, patches are as easy as a pull request ;)

Now it’s your turn! Do you have an Octopress blog? How is your load time? If you try the above tips, do you see any improvements? Do you have any other tips that I might have missed? Contact me via the comment form below, Twitter or the Hacker News thread I’d love to hear from you :)

Update September 2012

After weighting the pros and cons about the usage of @font-face, I’ve decided to remove the custom font I was using. In the end, I value speed more than fancy typography. A basic font like Helvetica is perfectly fine for this blog :)

There are pleny of backup solutions for Twitter. However, it seems that most of them are 3rd party websites and I am not sure if you can automate them easily (to integrate them with a backup script for instance). Wouldn’t it be cool if you could drive this task using only the command line?

Recently, I came accross the Twitter CLI gem. It’s a very powerful tool to query Twitter from the command line. In this post, I will show you how to leverage it to backup your Twitter data.

The t gem

The Twitter CLI gem (also known as the t gem) is an open source ruby gem that you install and use to query Twitter from the command line. It’s a Ruby gem. Gross, right? You have to install Ruby. That’s OK, installing Ruby is actually quite easy: checkout rvm or if you are running Ubuntu, checkout the new Ruby packages from Brightbox.

Once you have your ruby environment up and running, the installation is trivial:

1

gem install t

Once that’s done, if you type t in your shell, you should see the t help screen which lists all the available commands. Configuration will be the next step. You need to authorize t to use your Twitter account. Everything is explained on t’s website, so I will not repeat it here.

You should now be ready to use t. If you want to see some usage examples, jump back to t’s website. It contains some good examples.

Backing up your Twitter account

I want to backup my tweets (timeline), my retweets, my favorites, my direct messages and the list of people I am following.

Using the timeline subcommand I can retrieve all of my tweets. The following command will retrieve the 3000 most recent tweets for my username and save them as CSV in tweets.csv. You have to specify a number as the default behavior is to retrieve only the first 20.

1

t timeline @jphpsf --csv --number 3000 > tweets.csv

The retweets do not seem to be included in the timeline. Here is the command to fetch them. It’s very similar to the previous command. Note that in this case, it does not require you to specify the username

1

t retweets --csv --number 3000 > retweets.csv

The favorites command:

1

t favorites --csv --number 3000 > favorites.csv

For the direct messages, there are actually two separate commands: one for received messages and one for sent.

1
2

t direct_messages --csv --number 3000 > dm_received.csv
t direct_messages_sent --csv --number 3000 > dm_sent.csv

Finally, for the list of people I follow:

1

t followings --csv > followings.csv

Putting it all together

Now that we have the basic commands needed for the backup task, we can put them all together in a shell script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#!/bin/sh
# Simple Twitter backup script

export DAY=`date +'%Y-%m-%d'`

echo "Backing up tweets..."
t timeline @jphpsf --csv --number 3000 > tweets-$DAY.csv
echo "Backing up retweets..."
t retweets --csv --number 3000 > retweets-$DAY.csv
echo "Backing up favorites..."
t favorites --csv --number 3000 > favorites-$DAY.csv
echo "Backing up DM received..."
t direct_messages --csv --number 3000 > dm_received-$DAY.csv
echo "Backing up DM sent..."
t direct_messages_sent --csv --number 3000 > dm_sent-$DAY.csv
echo "Backing up followings..."
t followings --csv > followings-$DAY.csv

echo -e "\nBacked up the following:"
echo -e "- "`wc -l tweets-$DAY.csv|cut -d" " -f 1`" tweets"
echo -e "- "`wc -l retweets-$DAY.csv|cut -d" " -f 1`" retweets"
echo -e "- "`wc -l favorites-$DAY.csv|cut -d" " -f 1`" favorites"
echo -e "- "`wc -l dm_received-$DAY.csv|cut -d" " -f 1`" DM received"
echo -e "- "`wc -l dm_sent-$DAY.csv|cut -d" " -f 1`" DM sent"
echo -e "- "`wc -l followings-$DAY.csv|cut -d" " -f 1`" followings"

echo -e "\nDone\n"

Wrapping up

We now have a very easy way to backup a Twitter account from the CLI. As I am finishing up this post I realize it would be cool to have the backup feature available as a t command. I am thinking about submitting a pull request that would allow something like:

1

t backup -o /path/to/backup

What do you think?

In HTML5, quotes around attribute values are optional. Which means, omit them. Smaller, faster, less clutter.

Here’s an example. This page from GitHub contains about 4,517 quote characters. Most of these can be omitted.
https://github.com/rails/rails/commit/3756a3fdfe8d339a53bf347487342f93fd9e1edb

This is a very specific and interesting performance optimization suggestion. I never really thought about it much or even looked at it to see what kind of performance impact, the omission of quote characters might have on a web page. However, after reading these tweets, I started to wonder: how well is GitHub doing on front end performance?

A quick look at the Chrome dev tools with an empty cache for the GitHub url mentioned above showed a total load time of 5.43 seconds (onload at 3.33 and DOM ready at 1.33s) and an HTTP request count of 73 for a total of 1.36MB. That seemed a little high (for reference, the HTTP archive trends reports an average of 84 requests for a total of about 1MB). As some of you who know me from the SF web performance meetup, I really like dissecting web pages and figuring out what might make a given page slower.

Disclaimer: I do not work for GitHub and I have not contacted GitHub prior to writing this blog post. They might be aware of some of the issues and might be working on the front end performance of GitHub already. In any case, I would love to learn what they think of the following analysis.

Webpagetest

One of my favorite tools in my performance toolbox is WebPagetest. WebPagetest is a front end performance analysis tool that crawls a web page and generates a performance report card. It includes a lot of performance metrics, waterfall charts for first view and repeat view, page speed/yslow type of overview scores, … Also, it runs on a variety of real browsers (you can choose between IE, Chrome, Firefox, etc).

I ran the previous GitHub url and you can see the results using the following links:

• Performance report with IE8
• Performance report with Firefox 11

I tried to run the test with Chrome as well but encountered some issues with SSL in WebPagetest (I haven’t looked at the problem at this time and I am not sure if the issue is with Chrome or WebPagetest).

Let’s dive in!

Javascript blocks rendering

The problem

According to WebPagetest, the rendering starts pretty late (at around 6 seconds in Firefox and 3 seconds in IE).

In most browsers, a javascript <script> tag will block rendering as the browser is loading and parsing the javascript code. The reason for this is fairly simple: a javascript file might include code that could modify the HTML document via a document.write() for instance (boooh, don’t do that) or any other DOM manipulation technique. As this might affect the rendered page, browsers usually stop any rendering activity while parsing and evaluating javascript.

If you look at the waterfalls, the rendering start on GitHub is delayed by 2 javascript files (from the file name it seems that one is the jQuery source code and the other is the actual GitHub javascript code).

Solutions

The 2 <script> tags are located at the top of the HTML document in the head. A performance best practice recommends to place the javascript <script> tags at the bottom of the HTML document (right before the </body> closing tag) in order for the browser to start parsing the file as late as possible.

Another approach could be to use an asynchronous script loading technique (via a script loader such as LABjs or ControlJS; a custom solution as described here would work too).

This should allow the page rendering to start sooner.

Reduce the size of downloads

The problem

WebPagetest is accounting for 1,425KB of data transferred. That is quite a lot.

The worst offender in GitHub’s case seems to be the Gravatar 3rd party service. Gravatar is a popular service that allows to show a personal avatar for users of the interweb based on their email address. In the case of that GitHub page, Gravatar is loading 34 images for a total of 500KB. That is more than a third of the payload.

The second worst offender is the host called camo.githubapp.com. It seems to be serving 2 images in our example. At first, I was a bit puzzled about that host as I could not quite figure out why GitHub was serving directly 2 images worth 500KB (that is another third of our total payload) instead of using their CDN. After a bit of research I found the Camo project. GitHub is enforcing SSL for every page. When GitHub users write comments and insert funny cat pictures to illustrate their point, the said cat pictures might be served from a non SSL host. This will cause a nagging mixed content warning from the browser. Camo is basically an SSL image proxy that solves the issue. See more on this blog post. Note that one of the 2 images is taking 7 seconds to load.

Solutions

We have about 1,000KB of images. A common practice is to compress and optimize images. There is a lot of tools out there for that purpose. WebPagetest performance review tab estimates that some of the images can be compressed and save about 40KB. Note that it does not include one of the largest images, which is a animated gif proxied through Camo. I sent the gif to Smush.it and it came back 50KB lighter. Bottom line: potential savings would be around 10%. Compressing images might not be easily achievable. I don’t think it would be a good idea to compress them on the fly (it would take some extra CPU resources to do that through Camo for instance). A better approach might be to have the image compressed at the source (in the case of Gravatar, when a user uploads an avatar). That would probably require a significant effort and I am not sure it’ll be worth the gain.

An alternative could be to implement asynchronous image loading. When you first load the GitHub page, none of that content is visible (all the images are below the fold). Knowing that, the HTML page could be generated with a placeholder for the image which would be loaded later on via javascript. The javascript could be listening for scroll events and monitor the visibility of the images in order to decide when to load them. Pamela Fox wrote about that not long ago. You can also see the technique in action on Meetup’s website (for instance visit this meetup page and look at the sidebar with the list of attendees while you scroll). Note that for users browsing with javascript disabled, they would miss the images. I am not sure that would be a deal breaker as I am assuming most of GitHub users have javascript turned on.

Reducing the number of HTTP requests

The problem

WebPagetest shows 71 HTTP requests. Trying to reduce those numbers is usually a good idea. There is always some overhead with HTTP request, so the less you do, the better it is.

I mentioned earlier the presence of 2 <script> tags in the head. I am wondering if there is a specific reason for them to not be combined together. The same goes for the CSS stylesheets (github-xxxx.css and github2-xxxx.css).

GitHub uses some sprites which is good and avoids some HTTP requests. I am wondering if GitHub would see any gain by combining sprites together (aka über-sprite ). I am looking at the various icons in the png files (in WebPagetest, under the waterfall, click the link “View all Images”). It looks like mini_button_icons.png, repostat.png, public.png, file_modes.png, jump.png, diffstat.png… could all be combined into one.

Some pages include several individual icons which could be sprited. For instance a github profile/dashboard page has all the timeline icons in individual files (pull_request.png, push.png, fork.png, issues_closed.png, issues_comment.png, watch_started.png, etc).

Solutions

Well, I guess I spoiled that one. You’ve read it above. Combine all the things!s

The double sometimes quadruple logo

The problem

In the waterfall for Firefox, you can see 2 logos being loaded (the regular black version and the alternative hover version in blue: logov7@4x.png and logov7@4x-hover.png).

In the waterfall for IE, you’ll notice something interesting: GitHub is loading 4 logos! It is loading a smaller version (both regular and hover) as well as a higher resolution one (I am assuming given the 4x in the filename that is intended for retina displays). It seems to be a bug in the code. The smaller logos are enclosed in a conditional HTML comment targeted at IE. The conditional has an if branch but not a else branch. So when the browser is not IE, the if branch is ignored and the high resolution logos are used. But when the browser is IE, the if branch is executed loading the smaller logos. Then the high resolution logos are loaded as well. I am actually wondering why does IE need the smaller logos? Are the higher resolution logos not suitable for IE?

Solutions

The change between regular and hover is done with a CSS :hover rule that tweaks the logos opacity to 0 or a 100 to hide or show the desired version. The two version of the logos could probably be sprited together and used as CSS background image instead of inline <img> tags. Another approach: always load the regular black logo and lazy load (or preload) the hover logo via javascript. The hover effect could be achieved via javascript as well.

For the issue specific with the IE conditional comment, maybe look at removing the conditional comment all together.

Caching issue with IE over SSL?

The problem

With Firefox, WebPagetest summary shows 82 requests and 1,420KB for the first view. The repeat view seems to be using caching and performs only 12 requests for a total of 65KB. Great!

With IE however, WebPagetest shows that a repeat view executes 45 requests for a total of 1,329KB (first view was 71 for 1,425KB). Looking at the various requests details (click on a filename in the waterfall), I can see that a far future expire header is set as well as the Cache-Control header for max-age. According to this page on MSDN, this might be a known issue with IE (or more accurately with WinINET)

Epic pull requests can be big

The problem

Some pull requests on GitHub can affect a lot of files and generate a really long diff. Take this one for instance. Look at the diff. It generates an HTML document of 18.48MB (1.05MB gzipped). It takes 10 seconds in Chrome before getting the first byte of that page.

Solution

This is a tough one. My first thought would be to look at asynchronous requests and reusing the viewport visibility trick mentioned above. Generate the diff skeleton without the diff content for each file. Then, use pjax to load the diff of each file. pjax could be triggered in 3 cases: First, after the initial page load, the diff of each file could be loaded one by one. Second, if a user clicks a specific file anchor at the top, then immediately load that diff via pjax. Third, as the user scrolls up or down the page, maybe some javascript code could detect which diff is visible and load it via pjax?

Closing words: A note about performance metrics

You know the saying “Premature optimization is the root of all evil”. Related: don’t optimize without measuring first.

Measure. Optimize. Monitor. Rinse & Repeat.

The above analysis is looking at a very specific page but it was chosen fairly randomly from a tweet.

A better and more proper approach would be to setup first some kind of real user monitoring (such as Boomerang, New Relic or the new Torbit Insight) and find which pages are the worst offenders. Then start optimizing. After that, monitor the performance metrics and see if the optimization works as expected and if metrics are improving.

Monitoring is one thing, but using web analytics in addition to performance metrics is also important to help drive optimizations decision. For instance, let’s imagine that GitHub’s visitors using IE represents less than 1% of all GitHub’s visitors. In this case, fixing the issues specific to IE (such as double logo or SSL caching) might not be the most important optimization. Now, let’s imagine that GitHub’s visitors are in 99% of the case repeat users. At which point, they might be visiting GitHub with a primed cache (which would include assets such as avatars and icon images).

In the end, is GitHub slow? I actually don’t think so. When I use GitHub, I don’t have a perception of slowness or lag. Perceived performance is an important concept to consider (by opposite to the hard numbers discussed above, which tend to say “GitHub is slow”). Yet, I am wondering what would be the performance business case for GitHub? Even if GitHub does not feel slow, faster is always better. In the case of e-commerce websites or search engines, there is a direct correlation between performance and revenue (Amazon, Bing, Google, Walmart, they all shared numbers over the past few years). In the case of GitHub, what is the performance business pitch? Would a faster GitHub translate to more users? Would that then drive more revenue?

Thanks to Ryan Bigg for reviewing this post and providing great feedback.

This was a very interesting and enriching experience. I never thought I would have enjoyed writing so much. Not only that, I also really liked the preparation phase (researching and gathering the information I needed for my post). Finally, I liked getting some feedback after publication.

Earlier this year, my wife and I were chatting about our year 2011, looking back at it and discussing what we wanted to accomplish in 2012. One item on my list was: starting a blog. I enjoyed writing a guest post enough that I wanted to make it a recurring habit. Better get going!

So here we are, April 2012, introducing my blog “Tech talk with a french twist”. You can expect to read about web development in general and web performance in particular. I am also thinking to post book reviews (both technical and non-technical). Occasionaly, I may talk about gadgets or life in general.

Welcome to my blog, I hope you’ll enjoy the reading.

* If I recall properly, I have been using Intenet since 1999 and reading blogs since 2004/2005.