This week the developers were again in attendance of the years first Vancouver JavaScript Meetup (VanJS), this time on making the mobile web faster and to take a look at a JavaScript based event library.
Robert Hurst first introduced us to LucidJS, his own personal open source project, an event emitter library similar to jQuery Promises, Node.js Events, or the Backbone.js Event module.
LucidJS: Listen, Bind, and Trigger
LucidJS offers a variety of advanced event features that are hard to get from other more widely utilized libraries. Supporting both Node.js as well as the browser, this library allows you to build your own custom event emitters. There is also support for events which have already fired before being bound, preventing your listeners from asynchronously missing out on any events. It offers the ability to create sub events, making for clean event organization and namespacing, as well as event piping, which lets you centralize and aggregate your event emitters. Finally with support for both DOM and object augmentation you can turn any DOM element or object into an emitter. Finally the whole library is quite lightweight, weighing in at just under 6KB.
You can check out the slides from Robert’s presentation if you’re interested in finding out more.
So how can we utilize LucidJS in our software today? Currently we utilize the Event module from Backbone.js to bind and trigger custom named events. As we also use many of the other features the Backbone library offers, I can’t see us switching over to LucidJS in the near future. Down the road however, if we were interested in performing more complex event handling, LucidJS would definitely be worth checking out.
Next Peter McLachlan of Mobify joined us to talk about why mobile performance still matters, even though device CPU speeds and bandwidth are improving, and what we as developers can do about it.
Performance And The Mobile Web
Right now mobile traffic is an increasing trend. As devices become more powerful, more popular, and more common, the amount of mobile users on the web will also increase. Peter predicts that by the end of this year we could see at least 30% of all web traffic coming from a mobile device. Looking forward, responsive designs is where the web is headed. But this is just the tip of the iceberg that is known as the “mobile friendly web”. Taking this a step further would include building adaptive websites for our mobile audience. An adaptive site is everything that a responsive site is (clever CSS and media queries), however it adapts to suit the device that is viewing the site accordingly. This can mean advanced feature detection, special performance considerations, conditional loading of assets, a dynamic content strategy, and even touch optimizations.
So whats making sites slow on the mobile web?
Latency is the end all be all for mobile devices. Data from Amazon suggests that there is a 1% loss in sales for every 100ms in latency. For example, an eCommerce site serving a global customer base without a CDN can translate into a 5 second delay, resulting in a 50% loss in sales. Aspects such as the location of the web server, lack of compression, excess requests, large asset sizes, and even poor use of the device’s radio hardware can contribute to an overall slow user experience.
Next, once all the code has been delivered to the device, issues such as parsing lengthy HTML, rendering JavaScript (which is currently 10x slower on mobile devices), handling complex CSS selectors, or DOM modifications can severely slow down the device’s browser and eat up CPU cycles.
Well, how can we make sites faster?
First off, taking an existing design/website and making a smaller mobile design out of it is hard. Using a mobile first design approach makes it much easier to have a mobile site, and it becomes much easier to design desktop versions later as the space constraints are relaxed. This is an approach we have recently adopted here at ESL Explorer, and we can also confirm this has been our experience as well.
Next by following some tried and tested optimization strategies, such as removing unnecessary resources, compressing assets (gzip, minify, concatenation), utilizing a content distribution network, and intelligent caching to name a few, we can reduce the amount of data that needs to be transferred to the client.
Peter also suggests avoiding some practices that have now become “anti-patterns. Such practices as domain sharding, large library dependencies, naive lazy loading, and placing blocking JavaScript at the top (head) of the document should all be avoided.
Two other optimizations which are not as well known yet, but are worth thinking about both involve intelligently predicting when the user is about to perform an action, and where they are about to navigate to.
First by prefetching a page we believe our user is about to navigate to we can decrease the users perceived loading time. Although this should be practiced with care, by always ensuring that there is a high probability that the user will end up navigating to the prefetched page, we can ensure we are not requesting unnecessary resources. Fetching too many predicted pages can end up doing more harm than good in the long run.
Secondly by using intelligent radio warmup we can ensure that the device is in a high bandwidth state, eliminating the latency caused by powering up the radio. This can be implemented by simply pinging the server just before the user is about to make a request. This works well in situations where the user has fully filled out a form which is valid and ready to submit. The radio on the users device would of gone into an idle state while they were filling out the form, so hitting the server will power the radio up for them, and their next likely course of action is to submit the completed form.
Peter’s slides are up online for those of you who were unable to attend the event.
It was great to see everyone again, and a special thanks to everyone that makes these meetups happen. To find out more about future JavaScript meetups in the area check out VanJS on Meetup.
