Skip to content

Instantly share code, notes, and snippets.

@s3thi
Created August 22, 2016 11:25
Show Gist options
  • Save s3thi/a4badcb2c48dd17f3318afd468224cb0 to your computer and use it in GitHub Desktop.
Save s3thi/a4badcb2c48dd17f3318afd468224cb0 to your computer and use it in GitHub Desktop.

Motivation

  • Most of abof's traffic is mobile (true for most e-commerce companies in India)
  • Old website took ~20s to load on 3G, which killed conversion rates
  • We got it down to <5s, increasing conversion rates by 40%

Part 1: Building abof.com

  • Choosing a tech stack
    • The competition: React, Angular, Angular 2, Riot, Vue
    • Evaluation criteria: speed, size (minified + gzipped), support for isomorphic rendering, community size and availability of resources, tooling
    • The winners: React, Redux, Webpack, SASS, Babel, plus a small number of supporting libraries
  • Architecture
    • REST API powered by IBM WCS, heavily optimized and cached
    • The webapp is an API consumer, just like the mobile apps
    • We pre-render the initial page (with the site header and about 12 products) on the server to ensure first paint is really fast
    • The pre-rendered page is cached by the CDN
    • So are all other resources (product images, JS, CSS)
    • Icons are SVG, and inlined into the page
    • User-specific information (shopping bag, username, etc.) is fetched asynchronously after page load
    • Trackers, third party libraries, images, etc. are also fetched asynchronously after page load
    • We only send the bare minimum content required to display the product page down the wire
  • Project organization
    • Smart vs. dumb components
    • Building reusable React components
  • Keeping dependencies in check
    • Why?
    • How?
  • Handling data on the front-end
    • Redux vs. others
  • Pre-rendering walkthrough
    • We use koa.js, but anything will work (Express, raw Node, etc.)
    • How pre-rendering works in a React application
    • Common pitfalls and challenges
    • Advantages/disadvantages
  • Performance profiling
  • Testing on real devices
    • Why bother?
    • Forget numbers, just eyeball it
    • Unngh UCBrowser
  • Deployment
    • Server and client bundles
    • Deployment stack
    • Proxying cross-domain requests
    • Additional caching
    • Sharing configuration across API clients

Part 2: Why Build for the Web?

  • The business case
    • Every consumer computer ships with a web browser
    • Zero friction conversions, just give your users the URL
    • Updates on the web are instant
    • The user experience has caught up (see pokedex.org for what a modern webapp looks like)
    • Push notifications for repeat engagements
  • The technology perspective
    • APIs for offline access, push notifications, background sync, smooth animations
    • Tooling has caught up, is better than native in some cases
    • Common issues are being actively addressed (e.g, passive event listeners, intersection observers)
    • JavaScript is all grown up (ES6, ES7)
    • Fast-moving, exciting, fun!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment