JSFoo 2017

JSFoo is a conference about JavaScript and everything related.

Nikhil John

@nikjohn

Developing Websites for Low Bandwidth Markets

Submitted Jun 2, 2017

Does your website work everywhere in the world? How about developing countries? Bangladesh, India, Sri Lanka, Pakistan?

Internet is slow and expensive in the developing world, and devices not as powerful. Consequently a lot of modern web applications simply fail in these markets, which means they miss out on almost a Billion potential users.

This session will deal with how to:

  1. Develop for slow network connections
  2. Deal with proxy browsers (Opera Mini, UCBrowser etc.)
  3. Factor for legacy and low performance devices (Feature phones, older smartphones etc.)

during Archtecture, Development and Testing. Topics covered will include

  • Progressive Enhancement
  • Adaptive Web Development
  • Performance Monitoring

Outline

The Issue with Low Bandwidth Markets (LBMs)

Low Bandwidth Markets are areas where network speeds are slow, latency is high, and are often developing nations in the Indian Subcontinent, South East Asia, South America and Africa

  • Most websites are built and tested on high speed internet. Chances are that these applications would fare poorly or fail completely in Low Bandwith Markets.
  • LBMs have over 1 billion users, 40% of all internet users. But these markets have an average speed of less than ~4 Mbps.
  • Mobile web is even slower, adding to the problem. Mobile devices are also often older and less performant owing to low purchasing power, and legacy technology.
  • Data is also often expensive, pushing the use of proxy browsers (Opera Mini and UCBrowser) that strip CSS and Javascript before serving pages, making them unpredictable.
  • These factors cumulatively make the web User Experience notoriously horrible in these markets, keeping the web away from millions of people.
  • Bad UX means higher bounce rates. Ergo, a number of popular websites are missing out on massive revenue due to this often unaddressed problem.

Is it for everyone?

  • Not every website needs to cater to LBMs, but page load performance is should always be top priority.
  • Solid performance drives User Retention. So even if LBMs aren’t your primary concern, good performance ought to be.

Assessing the state of your Website

  • Run Analytics: Which countries do your users come from? What devices do they use? What browsers do they use?
  • Monitor Performance: Get an idea of how fast your website loads, through tools like NewRelic or DynaTrace.

Issue #1: Giant Web Applications, commonly > 5MB don’t load

Issue #2: Single Page Applications do everything client side

Issue #3: Proxy Browsers trim Javascript, CSS and large network requests

Issue #4: Javascript is often disabled

So what’s the solution?

There is no one all encompassing solution

  • The aim of the Web Architect should be to attain the delicate between Feature richness, Performance and Time to Market
  • Performance should be constantly monitored, and performance bugs should be seen as at par with others.
  • Have performance sprints

Architecture

  1. Progressive Enhancement and PWAs (Progressive Web Applications)
  • These are Connectivity independent, safe and installable applications
  • Universal Javascript is the future
  1. Adaptive Web Development
  • This uses static layouts based on breakpoints which don’t respond once they’re initially loaded.
  • Not ideal, but if push comes to shove and you need your app to work on a feature phone, you might need to serve out a different page altogether
  1. Server Side Rendering when possible
  • Sometimes, you don’t need Single Page Applications. A simple server redered static website would do.
  • Static sites work across browsers, network conditions, geographies and require little to no Javascript. If you can make do with one, then your work is cut out for you.

Development

  1. Develop mobile first - it always helps with perf
  2. Best Practices - Trim, Bundle, GZIP and Tree Shake your code to make it lean.

Testing

Testing should be done on

  1. Real devices
  2. Real networks

Monitoring

  1. Performance should be constantly monitored, and performance bugs should be seen as at par with others.
  2. Performance Sprints between regular development cycles

Requirements

This talk does not have any prerequisites. Some background in Javascript will be useful, but even non-technical folks will find this.

Speaker bio

Nikhil is a freelance Web Engineer with Six years of experience developing Responsive and Adaptive Web Applications, with frameworks such as ReactJS, AngularJS, EmberJS, BackboneJS, ExpressJS for Deloitte Digital, Saltside.se, Creatubbles.com and Mobi Corp.

Slides

http://slides.com/nikjohn/deck-3/fullscreen#/

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

JSFoo is a forum for discussing UI engineering; fullstack development; web applications engineering, performance, security and design; accessibility; and latest developments in #JavaScript. Follow JSFoo on Twitter more