Giveaway: O’Reilly Velocity Conference Ticket

By  on  

A few months back, O'Reilly was awesome enough to throw me two tickets to giveaway for the upcoming O'Reilly Velocity Conference, the popular front-end performance event in Santa Clara, CA, US from June 24th-26th.  People seemed pretty excited about the giveaway and loads of people entered to win.  O'Reilly noticed that and decided to give me one more ticket to give away.  Excellent!

Since I'm giving you something, you need to give me something too.  So...want to win the last golden ticket to O'Reilly Velocity Conference?  Post a comment below containing a small front-end performance trick you've learned.  It could be an optimized loop, a CSS efficiency, or anything else.

So teach me something and you may win a ticket to Velocity!  Good luck!

If you'd like to sign up and not risk winning the free ticket, use discount code AFF20 and this link.

Recent Features

Incredible Demos

  • By
    MooTools CountDown Plugin

    There are numerous websites around the internet, RapidShare for example, that make you wait an allotted amount of time before presenting you with your reward. Using MooTools, I've created a CountDown plugin that allows you to easily implement a similar system. The MooTools JavaScript The CountDown class...

  • By
    Sliding Labels Using MooTools

    A week back I saw a great effect created by CSSKarma: input labels being animated horizontally. The idea is everything positive: elegant, practical, unobtrusive, and requires very little jQuery code. Luckily the effect doesn't require much MooTools code either! The HTML A...


  1. Andrew Hahn

    If using a CSS preprocessor, be sure to use sourcemaps when developing/debugging your CSS. It speeds up your development atleast two fold! Google has a good round up on source maps here:

  2. Utilize browser idle time to download or prefetch documents that the user might visit in the near future:

  3. Everyone uses loop caching:

    for (i = 0, len = arr.length; i < len; i++) {
      // do something

    but it’s actually MUCH faster to define the caching outside the loop:

    var i = 0, len = arr.length;
    for (i; i < len; i++) {
      // do something

    A jsperf test I created:

  4. Optimizing perceived performance could be a nice thing to do beyond the usual YSLOW/PageSpeed performance golden rules. Examples:

    1) Optimistic UI: imagine you have a UI where the user stars something as favorite. Maybe that would send an XHR request to the server and on success change the icon from a grayed out star to a yellow star. Instead of waiting for the success XHR response, swap the icon right away. It will feel to the user that the action worked instantly. Drawback: if XHR call fails, you’ll have to handle the situation in a specific way eventually.

    2) Change ordering of execution: I’ve seen this case where a device would boot up to a login screen in about 30 sec. Once the user login, a few more init steps would occur for a few seconds then the UI would show up. Move the init steps before the login screen if possible. The login operation would feel much faster. The boot time was already long, so the user will eventually not see the difference there.

    3) Have the UI react to user actions ASAP: I guess this is similar to number #1 but imagine you have this UI where you need to open a dialog and fetch data with XHR. If you wait for the XHR response to open the dialog, then the dialog might show up with delay. Instead, open the dialog right away with an animated spinner. Then as soon as XHR response comes back, add the content to the dialog. Chances are that it will feels faster.

    4) Speaking of spinners and other progress bar, tweak the animation to make it feel faster. I can not remember where I saw that but there was this tip where adding some effect to a progress bar such as easing instead of linear progress would make it feel faster.

    Fun stuff!

    Cheers :)

  5. Sales
    CSS: transform: translate3d(0,0,0);

    Better scroll on devices

  6. Agustin

    Inlining your css can make your website to start render earlier.

  7. Used the object allocation tracker in Chrome to more easily find memory leaks:

  8. Let’s say you need to set the property “x” to object o.x.
    The result should be o.x.x, but “o” may be an “empty” object {}, so, you need to check it, and if so, create the first x attribute.

    Something usually done like this:

    var o= {},
        i= "x"; // we could pretend we are inside a loop here
    if (!o[i]) {
        o[i] = {};
    o[i].x = 'x';

    But there are so many ways to do so, what is the fastest one? Specially when you do it inside a long loop?
    We had a long discussion about it around here, and these are the results and alternatives:

  9. You can add a ::before to the with to optimze font render.

    html:before { /*only one : so it works also on IE8*/
    font: 0/0 ‘myFont’;
    content: ‘load now!’;

    This happens because, even though CSS is loading your font at top, the browser renderer waits until it reads an element that needs it to add font rendering to the DOM.

    Doing that may prevent you FOUT issues, because you’re adding the font-family before actually needing to show it.

  10. Manoj T

    1. Simple checker code for Anagrams.

    function isAnagram(a,b){
      function _(s){return s.toLowerCase().replace(/[^a-z]+/g).split('').sort().join()}
      return _(a)==_(b)

    2. To display fonts optimally on all devices.

    html { 
     -webkit-font-smoothing: antialiased; 
     -moz-osx-font-smoothing: grayscale; 
     text-rendering: optimizeLegibility; 
  11. Frank van Gemeren

    Minimizing HTML code by changing extra class-attributes to a more complicated CSS solution doesn’t help:


    vs a cleaner HTML, at expense of more CSS (or CSS depth) (CSS not shown)


    The reason is, in hind-sight, obvious: the gzip compression on the HTML sees mostly the same content, so it’s able to optimize all the bytes that the classes take up away. The gains for removing all that HTML is less than 1% over the wire. And you lose a lot of flexibility.

    This was counterintuitive for me at first, because a cleaner HTML should be faster, right? Apparently not necessarily.

  12. Colm Morgan

    When working with page-specific stylesheets in Sass, create a config folder to house all your variables, mixins, functions etc. These can easily be imported at the beginning of each page-specific stylesheet.

    Essentially, only non-compiling CSS should be included in the setup folder so that compiled CSS is not duplicated throughout your website of application:

    @import 'variables';
    @import 'functions';
    @import 'mixins';
    @import 'lib/3rd-party-helpers';
    @import 'setup/index';
    // other rules can then follow, and still use mixins etc. as dependencies
  13. Regarding CSS performance, what helps most is putting guidelines, processes, etc. in place, because it doesn’t matter how optimised your CSS definitions are or what CSS processors you use, if you don’t delete stuff you’re no longer using you’ll end up with ginormous CSS files that need to download to the end user (blocking rendering)

  14. I learned the hard way how much better-performing jQuery’s $.when is when compared to synchronous API calls.

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!