ALL ABOUT PERCEIVED
PERFORMANCE
Aakash Bapna

UI Engineer, flipkart.com


!1
Me!

Abhilash

Arya

!2
I HATE SLOW WEBSITES.

!3
!4
ANYTHING YOU ADD- BROWSERS HAVE TO
DOWNLOAD, COMPUTE &
RENDER

!5
ANYTHING YOU ADD- BROWSERS HAVE TO
DOWNLOAD, COMPUTE &
RENDER

!6
Basics Performance Rules

•
•
•
•
•

CSS on top, JS at bottom.

Use CDN.

Caching static resources.

Minify JS, CSS, gzip....
USERS STILL SAY YOUR SITE IS
SLOW
!8
WHAT PERCEIVED
PERFORMANCE?

!9
!10
ITS ALL HOW USERS
PERCEIVE YOUR PAGE LOAD
whether loads in a flash, or takes ages to load.

!11
YOU HAVE TO MAKE USERS
BELIEVE ITS LOADING FAST...

!12
HOW WE DO THIS?

!13
Skeleton screens- Homepage
(below fold)

!14
Progressively enhanced MotoG page

SLOW CONNECTION

FAST CONNECTION
!15
Other Techniques
1.
2.
3.

Show precise progress loader when it
takes time (gmail)

Optimistic actions. (Instagram)

Paint...
Other Techniques
1.
2.
3.

Show precise progress loader when it
takes time (gmail)

Optimistic actions. (Instagram)

Paint...
MEASURING PERCEIVED
PERFORMANCE
HARD!

!18
SYNTHETIC MONITORING

!19
WEBPAGETEST
1.
2.
3.
4.
5.

Shows load times.

Shows waterfall of requests of how
page loaded.

CPU, network utilisation.
...
Frames

Waterfall

!21
“Why is it taking 715ms to download a 5kb
image?” - A developer after running WPT.

!22
Problem with WPT

•
•

!

Inconsistent results for load times on
every run.

Probably due to network conditions in
India.
...
BIGGER QUESTION- HOW OFTEN ARE
USERS SEEING THE PAGE WEBPAGETEST
IS SEEING?

!24
REAL USER MONITORING

!25
window.onload
1.
2.
3.
4.

so Web 1.0.

Doesn’t tell you how page loaded. 

Above the fold might complete very
early.

Thi...
NAVIGATION TIMING API

!27
NAVIGATION TIMING API
Client Time:
Very High.

NEED MOAR
DETAILS!

Server Time:
Very less for
big sites.

!28
WHAT IF YOU COULD EXPORT
REQUESTS WATERFALL FROM
REAL USERS?
and reconstruct picture.

!29
Resource Timing API.

•
•
•
•

window.performance.getEntries()

Supported: latest Chrome, IE10!

DNS/TCP connect times ava...
NAVIGATION TIMING API +
RESOURCE TIMING API =
WINDOW.ONLOAD
complete end to end picture of network performance.

!31
WE EXPORTED DATA FROM BROWSERS,
RAN HADOOP JOBS TO PROCESS THIS.

!32
!33
Requests Waterfall from RUM

!34
Requests Waterfall from RUM
Identify critical requests

!35
Requests Waterfall from RUM
Above the fold load time,
aim for getting this as
low as possible

!36
Findings (what was fast) :

•
•
•

CSS, JS are heavily cached over
requests, median under 100ms.

Cleaning up CSS/JS would...
Findings (what was slow) :

•
•
•
•

Google Analytics, Omniture tracking
calls were taking 500ms (median)

Redirects.

HTM...
CRITICAL REQUESTS.
Let browser handle, 

make them discoverable to browsers as soon as possible via
markup itself.

!39
NON-CRITICAL, BELOW FOLD

Lazy load images, lazy load modules via Ajax at DOM Ready.

!40
3RD PARTY CODE, SHARE
BUTTONS
You don’t have control over these, start at post onload.

!41
All in all, data by Resource Timing APIs is a
gold mine. There is lots to discover from it.

!42
FIXING IMAGES

