Get to know the browser better and write faster web apps

© 2013 SAP Portals. All rights reserved.
1
Lior Bar-On, Senior Development Architect @ SAP
Sept. 2013
Public

2
About Me


‫שלי‬ ‫הבלוג‬(‫בעברית‬:)http://www.softwarearchiblog.com/
http://www.linkedin.com/in/liorbo

3
Agenda
The Server
The Network
The Browser

4
The Network
The Network
The Server The Browser

5
A Web App that loads is a Miracle!
Load HTML file
DNS lookup
Establish TCP Conn. (3-way handshake)
HTTP request @Cold Connection
HTML Parsing starts
<script> tag => “Stop The World”
ForEach Script file:
 (Optional) DNS lookup
 (Optional) 3-way handshake + TLS handshake (“4-way”)
 (Optional) http request over a (cold) connection
Continue HTML parsing….
t

6
TCP Congestion Control: Slow Start (sending 20KB of data)
Cold Connection Warn Connection
Segment = 1460 bytes
Header = 40 bytes

7
An “Underwater Cable” won’t save ya!

8
How Does it works?
Hardware improves all the time
CPU / Memory
Network
Browsers Optimizations
Client-Side Cache
Keep Alive
DNS pre-fetch
TCO pre-connect
Network Optimizations: Content Delivery Networks (CDNs)
Developers can do much more!

9
Main Pain Point of Modern Networks: Latency
“average” latency is typically ~200ms, +200ms for 3G access
source

10
Tactics dealing with the Network
Reduce the number of Roundtrips
Lazy Loading
Caching
Domain Sharding
Unification
Minification

11
Tactic: Reduce number of Roundtrips / redirects
Latency is paid for each roundtrip done.
Eliminate (e.g. 404s, resources not being used)
Unify (later)
Lazy-Load (later)
Redirects require a new HTTP request cycle
Redirect = a significant waste
e.g. redirect to “m.mysite.com”
source: http archive

12
Tactic: Lazy Loading
Load resources (scripts, ajax calls, (images)) only when they are needed.
Dynamic JavaScript loading libraries:
 LABjs
 require.js
 Lsjs
 ControlJS
Manually: $('head').append( ... );

13
Tactic: Caching
Distinguish between “Cachable” vs. “Non-Cachable” HTTP Methods:
Some Methods (GET, HEAD) will be cached by the “network”
Unsafe Methods (POST, PUT, DELETE, OPTIONS) will not be cached by the “network”
Use appropriate HTTP headers to define a proper caching policy
Such as:
 Cache-control / expires
 If-Modified
 ETags
POST method can become cachable with proper headers, at least in theory

14
Domain Sharding
Distribute resources over multiple hostname to increase connection parallelism
Effectiveness is nowadays questionable (argument for, argument against)
Even if you do:
 Only on domains proven to require many files
 Shard no more than once
A new method rising: “Domain UnSharding”:
Assembling large, unique resources to a single host
can enjoy “connections warm-up”.
Images, fonts and niche JavaScript libraries
- are a good candidates
example.com = 1.1.1.1
img.example.com = 1.1.1.1
DNS
Browser
consult
6 x example.com
6 x img.example.com
Overall: 12 connections!
<< 1.1.1.1 >>
Server
connections:

15
Tactic: Unification
Working with small source files is a good programming practice.
So - crunch JavaScript and CSS files
Yahoo’s YUI Compressor
Google Closure Compiler
CSSO (for CSS files)
etc.
source: http archive

16
Tactic: Unification (2)
Sprites
Create 1 image to replace many
Not just for image files (e.g. howler.js)
Data URIs
Note: DataURI increase resource size by 37%

17
Tactic: Minification
JavaScript Minification tools can reduce 50%-90% of the file’s size
Being compressed into:

18
Tactic: Minification(2)
CSS minification tools can reduce 30%-50% of the file’s size
Optimize images size and compression - can save much size.
Enabling GZIP compression on textual files (even if minified) can save you some network bytes.
Bitmap
Vector SVG
JPG
compression?
PNG
Bit depth?
Lossy PNG
?
?
?
Bitmap
reduce size?
?
?

19
Real Life Experience

20
WebPageTest: Results

21
WebPageTest: Some Data provided

22
WebPageTest: Connection View

23
Inbound Alternative: Chrome Dev Tools

24
The Browser
The Network
The Server The Browser

