$30 off During Our Annual Pro Sale. View Details »

Next Gen Web: Scaling Progressive Web Apps

Next Gen Web: Scaling Progressive Web Apps

A case study of how we re-built Flipkart.com's desktop website as a progressive web app while dealing with the unique challenges of scaling to a new ecosystem without compromising on performance.

Abhinav Rastogi

September 15, 2016
Tweet

More Decks by Abhinav Rastogi

Other Decks in Technology

Transcript

  1. The Next-Gen Web
    Abhinav Rastogi
    @_abhinavrastogi
    A case study of how we re-built Flipkart.com

    View Slide

  2. View Slide

  3. Flipkart Lite
    Service Worker, App Shells
    Progressive Web App

    View Slide

  4. Probably the first

    mobile -> desktop
    migration!

    View Slide

  5. Significant Differences
    Mobile vs Desktop

    View Slide

  6. Requirements
    User Behaviour
    Network Conditions
    Device Capabilities
    Browser Fragmentation

    View Slide

  7. Typical SPA
    • Serve empty HTML from server
    • Client downloads JS bundle
    • Shows loaders, makes API calls
    • Renders full page
    • Subsequent navigations are client-side

    View Slide

  8. Typical SPA
    • Serve empty HTML from server
    • Client downloads JS bundle
    • Shows loaders, makes API calls
    • Renders full page
    • Subsequent navigations are client-side
    Pros:
    • Easy to implement
    • Fast navigations
    • Cheap server processing
    • Low server QPS

    View Slide

  9. First Paint +
    Full Render

    View Slide

  10. Cons:
    • Empty page for a long time
    • SEO jeopardised
    • JS bundle is huge

    View Slide

  11. Upgrade #1 - App Shells
    Initial HTML renders ‘loading state’

    (Build-time rendering)

    View Slide

  12. Upgrade #1 - App Shells
    Initial HTML renders ‘loading state’

    (Build-time rendering)
    Pros:
    • No more empty page!

    View Slide

  13. Full Render
    with content
    First Paint
    (Loading state)

    View Slide

  14. Cons:
    • Stuck in “Loading” state
    • First-paint is not meaningful content

    View Slide

  15. Update #2 - Server Render
    • Render full page on server for first request
    • Client loads JS, makes API calls
    • Re-renders complete page

    View Slide

  16. Update #2 - Server Render
    • Render full page on server for first request
    • Client loads JS, makes API calls
    • Re-renders complete page
    Pros:
    • First paint is meaningful
    • SEO is solved!

    View Slide

  17. Client Render +
    Interactive
    First Paint +
    Full Render

    View Slide

  18. Cons:
    • Significant increase in server load
    • HTML download size increased
    • Response time increased
    • JS file is still huge

    View Slide

  19. Update #3 - Universal app
    • Render only SEO-critical content on server
    • Client continues to work as normal
    • React is able to reconcile the DOM

    View Slide

  20. Update #3 - Universal app

    View Slide

  21. Update #3 - Universal app
    Pros:
    • Lesser load on server
    • Better SEO, smaller HTML
    • Header/Footer can load
    quicker :: Perceived perf!
    Cons:
    • First paint still slow
    • No organic content in first-
    paint
    • JS file is still huge

    View Slide

  22. Update #4 - First-fold
    Render above-the-fold content also on the server

    View Slide

  23. Update #4 - First-fold
    Progressive
    Images!

    View Slide

  24. Update #4 - First-fold
    Pros:
    • Making API calls from
    server is better
    • Organic content in first
    paint!
    • Send api data as part of
    HTML

    View Slide

  25. #5 - Route based chunking
    • Break JS bundle into parts based on routes
    • Only load JS required for the current page
    • Subsequent JS can be loaded when needed

    View Slide

  26. #5 - Route based chunking

    View Slide

  27. Break JS bundle?
    • Define “split-points”
    • Replace “import” with “require.ensure”
    • Webpack & React-Router take care of the rest!

    View Slide

  28. View Slide

  29. View Slide

  30. Full Render
    with content

    View Slide

  31. Typical HTML page

    View Slide

  32. Update #6 - PRPL
    • Push critical resources for the initial route.
    • Render initial route.
    • Pre-cache remaining routes.
    • Lazy-load and create remaining routes on demand.

    View Slide

  33. Basic Preloading

    View Slide

  34. #7 - HTML streaming
    • Some parts of html are independent of page type/
    url. Send those first to start resource download
    • Smart use of preload, prefetch and defer!

    View Slide

  35. Basic Streaming using Express.js

    View Slide

  36. Static resource download
    starts in milliseconds
    First paint
    with meaningful content
    Full page render

    View Slide

  37. Pros:
    • CSS and JS resources can
    start downloading within
    milliseconds of request
    • Page is ready to render as
    soon as HTML is
    downloaded
    Cons:
    • Server has to keep connection
    open with client until download
    completes
    • Client can download limited
    number of resources at a time

    View Slide

  38. Chunking + Streaming + Preload (PRPL)
    Real
    first-paint
    First-paint event?

    View Slide

  39. Track custom perf events
    • Existing browser events like DOMContentLoaded
    and Load are not sufficient
    • Track real first-paint using RAF and User Timing API
    • More custom metrics?

    View Slide

  40. Key Take-aways
    • Problems and solutions are different for Mobile and Desktop
    • Treat performance as a feature
    • You can’t optimise what you can’t measure
    • You can split JS bundles into smaller chunks
    • Smart preloading of chunks goes a long way
    • RUM is important. Synthetic testing can only do so much.

    View Slide

  41. @_abhinavrastogi
    Thank you!

    View Slide