Giveaway: O’Reilly Velocity Conference Ticket

Discussion

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: https://developer.chrome.com/devtools/docs/css-preprocessors.
2. Laura

   Utilize browser idle time to download or prefetch documents that the user might visit in the near future: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ
3. Dan

   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: http://jsperf.com/browser-diet-cache-array-length/11
4. JP

   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.

   https://speakerdeck.com/patrickhamann/css-and-the-critical-path-cssconf-may-2014?slide=32
7. Markus Kohler

   Used the object allocation tracker in Chrome to more easily find memory leaks:
   https://developer.chrome.com/devtools/docs/javascript-memory-profiling#object-allocation-tracker
8. Felipe N. Moura

   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:

   http://jsperf.com/ifs2/8
9. Átila Fassina

   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:

    foo1
    foo2
    foo3
    foo4
    foo5
    foo6
    foo7
    foo8
    

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

    foo1
    foo2
    foo3
    foo4
    foo5
    foo6
    foo7
    foo8
    

    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:

    `setup/_index.scss`
    
    @import 'variables';
    @import 'functions';
    @import 'mixins';
    @import 'lib/3rd-party-helpers';
    
    
    `main.scss`
    
    @import 'setup/index';
    ...
    ..
    .
    
    // other rules can then follow, and still use mixins etc. as dependencies
    
13. Juanjo

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

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