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.

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. (as of react-router@2.7.0)
    

    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