25
The Web Browser
source: statcounter

26
The Browser Internals - engines
Browser Rendering Engine
Safari (iOS, win or Mac) Webkit
Chrome, Opera Blink (a recent fork of Webkit)
Firefox Gecko
Internet Explorer Trident
Internet Explorer for Mac Tasman
Browser JavaScript Engine ECMAScript 5.1
Support since
Safari (iOS, win or Mac) javaScriptCore (aka Nitro) SF5.1*
Chrome, Opera V8 Chrome13
Firefox
SpiderMonkey
JIT part called ionMoney (since
FF18)
FF4
Internet Explorer Chakra (since IE9) IE9*

27
Typical Browser HTML rendering flow
HTML file
DOM Tree
(aka content model)
1: parse
Style Tree
(aka style ruleSet, CSSOM)
CSS file 2: parse
2: load
Render Tree
(aka frame tree)
3: merge
3: merge
Canvas
5: render
Layout
4: layout /
re-flow
JavaScript file
2: update
2: update
2: load
6: draw
on screen
Source: d.baron

28
Problems that may occur with the Browser’s Rendering Model
“Stop the World” on initial page load
Doing Unnecessary work (“Layout trashing”, “Paint trashing”)
Single thread
The Browser is not well-known to developers

29
“Stop The World”
blocks other downloads (images in IE, iframes); scripts are loaded and executed serially; blocks rendering
during parse-execute

30
3 interaction milestones
0.1 second
is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special
feedback is necessary except to display the result.
1.0 second
is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the
delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second,
but the user does lose the feeling of operating directly on the data.
10 seconds
is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want
to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating
when the computer expects to be done. Feedback during the delay is especially important if the response
time is likely to be highly variable, since users will then not know what to expect.

31
Tactics dealing with the Browser
Postpone Script Execution
Add styles before DOM Elements
Be aware of DOM Tree’s Write Buffer
Offload work to other threads

32
Tactic: Postpone Script Execution
Either:
 Move Script to the end of the file (after <body> tag)
 Add Script Dynamically to <head> tag:
$('head').append( ... );
 Use “async” and “defer” attributes
<script src=“…” async></script>
 Simply, use require.js / LABjs / etc.

33
Tactic: Add styles before DOM Elements
Inserting Style tree element is more expensive than inserting DOM element.
We also want nice visualization on the screen early (perceived performance)
Therefore:
 Inside the <HEAD>, put all CSS files first.
 Prefer jQuery’s data() over addClass()
 Minimize use of CSSOM, e.g.:
myStyle.insertRule(…)
DOM Tree
(aka content model)
Style Tree
(aka style ruleSet, CSSOM)
Render Tree
(aka frame tree)
3: merge
3: merge

34
2 Code Examples…
Which Example looks Much better for performance?

35
Tactic: Be aware of DOM Tree’s Write Buffer
A little theory:
Flush will happen:
 At DOM read operation, e.g. element.height
 Every 16.6ms (to achieve 60fps)
Style Tree DOM Tree
Render Tree
DOM API
Read (B)
Write Buffer
Read (A)
write
Flush changes
derived fromderived from

36
Tactic: Be aware of DOM Tree’s Write Buffer (2)
R/W/R/W/R/W/R/W/R/W = ~250ms
RRRRRRR/WWWWWW = ~20ms
source

37
Another example
Could be so much better as:

38
Tactic: offload work to other threads
Browser has a single thread that executes JavaScript (per browser tab)
When the thread is busy, the following is being blocked:
Event handling (e.g. Click, Resize)
setTimeout / setInterval
Possibly rendering
What can be done?
SetTimeout(myFunc, 0);
Use CSS Animations
transform: translateZ(0); read more
Use Web Workers for intensive calculations / network activity
Heap
Queue
Stack
Thread
Closure
Closure
Closure
Closure
Closure
Closure
Closure
Closure
Closure
Closure
global variables
Context
(“window” object)
public part
private part
pull
push
“document” object
(DOM)

39
Chrome Dev Tools’ Timeline is your best friend

40
Thank You
Lior Bar-On
baronlior@gmail.com
(Hebrew) Blog: http://www.softwarearchiblog.com/

Get to know the browser better and write faster web apps

More Related Content

What's hot (20)

Similar to Get to know the browser better and write faster web apps (20)

Recently uploaded (20)

Get to know the browser better and write faster web apps