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

  • By
    JavaScript Promise API

    While synchronous code is easier to follow and debug, async is generally better for performance and flexibility. Why "hold up the show" when you can trigger numerous requests at once and then handle them when each is ready?  Promises are becoming a big part of the JavaScript world...

  • By
    CSS Animations Between Media Queries

    CSS animations are right up there with sliced bread. CSS animations are efficient because they can be hardware accelerated, they require no JavaScript overhead, and they are composed of very little CSS code. Quite often we add CSS transforms to elements via CSS during...

Incredible Demos

  • By
    Face Detection with jQuery

    I've always been intrigued by recognition software because I cannot imagine the logic that goes into all of the algorithms. Whether it's voice, face, or other types of detection, people look and sound so different, pictures are shot differently, and from different angles, I...

  • By
    Telephone Link Protocol

    We've always been able to create links with protocols other than the usual HTTP, like mailto, skype, irc ,and more;  they're an excellent convenience to visitors.  With mobile phone browsers having become infinitely more usable, we can now extend that convenience to phone numbers: The tel...


  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!