Giveaway: O’Reilly Velocity Conference Ticket
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.
One major problem with creating UI components with the MooTools JavaScript framework is that there isn't a great way of allowing customization of template and ease of node creation. As of today, there are two ways of creating:
new Element Madness
The first way to create UI-driven...
MooTools has always gotten a bit of grief for not inherently using and standardizing namespaced-based JavaScript classes like the Dojo Toolkit does. Many developers create their classes as globals which is generally frowned up. I mostly disagree with that stance, but each to their own. In any event...
The Firefox Marketplace is an incredibly attractive, easy to use hub that promises to make finding and promoting awesome HTML5-powered web applications easy and convenient. While I don't work directly on the Marketplace, I am privy to the codebase (and so...
Cocoon
I love canvas, I love interactive demos and I don't think I have ever been more impressed by somebody's work than when I discovered what Tiffany Rayside has created on CodePen. So I had to start off with one of her interactive canvas pens, even though...
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.
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
Everyone uses loop caching:
but it’s actually MUCH faster to define the caching outside the loop:
A jsperf test I created: http://jsperf.com/browser-diet-cache-array-length/11
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 :)
Better scroll on devices
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
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
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:
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
You can add a ::before to the with to optimze font render.
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.
1. Simple checker code for Anagrams.
2. To display fonts optimally on all devices.
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.
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:
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)
I learned the hard way how much better-performing jQuery’s
$.when
is when compared to synchronous API calls.