!43
DEVELOPER: “THIS IMAGE IS HUGE, GIMME A SMALLER ONE”

!

DESIGNER: “OKAY, HOW SMALL?”

!

DEVELOPER: (CONFUSED, MAKES A RA...
DON’T GUESS, USE DATA.

use data from Resource Timing APIs

!45
Example:

730px x 300px
50kb
380ms to load

!46
FIXING CAROUSELS

!47
An example carousel on site.

!48
Wrong way

3 x 50kb images in parallel


!

Median load time of each: 832ms


!

BUT we are showing only one image, why lo...
Right way

Median load time: 380ms

Load via <img src=’’” >
as a critical resource

Load via javascript after
critical req...
IMAGE REUSE

!51
Browse Page

Product Page
!52
Same cached image from previous
page upscaled and used as
placeholder while big image loads.

Browse Page

Product Page
!5...
THEMING

All developers hate it.

!54
!55
Progressive festival theming
1.
2.
3.
4.
5.
6.

Theme is non-critical, should load after all
critical requests complete.

...
FIXING HTML SIZE

Important as affects discovery on critical requests.

!57
Our huuuge Nav menu

!58
MENU ON SLOW
CONNECTION

!59
<html>

<head>

	 <!— css —>

</head>

<body>

	 <div class=“header”>

	
	
<!— search bar —>

	 	
<!— navigation menu and ...
HTML caching

•
•
•
•

Over 40% of our markup is flyout
menu.

Persisted on clientside with
localStorage for 10 mins.

Dra...
REDIRECTS

very costly

!62
IT ALL STARTS WITH A
SHORTCUT
if (some condition) redirect();

!63
DECIDE URL STRATEGY BETWEEN
MOBILE/DESKTOP EARLY ON.

!64
PREFER ONE URL BETWEEN
MOBILE/DESKTOP
www.flipkart.com - good

www.flipkart.com/m - bad

!65
MOBILE SITE PERFORMANCE

!66
Mobile perf. highlights

•
•
•

Much of users(~50%) still come from
2G connections in India.

Use touchStart event instead...
TO SUSTAIN
Performance is a moving target.

!68
To sustain
1.
2.
3.

Have a performance team.

Measure key performance metrics.

Use webpagetest in CI to keep an eye
on w...
THE FUTURE
Prefetching

!70
NATIVE APPS ARE CHEATING
WITH PREFETCHING

!71
NATIVE APP: 8.5MB

WEB VIEW: 0 BYTES

!72
Food for thought

•
•
•

Prefetching autosuggest, next pages…

Going offline with ServiceWorkers
[W3C proposal] 

Prefetch...
THANK YOU!
connect:

twitter: @_aakash

mail: aakash@flipkart.com
!74
Upcoming SlideShare
Loading in …5
×

Meta Refresh 2014

1,456 views

Published on

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,456
On SlideShare
0
From Embeds
0
Number of Embeds
30
Actions
Shares
0
Downloads
18
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • good morning everyone,
    I am Aakash, I work with web performance team at Flipkart.
    Today I will talk about perceived perf.
    Lets start with this, How many of you feel Flipkart is fast?
  • These are the guys you should thank or blame when Flipkart is fast/slow.
    Thats me on top, then Abhilash and then Arya.I take care of desktop site perf, abhilash mobile site and arya of all server side perf.
  • I really hate slow websites. Developers test websites on fast office connections and get away with it. But In India, we could be subjected to slow connections at any point. You download TV series in night, morning you cross your FUP and your connection goes to 256K.
  • We curse the products we built.
    I really hate when I see the title of the tab and a white page below it.
    The content is actually ready with browser but its waiting for css request to finish. I feel these white pages are the reason web appears slow.
    And these white pages — browsers are really fast in rendering them.
  • anything you add to it, browsers have to download it, compute it and render on screen.
  • this talk we will see how to handle the download part, network part. We will not talk about JS performance, or rendering performance.
  • Lets start with basics, you do all this.
    You put css on top, js at bottom. use cdn and follow all those Y! slow rules.
  • But users still say your site is slow.
  • To fix things now, lets take a step back and see the fast page on earth.
  • this is the fastest page on earth.
  • Lets see why users are saying its slow, what is perceived performance.
  • This is to me is perceived performance!
    You don’t always need the fastest bike to win the race
    You need a good strategy to load content to make appear websites faster.
  • Its all how your users perceive your page load, whether it loads in a flash or takes ages to load.
  • You have to make users believe its loading, its loading fast even when its not the case.
  • Lets see how you can do this.
  • This is the snapshot of below the fold of our homepage while it is still loading. We put placeholders where content will appear once it loads.
  • Slow connection: all text visible, action buttons clickable.
    Fast connection: full width images, parallax scroll.
    possible because of background:blue
  • Show precise progress loader when it takes time (gmail)
    Optimistic actions. (Instagram)
    Paint what users are seeing right now.
  • Most important. We will see this in detail through the talk.
  • What users see on screen is nothing but critical rendering path, lets see how we optimised that.
  • Next, measuring perceived performance.
    How do you know whether users feel its fast or slow?
    Also, you need to know what are you fixing and how it will affect the user.
  • Running a test locally and seeing the results.
  • How many of you have used WebpageTest at least once?
  • One particular, very interesting feature of WPT is the flimstrips.
    As you hover over frames, it shows you the status of network requests at that time which you could correlate to the content of frame.
    It tells you how each network request is perceived by the user.
  • Using WPT, HTTPARCHIVE.org stores historical information about how websites load. Allows you to benchmark against different sites.
    Here is Flipkart homepage an year ago, now.
  • “Why is it taking 715ms to download a 5kb image” exact quote from one of our emails.
  • Bigger question- How often are users seeing the page Webpagetest is seeing? How often are they seeing the slow requests, how often are they seeing the page load like in video on httparchive?
  • thats why we need real user monitoring, we need data from actual users.
  • browsers fire this when all requests start before this event complete.
  • Gives a detailed break down of main request.
  • Enter Resource Timing API
  • This is what we observed. Complete CHAOS, So many requests starting, all wanting to complete as soon as possible.
  • To get better idea, We constructed the waterfall from startTime and duration of requests.
    We found lots of optimisations possible, which would give biggest benefit?
  • We went on identify critical requests.
    CSS
    logo
    main sprite
    banner - occupying more than 50% of screen.
  • JS cleanup is the last thing you should do for performance optimisation.
  • WE grouped our requests.
    Let browser handle them,
    make them discoverable to browsers as soon as possible via markup itself.
  • All in all, data by resource timing APIs is a gold mine. There is lots to discover from it.
  • 730px x 300px banner takes 380ms to load.
  • Very easy to wrongly implement. They could impact overall page performance if not implemented correctly.
  • three images, one on each slide. if you load all of them in parallel.
    each of them would load in 832ms, because they all compete for bandwidth
  • Load visible images via markup, rest when connection is idle.
  • Our users navigate a lot between browse and product pages.
  • Experimented on mobile site, coming soon on desktop.
  • This is how flipkart looked on Diwali, then christmas and latest-&gt; valentines day.
    Frankly, How many of you like these themes?
    The idea was that the christmas tree should load after product images, banners.
  • Guidelines for themes.
  • Submenus make it huge, categories expanded over time and exploded the menu.
  • on a data card like connection. for every page view.
  • Simillar gains on mobile
  • Its very bad practise in code, soon everyone exploits this.’
    At one point most of our search queries were redirects.
    We saved 700ms (median) in redirects on search pages.
    Increased searches per visit and everything else related
  • otherwise you will be left redirecting users here and there.
  • It makes things easier in longer run.
  • Most of things we discussed applied to both mobile/desktop.
  • Performance is a moving target, you can’t do once and forget.
  • performance team to evangelise performance to other team.s
  • Prefetching is the future of performance, to give near instant loads like native apps.
  • lets compare Flipkart mobile app, vs iOS app
    When you open Flipkart app
  • Tell a web developer, you could download 8.5mb of data on client, how happy he would be!
    With this Apps could show splash screens, stale data and buy more time to load.
    But moment you hit across a webview in app, it shows a white page!
  • Meta Refresh 2014

    1. 1. ALL ABOUT PERCEIVED PERFORMANCE Aakash Bapna UI Engineer, flipkart.com !1
    2. 2. Me! Abhilash Arya !2
    3. 3. I HATE SLOW WEBSITES. !3
    4. 4. !4
    5. 5. ANYTHING YOU ADD- BROWSERS HAVE TO DOWNLOAD, COMPUTE & RENDER !5
    6. 6. ANYTHING YOU ADD- BROWSERS HAVE TO DOWNLOAD, COMPUTE & RENDER !6
    7. 7. Basics Performance Rules • • • • • CSS on top, JS at bottom. Use CDN. Caching static resources. Minify JS, CSS, gzip. … Y! slow rules !7
    8. 8. USERS STILL SAY YOUR SITE IS SLOW !8
    9. 9. WHAT PERCEIVED PERFORMANCE? !9
    10. 10. !10
    11. 11. ITS ALL HOW USERS PERCEIVE YOUR PAGE LOAD whether loads in a flash, or takes ages to load. !11
    12. 12. YOU HAVE TO MAKE USERS BELIEVE ITS LOADING FAST... !12
    13. 13. HOW WE DO THIS? !13
    14. 14. Skeleton screens- Homepage (below fold) !14
    15. 15. Progressively enhanced MotoG page SLOW CONNECTION FAST CONNECTION !15
    16. 16. Other Techniques 1. 2. 3. Show precise progress loader when it takes time (gmail) Optimistic actions. (Instagram) Paint what they are seeing right now. !16
    17. 17. Other Techniques 1. 2. 3. Show precise progress loader when it takes time (gmail) Optimistic actions. (Instagram) Paint what they are seeing right now. !17
    18. 18. MEASURING PERCEIVED PERFORMANCE HARD! !18
    19. 19. SYNTHETIC MONITORING !19
    20. 20. WEBPAGETEST 1. 2. 3. 4. 5. Shows load times. Shows waterfall of requests of how page loaded. CPU, network utilisation. Filmstrips. etc… !20
    21. 21. Frames Waterfall !21
    22. 22. “Why is it taking 715ms to download a 5kb image?” - A developer after running WPT. !22
    23. 23. Problem with WPT • • ! Inconsistent results for load times on every run. Probably due to network conditions in India. !23
    24. 24. BIGGER QUESTION- HOW OFTEN ARE USERS SEEING THE PAGE WEBPAGETEST IS SEEING? !24
    25. 25. REAL USER MONITORING !25
    26. 26. window.onload 1. 2. 3. 4. so Web 1.0. Doesn’t tell you how page loaded. Above the fold might complete very early. This is the bare minimum you should record. !26
    27. 27. NAVIGATION TIMING API !27
    28. 28. NAVIGATION TIMING API Client Time: Very High. NEED MOAR DETAILS! Server Time: Very less for big sites. !28
    29. 29. WHAT IF YOU COULD EXPORT REQUESTS WATERFALL FROM REAL USERS? and reconstruct picture. !29
    30. 30. Resource Timing API. • • • • window.performance.getEntries() Supported: latest Chrome, IE10! DNS/TCP connect times available when cross origin headers are set. under documented. !30
    31. 31. NAVIGATION TIMING API + RESOURCE TIMING API = WINDOW.ONLOAD complete end to end picture of network performance. !31
    32. 32. WE EXPORTED DATA FROM BROWSERS, RAN HADOOP JOBS TO PROCESS THIS. !32
    33. 33. !33
    34. 34. Requests Waterfall from RUM !34
    35. 35. Requests Waterfall from RUM Identify critical requests !35
    36. 36. Requests Waterfall from RUM Above the fold load time, aim for getting this as low as possible !36
    37. 37. Findings (what was fast) : • • • CSS, JS are heavily cached over requests, median under 100ms. Cleaning up CSS/JS would hardly move metrics. Although CSS load times are less, its a blocking resource and need to keep a check on its size. !37
    38. 38. Findings (what was slow) : • • • • Google Analytics, Omniture tracking calls were taking 500ms (median) Redirects. HTML document itself taking too long to load. Images. !38
    39. 39. CRITICAL REQUESTS. Let browser handle, make them discoverable to browsers as soon as possible via markup itself. !39
    40. 40. NON-CRITICAL, BELOW FOLD Lazy load images, lazy load modules via Ajax at DOM Ready. !40
    41. 41. 3RD PARTY CODE, SHARE BUTTONS You don’t have control over these, start at post onload. !41
    42. 42. All in all, data by Resource Timing APIs is a gold mine. There is lots to discover from it. !42
    43. 43. FIXING IMAGES !43
    44. 44. DEVELOPER: “THIS IMAGE IS HUGE, GIMME A SMALLER ONE” ! DESIGNER: “OKAY, HOW SMALL?” ! DEVELOPER: (CONFUSED, MAKES A RANDOM GUESS…) !44
    45. 45. DON’T GUESS, USE DATA. use data from Resource Timing APIs !45
    46. 46. Example: 730px x 300px 50kb 380ms to load !46
    47. 47. FIXING CAROUSELS !47
    48. 48. An example carousel on site. !48
    49. 49. Wrong way 3 x 50kb images in parallel ! Median load time of each: 832ms ! BUT we are showing only one image, why load all three? !49
    50. 50. Right way Median load time: 380ms Load via <img src=’’” > as a critical resource Load via javascript after critical requests end. !50
    51. 51. IMAGE REUSE !51
    52. 52. Browse Page Product Page !52
    53. 53. Same cached image from previous page upscaled and used as placeholder while big image loads. Browse Page Product Page !53
    54. 54. THEMING All developers hate it. !54
    55. 55. !55
    56. 56. Progressive festival theming 1. 2. 3. 4. 5. 6. Theme is non-critical, should load after all critical requests complete. All functionality should work with base skin. Limited to colours, background images. No new DOM elements, use :before, :after. Packed in single theme.css file. Theme CSS file is loaded asyncly on DOM ready. !56
    57. 57. FIXING HTML SIZE Important as affects discovery on critical requests. !57
    58. 58. Our huuuge Nav menu !58
    59. 59. MENU ON SLOW CONNECTION !59
    60. 60. <html> <head> <!— css —> </head> <body> <div class=“header”> <!— search bar —> <!— navigation menu and big fat submenus —> ……. .…… </div> <img src=“…” /> <img src=“…” /> … </body> !60
    61. 61. HTML caching • • • • Over 40% of our markup is flyout menu. Persisted on clientside with localStorage for 10 mins. Drastically reduced payload which was transferred for every request. 200ms improvement over median. !61
    62. 62. REDIRECTS very costly !62
    63. 63. IT ALL STARTS WITH A SHORTCUT if (some condition) redirect(); !63
    64. 64. DECIDE URL STRATEGY BETWEEN MOBILE/DESKTOP EARLY ON. !64
    65. 65. PREFER ONE URL BETWEEN MOBILE/DESKTOP www.flipkart.com - good www.flipkart.com/m - bad !65
    66. 66. MOBILE SITE PERFORMANCE !66
    67. 67. Mobile perf. highlights • • • Much of users(~50%) still come from 2G connections in India. Use touchStart event instead of click(~300ms delay). A/B tested heavily to find right mix of content. !67
    68. 68. TO SUSTAIN Performance is a moving target. !68
    69. 69. To sustain 1. 2. 3. Have a performance team. Measure key performance metrics. Use webpagetest in CI to keep an eye on what's being checked in. !69
    70. 70. THE FUTURE Prefetching !70
    71. 71. NATIVE APPS ARE CHEATING WITH PREFETCHING !71
    72. 72. NATIVE APP: 8.5MB WEB VIEW: 0 BYTES !72
    73. 73. Food for thought • • • Prefetching autosuggest, next pages… Going offline with ServiceWorkers [W3C proposal] Prefetching on hover/touchStart http:// instantclick.io/ !73
    74. 74. THANK YOU! connect: twitter: @_aakash mail: aakash@flipkart.com !74

    ×