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. 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
36. Requests Waterfall from RUM
Above the fold load time,
aim for getting this as
low as possible
!36
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. Findings (what was slow) :
•
•
•
•
Google Analytics, Omniture tracking
calls were taking 500ms (median)
Redirects.
HTML document itself taking too long
to load.
Images.
!38
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
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. 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
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
73. Food for thought
•
•
•
Prefetching autosuggest, next pages…
Going offline with ServiceWorkers
[W3C proposal]
Prefetching on hover/touchStart http://
instantclick.io/
!73
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-> 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!
