1.
Mobile
Op*miza*on
Oct.
2013
/
Sangjoon
Ahn

2. Agenda
§ Introduc9on
§ Market
trend
§ Mobile
Op9miza9on
Technologies
§
§
§
§
TCP
op9miza9on
FEO
Image
Op9miza9on
Performance
Test
of
FEO
&
Image
Op9miza9on
§ Mobile
CDN
§ Considera9on
of
Mobile
Delivery
§ Conclusion
Page
1

3. Introduc9on
-­‐
Market
Trend
-­‐
LTE
Status
Page
2

4. Mobile
Trend
§ According
to
Cisco's
Visual
Network
Index
report
from
Feb.
2013
§
§
§
§
Two-­‐thirds
of
the
world's
mobile
data
traffic
will
be
video
by
2017.
Global
mobile
data
traffic
will
increase
13-­‐fold
between
2012
and
2017
In
2017,
4G
will
be
10
percent
of
connec9ons,
but
45
percent
of
total
traffic
Cisco
Visual
Networking
Index:
Global
Mobile
Data
Traffic
Forecast
Update,
2012-­‐201
7
:
h[p://www.cisco.com/en/US/solu9ons/collateral/ns341/ns525/ns537/ns705/ns8
27/white_paper_c11-­‐520862.html
Page
3

5. MNO
Status
Page
4

6. Web
Performance
And
User
Expecta9on
Page
5

7. Impact
of
1
second
delay
Page
6

8. Web
Accelera9on
How
web
site
page
load
9me
breaks
down
80
~
90%
10
~
20
%
Backend
First-­‐mile
Front-­‐end
Internet
l Database
calls
l HTML
page
genera9on
Internet
Middle-­‐mile
l Retrieving
page
contents,
including
HTML,
images,
Javascript,
etc.,
fro
m
origin
server,
across
the
internet
Last-­‐mile
l Delivering
content
over
cable
m
odem,
Cellular
network,
etc.,
to
end-­‐user
l Rendering
page
in
the
browser
Problem
Addressed
How
it
works
Contents
Delivery
Network
(CDN)
Network
Latency
Files
cache
in
mul9ple
edge
caches
tha
t
are
geographically
dispersed
Dynamic
Web
Accelera9on
(DWA)
Network
Latency(especially
dy
namic
content)
Op9mize
rou9ng
TCP
op9miza9on
Compression
Front-­‐end
Op9miza9on
(FEO)
Reduce
HTTP
Requests,
page
s
ize
and
browser
bo[lenecks
Op9mize
HTML
code
and
page
resourc
es
Page
7

9. Mobile
Op9miza9on
QoE
improvement
for
mobile
user
QoE
Today
Topic
Improve
QoE
[L7
improvement]
Content
Op*miza*on
Video
Pacing,
Image
Op*miza*on
and
etc.
[L6
improvement]
Adopt
FEO
Technology
HTML
(Presenta*on-­‐level)
Op*miza*on
Improve
Responsibility
&
Reduce
Traffic
[L5
improvement]
Adopt
SPDY/RE
Technology
HTTP
(Session-­‐level)
op*miza*on
Improve
Transfer
rate
[L4
improvement]
TCP
（Transport-­‐level）Op*miza*on
Improve
Latency
[L1-­‐L3
improvement]
Adopt
CDN
(beZer
performance
than
ISP
N/W)
Page
8

10. TCP
Op9miza9on
Page
9

11. TCP
conges9on
control
&
avoidance
§ TCP
§ Designed
to
probe
available
bandwidth
§ Does
not
use
full
bandwidth
from
start
Page
10

12. TCP
performance
on
mobile
network
is
poor?
§ Don’t
know
characteris9cs
of
cellular
network
§ Bufferbloat
by
large
queue
in
mobile
network
§ Interference
by
middlebox
deployed
inside
mobile
network
§ Don’t
consider
about
TCP
characteris9cs
§ overshoo9ng
by
TCP
slow
start
§ Limited
Slow
start,
hystart
§ can
detect
conges9on
by
packet
loss
§ Delay-­‐based
conges9on
control
:
vegas,
westwood
§ Traffic
control
of
heavy
users
§ Too
much
retransmit
overhead
on
bandwidth
limited
network
and
congested
area
network
Page
11

13. Performance
Bo[leneck
3G
Network
Latency
NAT
Origin
100
~
200
ms
50
~
100
ms
Available
Bandwidth
LTE
4G
2
~
7
Mbps
70
~
150
Mbps
PGW
eNB
3G
GGSN
Issues
SGW
SGSN
Bufferbloat
by
mid Limit
bandwidth
of
dle
boxes
heavy
users
How
to
solve
p DRWA
(Dynamic
R
erformance
iss eceiver
Window
A
ues
djustment)
Mobile
Device
Traffic
control
at
ap
plica*on-­‐level.
Candidate : DRWA (Dynamic Receiver Window Adjustment)
Mobile
Device
NB
Issue
of
latency
and
available
ba
ndwidth
Limited
Slow
Start
Tuning
TCP
parameter
and
Cong
es*on
Control
Algorithm
Page
12

14. Analysis
of
packet
loss
§ Download
200KB
on
bandwidth-­‐limit
of
heavy
user
:
300Kbps
§ Rxt
overhead
:
32.89
%,
Download
9me
:
4.58
sec
Page
13

15. Analysis
of
packet
loss
(cont’d)
§ Download
2MB
on
bandwidth-­‐limit
of
heavy
user
:
300Kbps
§ Rxt
overhead
:
16.5
%,
Download
9me
:
57.41
sec
Page
14

16. TCP
op9miza9on
§ Tuning
§ Limited
slow
start
for
preven9ng
overshoo9ng
§ Tune
Ini9al
CWND
§ 2.6.39+
defaults
to
10
§ 2.6.19+
can
be
configured
via
IP
ROUTE
§ ip
route
change
default
via
gateway_ipaddr
dev
eth0
initcwnd
10
§ Tune
CA
(Conges9on
Avoidance)
for
sending
less
aggressively
da
ta
§ Tune
backoff
when
detected
packet
loss
§ Improve
rxt
rate
of
bandwidth-­‐limited
user
(heavy
user)
§ not
easy
to
improve
with
current
TCP
§ Shape
bandwidth
by
force.
Page
15

17. Result
of
rxt
rate
of
BW-­‐limited
user
No
Busy
area
:
10:00:00
~
15:30:00
Model
Normal
TCP
IS12S
B/W-­‐limited
phone Tuned
TCP
Normal
TCP
ISW11SC
Tuned
TCP
Busy
area
=
15:56:00
~
23:30:00
Model
Normal
TCP
IS12S
Tuned
TCP
Normal
TCP
ISW11SC
Tuned
TCP
200K
Num
157.7
100.3
138.7
100.2
300K
10
10
19
10
Num
142.1
103.0
128.9
104.9
2M
10
10
10
10
Num
117.2
108.5
111.0
108.3
50M
10
10
10
10
Num
200K
Num
117.5
100.2
116.7
100.2
300K
10
10
11
11
Num
111.0
100.3
120.0
102.2
2M
10
10
10
10
Num
101.9
102.2
110.6
106.2
50M
3
3
10
10
Num
Page
16

18. Field
test
with
tuned
TCP
Page
17

19. FEO
Page
18

20. FEO
§ FEO
technologies
help
to
reduce
the
number
of
page
resources
required
to
down
load
a
given
page
and
makes
the
browser
process
the
page
faster.
§ mod_pagespeed(MPS)
is
an
Open
Source
FEO
solu9on
from
Google.
As
Google
d
efined
it
:
Apache
module
for
rewri9ng
web
pages
to
reduce
latency
and
bandwi
dth
Page
19

21. Mod_pagespeed
features
§ Op9mize
caching
§ Extend
Cache,
Local
storage
cache
§ Outline
CSS/javascript
§ Minimize
Round
Trip
Times
§
§
§
§
Combine
and
Inline
CSS/Javascript
Inline
images,
Sprite
Images
Fla[en
CSS
@imports
Sharding
domains
§ Minimize
Payload
sizes
§ Op9mize
image
(PNG/JPG/GIF/WebP)
:
remove
metadata
of
Image,
resize
image
§ Minify
CSS/Javascript
§ Deduplicate
inlined
images
§ Op9mize
browser
rendering
§
§
§
§
Defer
Javascript
Move
CSS
to
Head
Lazily
load
images
Convert
JPEG
to
Progressive
Page
20

22. Web
Request
§
§
§
§
DNS
lookup
to
resolve
the
hostname
to
IP
address
New
TCP
connec9on
requiring
a
full
roundtrip
to
the
server
HTTP
request
requiring
a
full
roundtrip
to
the
server
Server
processing
9me
§ Network
latency
on
mobile
network
is
longer
than
that
on
wired
n
etwork.
Page
21

23. Mobile
site
performance
challenges
§ Remove
network
latency
overhead.
§ Careful
about
using
Domain
sharding
§ Don’t
use
redirect
§ Op9mize
Cri9cal
Rendering
path
§ Inline
cri9cal
CSS
§ Remove
blocking
JavaScript
§ Defer
non-­‐cri9cal
assets
§ Reduce
HTTP
requests
§ Image
spri9ng
§ Inline
small
image/CSS/JS
§ Reduce
image
size
§ Op9mize
Image
§ Load
“above
the
fold”,
not
load
en9re
page.
§ Lazy-­‐load
images
§ Watch
out
for
extra
round-­‐trips
§ Especially
new
connec9ons
Page
22

24. Lab
Experiment
§ Test
with
mod_pagespeed
as
an
open
source
FEO
solu9on
fro
m
Google
§ Test
scenario
§ choose
5
sample
sites
:
each
web
site
for
PC
&
mobile
user
§ Simulate
mobile
network
environment
using
TC
tool
naver
daum
mod_pagespeed
TC
Origin
Latency
:
0,
50,
100ms
TC
gmarket
samsung
auone
Page
23

25. Test
result
of
PC
website
naver
w/o
MPS
Sent
Kb
Receive
Kb
Second(Cache)
75.8
24.8
393.5
Request
Count
0.1
0.0
0.6
CSS
count/size(Kb)
7
7
6
GIF
count/size(Kb)
23.9
JPG
count/size(Kb)
25
5.9
HTML
count/size(Kb)
JS
count/size(Kb)
PNG
count/size(Kb)
Loading
Time
(0ms
delay)
Loading
Time
(50ms
delay)
Loading
Time
(100ms
delay)
w MPS
Request
Count
Sent
Kb
Receive
Kb
HTML
count/size(Kb)
JS
count/size(Kb)
CSS
count/size(Kb)
GIF
count/size(Kb)
JPG
count/size(Kb)
PNG
count/size(Kb)
Loading
Time
(0ms
delay)
Loading
Time
(50ms
delay)
Loading
Time
(100ms
delay)
daum
First
51.0
28.2
28.8
15.3
154.2
79.6
0
0
0
0.0
0
0
0.1
0.0
1.0
2.2
3.5
0.0
0.0
0.0
0.6
0.3
0.4
0.3
First
112.3
35.7
553.1
14
55.3
6
49.9
0
0.0
2
8.1
40
42
135.7
253.7
1.4
2.6
4.6
naver
First
Req
No.
Second(Cache)
45
9
15.5
2.9
40.6%
373.7
61.3
7
60.9
Sent
Size
7
61.0
7
27.5
0
0.0
5
34.1
0
37.3%
0.0
0
0
0.0
0.0
Receive
Size
1
19
139.2
0.2
6
75.6
0
0.0
1.0
5.0%
0.5
1.9
0.8
Loading
Time
1.3
3.0
15.0%
gmarket
samsung
Second(Cache)
First
Second(Cache)
2
0.9
0.8
256
90.6
5,434.1
12
39.4
30
195.7
2
10.3
22
9.8
7.8
1
0
0
0.3
1
0
0
0.4
0.0
0.0
0.0
0.0
94
83
30
103.2
4,859.4
216.4
0.8
0.8
0.7
Second(Cache)
First
Req
No.
0.0
22
0
0
7.8
2.6
5.7
10.1
0.0
0.0
0.0
0.0
77
3.3%
1
0
0
59.6
1.3
3.8
6.9
Second(Cache)
First
178.9
62
66.5
25.5
30.1%
1,546.1
88.5
9
Sent
Size
9
74.0
74.0
26
184.3
3
0.6
2
0
10.5
26.7%
0.0
34
31
31.0
10.7
Receive
S
80.9
1,016.8
ize
8
1.4
19
218.1
6
1.0
2.7
71.5%
1.5
4.0
3.7
Loading
Time
6.8
2.4
37.6%
18.5
0
0
0
739.9
gmarket
78.6
21.4
26.6
30.0%
7.7
512.2
132.8
13
Sent
Size
12
98.2
94.5
6
0
49.4
0.0
0
0
0.0
25.5%
0.0
1.3
1.2
7.9
0.3
Receive
Size
0
12
69.7
0.0
37.3
3.2
240.3
37.2
1.5
7.4%
0.9
2.6
1.4
Loading
Time
4.5
1.8
1
0.3
18.5
102.6
40
65
auone
Second(Cache)
199
62.0
1,079.2
3
48.7
11
104.5
3
23.8
1.1
1.1
1.3
daum
First
Req
No.
0
0
0
First
0.0
0.0
0.0
0.0
0.0
First
43
13.1
231.3
2
17.8
9
46.7
1
4.7
24
7
0
70.0
92.1
0.0
0.2
0.4
0.6
Second(Cache)
First
8
2.9
10.6
1
0
0
8.3
7
0
0
2.3
0.7
1.4
2.3
samsung
Req
No.
Second(Cache)
41
13.5
702.3
5
1.5
79.4%
144.5
3
3
144.2
144.2
Sent
Size
10
1
95.2
0.2
3
1
41.0
0.2
78.3%
0
0
0.0
0.0
19
Receive
Size
0
396.0
0.0
6
0
25.8
0.0
1.9
35.0%
0.8
2.7
1.1
Loading
Time
4.0
1.8
42.4%
0.0
0.0
0.0
0.0
0.3
0.5
0.7
auone
Req
No.
Second(Cache)
23
5
7.2
1.6
46.5%
219.0
31.7
2
31.5
2
31.2
Sent
Size
5
42.9
0
0.0
1
0
4.9
45.1%
0.0
3
3
6.0
0.5
7
92.6
0
Receive
Size
0.0
5
41.1
0
0.0
0.7
5.3%
0.4
1.5
1.0
Loading
Time
1.6
2.5
7.3%
Page
24

26. Test
result
of
Mobile
website
M_naver
w/o
MPS
Request
Count
Sent
Kb
Receive
Kb
HTML
count/size(Kb)
JS
count/size(Kb)
CSS
count/size(Kb)
GIF
count/size(Kb)
JPG
count/size(Kb)
PNG
count/size(Kb)
Loading
Time
(0ms
delay)
Loading
Time
(50ms
delay)
Loading
Time
(100ms
delay)
M_daum
M-­‐gmarket
M_samsung
auone
First
Second(Cache)
First
Second(Cache)
First
Second(Cache)
First
Second(Cache)
30
9.7
209.2
1
0.4
0.3
31.9
10.2
146.6
1
0.4
0.3
68.8
22.4
565.2
1
4.0
4
29.9
9
23.0
38.8
103.9
12
385.8
3
6.7
0.5
1.5
3.0
3
1.3
1.1
47
15.6
340.0
46
18.6
8.5
2
6
1
1
10
8
0
0
0
0
0
0
20.8
39.0
9.4
1.9
99.2
35.4
1.0
1.9
2.8
0.0
0.0
0.0
0.0
0.0
0.0
0.6
0.7
0.8
4
5
1
0
8.9
10
19.1
40.8
7.4
0.0
33.7
42.9
0
0
0
0
0
1
0.5
1.4
2.4
0.0
0.0
0.0
0.0
0.0
0.3
0.1
0.2
0.3
0
0
0
3
0
0
0.0
0.0
0.0
1.1
0.0
0.0
0.1
0.2
0.3
2
2
3
12
14
14
5.1
27.9
12.2
8.7
265.9
20.1
1
2
3
12
14
14
0.5
1.4
2.3
0.2
0.3
0.5
2.9
2.0
2.6
0.2
0.8
1.4
First
Second(Cache)
59
18.6
195.5
1
9.1
5
46.9
2
5.7
0
0.0
1
2.2
44
117.5
0.7
1.6
2.7
0
0.0
0.0
0
0
0
0
0
0
w MPS
Request
Count
Sent
Kb
Receive
Kb
HTML
count/size(Kb)
JS
count/size(Kb)
CSS
count/size(Kb)
GIF
count/size(Kb)
JPG
count/size(Kb)
PNG
count/size(Kb)
Loading
Time
(0ms
delay)
Loading
Time
(50ms
delay)
Loading
Time
(100ms
delay)
First
Req
No.
Second(Cache)
28
15
9.4
6.7%
5.8
156.4
17.2
2
14.9
Sent
Size
2
14.7
6
39.2
2
0.4
1
0
9.5
2.6%
0.0
1
1
1.9
0.2
Receive
1
9
56.1
Size
0.2
7
33.3
7
1.2
1.1
25.2%
0.7
1.9
1.2
Loading
Time
1.7
2.8
0%
M_daum
First
Req
No.
Second(Cache)
28
9.7
143.0
5
1.9
12.2%
22.5
4
Sent
Size
3
22.2
21.8
5
0
40.5
0.0
1
0
7.4
0.0
4.9%
0
0
0.0
0.0
Receive
Size
0
5
17.3
0.0
11
0
54.7
0.0
0.6
2.5%
20.0
1.3
0.7
Loading
Time
2.3
1.3
5.0%
M-­‐gmarket
First
Req
No.
Second(Cache)
36
30
11.8
47.7%
12.0
506.4
43.1
1
Sent
S37.2
ize
1
37.2
3
0
30.1
0.0
8
8
23.1
47.5%
1.5
10
9
22.0
2.3
Receive
Size
12
12
386.7
2.0
2
0
7.3
0.0
0.5
10.4%
0.2
1.5
0.8
Loading
Time
2.6
1.5
14.0%
M_samsung
Req
First
No.
Second(Cache)
18
18
5.9
61.7%
7.0
219.4
12.8
2
Sent
Size
2
11.1
11.0
2
2
27.0
0.2
3
3
36.7
0.4
62.1%
0
0
0.0
0.0
Receive
Size
10
10
142.0
1.1
1
1
2.6
0.1
0.3
35.5%
0.2
1.4
0.8
Loading
Time
2.3
1.4
0%
0.0
0.0
0.0
0.0
0.0
0.2
0.2
0.2
M_naver
0.0
auone
First
Req
No.
Second(Cache)
40
28
13.1
32.2%
11.4
187.1
29.8
1
25.2
Sent
Size
1
25.2
4
44.2
0
0.0
1
0
9.5
29.3%
0.0
0
0
0.0
0.0
Receive
Size
0.0
1
0
4.5
27
89.2
21
3.5
0.7
4.3%
0.3
1.7
0.8
Loading
Time
1.4
2.7
0%
Page
25

27. Experiment
by
tuning
Mobile
site
Default
tuning
Req
No.
32.2%
Sent
Size
29.3%
Receive
Size
4.3%
Loading
Time
0%
Aggressive
tuning
inline
more
js
:
2048
-­‐>
20480
inline
more
image
:
2048
-­‐>
6000
Req
No.
47.5%
Sent
Size
46.3%
Receive
Size
5.4%
Loading
Time
28.6%
Page
26

28. Experiment
by
tuning
(Cont’d)
Default
tuning
Mobile
site
Req
No.
61.7%
Sent
Size
62.1%
Receive
Size
35.5%
Loading
Time
M_samsung
w/o
MPS
Request
Count
Sent
Kb
Receive
Kb
HTML
count/size(Kb)
JS
count/size(Kb)
CSS
count/size(Kb)
GIF
count/size(Kb)
JPG
count/size(Kb)
PNG
count/size(Kb)
Loading
Time
(0ms
delay)
Loading
Time
(50ms
delay)
Loading
Time
(100ms
delay)
0%
First
Second(Cache)
47
15.6
340.0
Aggressive
tuning
fla[en_css_imports
:
JpegRecompressionQuality:
100%
-­‐>
75%
Req No.
46
18.6
8.5
2
2
3
12
14
14
5.1
27.9
12.2
8.7
265.9
20.1
0.5
1.4
2.3
1
2
3
12
14
14
66.1%
Sent Size
0.2
66.1%
0.3
0.5
Receive Size
2.9
2.0
66.0%
2.6
0.2
0.8
1.4
Loading Time
118K
33.7%
Page
27

29. Image
Op9miza9on
Page
28

30. Background
§ The
average
web
page
will
hit
2
MB
by
201
5.
§ Image
is
already
a
significant
por9on
of
we
b
page.
§ 61.8%
of
total
web
size
is
image
at
Mar
201
3.
(826KB/1335KB)
§ 62.5%
at
Mar
2012.
(630KB/1008KB)
§ 57.4%
at
Mar
2011.
(445KB/775KB)
Mar
2013
Source
:
HTTP
Archive
Image
is
61.8%
of
total
size.
Page
29

31. How
to
op9mize
image
§ Op9mize
image
formats
§ Op9mize
image
delivery
§ U9lize
Browser
cache
§ Use
CDN
§ Op9mize
image
loading
process
§ Lazy
loading
§ Op9mize
image
for
mobile
§ Responsive
Images
:
RWD
(Responsive
Web
Design)
Page
30

32. Op9mize
image
formats
§ GIF
§ PNG
§ Convert
from
PNG
24
-­‐>
8
§ PNG
Op9miza9on
tools
:
PNGCrush,
Op9PNG
§ JPEG
§ Control
Quality
§ Remove
metadata
§ Op9miza9on
Tools
:
jpegtran,
ImageMagick
§ WebP
§ a
new
image
format
that
provides
lossless
and
lossy
compression
for
images
on
the
web
§ Lossless
WebP
26%
smaller
than
PNG
§ Lossy
WebP
25%
~
34%
smaller
than
JPEG
§ Support
browser
(~26%):
Chrome
9+,
Android
4+,
Opera
12+,
Opera
Mobile
1
1.1+
Page
31

33. Image
Op9miza9on
Item
Descrip9on
§ Recompress
§ Recompress
JPEG(lossy),
PNG,
WEBP(lossy)
images
§ compression
quality
0~100,
-­‐1(lossless)
(re-­‐compressing
jpeg
and
webp
images)
§ Strip
color
profile
informa9on
§ Strip
unnecessary
meta-­‐data
(such
as
thumbnails)
§ Reduc9on
the
color
sampling
of
jpeg
images
§ Transforma9on
§ Op9mize
GIF
image
by
conver9ng(lossless)
to
a
PNG(except
animated
gifs)
§ Conver9ng
GIF
or
PNG
image
to
a
jpeg
(When
it
hasn’t
alpha
channel
or
transpa
rent
pixels)
§ Conver9ng
JPEG
to
WEBP
§ Transforma9on
larger
non-­‐progressive
jpeg
images
into
progressive(fade-­‐in)
jpe
gs
§ Image
Resizing
§ image
resizing
depending
on
screen
size
Page
32

34. Difference
between
FEO
and
Image
Opt.
Request
h[p://www.foo.com/index.html
Response
h[p://image.foo.com/index.html
FEO
(mod_pagespeed)
*ng
forma
Re
a*on
HTML
nsform
nt
tra
Conte
<html>
<script
src="js/jquery.js.pagespeed.jm.LQy2C9DQIS.js"
type="text/javascript"></script>
<img
src=“a.gif.pagespeed.ic.4f4XMOxRCY.png"
alt=""
width="45"
height="44">
</html>
Origin
<html>
<script
src="js/jquery.js"
type="text/javascript"></script>
<img
src=“a.gif"
alt=""
width="45"
height="44">
</html>
Request
h[p://image.foo.com/a.gif.pagespeed.ic.4f4XMOxRCY.png
Response
h[p://image.foo.com/a.gif.pagespeed.ic.4f4XMOxRCY.png
Image
Opt.
Request
h[p://image.foo.com/a.gif
Response
h[p://image.foo.com/a.gif
Origin
Request
h[p://image.foo.com/a.gif
forma*
ge
trans
Ima
on
Image
re-­‐encoding
from
gif
to
png
-­‐
MIME
TYPE
:
image/PNG
Page
33

35. Difference
between
FEO
and
Image
Opt.(Cont’d)
Image
op9miza9on
Traffic
Reduc*on
Image
op9miza9on
Traffic
Reduc*on
Sta9c
Image
Sta9c
Image
Sta9c
Image
Dynamic
Image
Dynamic
Image
Content
Minifica9on
Traffic
Reduc*on
Image
op9miza9on
Traffic
Reduc*on
Dynamic
Image
JS
/
CSS
JS
/
CSS
JS
/
CSS
HTML
HTML
HTML
Origin’s
Web
Content
By
FEO(mod_pagespeed)
By
Image
Op9miza9on
Page
34

36. Experiment
of
Image
Opt.
in
the
field
§ Experiment
of
image
op9miza9on
using
mod_pagespeed
on
real
sit
e
Origin
Data
Total
Data
S
ize(Kbyte)
Image
Op*miza*on
by
mod_pagespeed
Total
Image
Size(Kbyte)
Total
Data
S
ize(Kbyte)
Total
Image
Size(Kbyte)
Total
Opt.
r
a9o
Image
Opt.
ra9o
Processed
I
mage
ra9o
Naver
1,329.9
346.6
1,262.0
263.6
5.1%
23.9%
50.6%
Daum
1,382.1
278.3
1,309.6
225.6
5.2%
18.9%
26.0%
Gmarket
3,264.8
2,989.5
3,176.9
2,923.9
2.7%
2.2%
10.2%
Samsung
1,125.6
1,003.6
453.1
341.8
59.8%
65.9%
96.6%
Auone
279.5
131.6
228.1
86.4
18.4%
34.4%
95.2%
Mobile
Naver
453.9
302.8
456.8
307.4
0.0%
-­‐1.5%
3.1%
Daum
409.4
314.9
365.8
285.0
10.7%
9.5%
19.0%
Gmarket
869.5
802.7
497.7
439.7
42.8%
45.2%
99.9%
Samsung
368.1
314.7
117.5
64.9
68.1%
79.4%
99.7%
Auone
213.4
132.3
172.9
98.4
19.0%
25.7%
We
can
know
how
much
image
is
op9mized
90.5%
PC
§
Processed
Image
Ra9o
=
(Processed
Image
size
/
Total
origin
image
size)
§
We
can
know
how
much
image
data
can
be
op9mized.
If
op9mize
dynamic
image,
we
c
an
reduce
more
image
traffic.
Page
35

37. Experiment
of
Image
Opt.
in
the
field
§ Experiment
of
image
op9miza9on
in
the
field
Origin
Data
Total
Data
Size(KB)
PC
mod_pagespeed
Total
Data
Size(KB)
Total
Ima
ge
Size(KB
)
Total
Ima
ge
Size(KB
)
Image_op*mizer
Total
Opt.
ra9o
Image
Op
t.
ra9o
Processed
Image
ra
9o
Total
Data
Size(KB)
Total
Ima
ge
Size(KB
)
Total
Opt.
ra9o
Image
Op
t.
ra9o
Processed
Image
ra
9o
Naver
436.8
1251.9
367.2
8%
16%
73%
1216.4
313.1
11%
28%
98%
Daum
1110.6
278.5
1116.8
240.4
-­‐1%
14%
88%
1064.5
233.1
4%
16%
86%
Gmarket
8244.7
7888.8
7453.9
7124.6
10%
10%
25%
1428.4
1078.9
83%
86%
101%
Samsung
6177.1
5396.7
1408.3
627.9
77%
88%
70%
1384.5
603.5
78%
89%
89%
Auone
343.5
123.8
302
85.8
12%
31%
90%
305.1
84.7
11%
32%
100%
Mobage
606.9
337.2
574.4
314.3
5%
7%
35%
469
211.0
23%
37%
95%
Gree
417.7
326.1
420.7
319.1
-­‐1%
2%
0%
264.5
173.0
37%
47%
100%
Naver
340.1
209.4
321.3
200.1
6%
4%
42%
330.9
200.1
3%
4%
38%
Daum
298.9
161.2
283.6
160.9
5%
0%
0%
287.1
149.3
4%
7%
72%
Gmarket
2519.3
2368.8
1208.1
1055.3
52%
55%
85%
1183.5
1014.8
53%
57%
87%
Samsung
438.5
262.9
229.9
54.3
48%
79%
88%
227.7
52.0
48%
80%
86%
Auone
Mobil
e
1366.9
585.9
358.4
531.5
322.2
9%
10%
21%
526.8
299.4
10%
16%
93%
298
234.6
266.7
205.9
11%
12%
21%
268.7
205.2
10%
13%
100%
387.8
249.6
296.8
173.5
23%
30%
68%
310.7
172.5
20%
31%
88%
Mobage
Gree
§
Processed
Image
Ra9o
=
(Total
no.
of
processed
image
/
Total
no.
of
origin
image)
§
We
can
know
how
much
image
data
can
be
op9mized.
Page
36

38. U9lizing
Cache
Server
Service
Flow
origin
Image
Opt.
Cache
client
h[p://www.foo.com/a.png
h[p://www.foo.com/a.png Cache-­‐miss
h[p://www.foo.com/a.png
Content-­‐Type
:
Image/PNG
:
a.png
Image
convert
:
PNG
-­‐>
JPEG
Content-­‐Type
:
Image/JPEG
:
a.png
Cache-­‐fill
Content-­‐Type
:
Image/JPEG
:
a.png
h[p://www.foo.com/a.png
Cache-­‐hit
Content-­‐Type
:
Image/JPEG
:
a.png
§ Image
op9miza9on
is
very
CPU-­‐intensive
job.
To
alleviate
load,
it’s
be[er
to
u9lize
cache
server
between
client
and
image
op9miza9o
n.
Page
37

39. Performance
of
FEO
and
Image
Op9miza9on
Page
38

40. Test
Environment
Gomez
Agent
in
CA
US
CDNW
POP
at
Dallas,
US
Origin
Web
2.
Accelera9o
n
of
dynamic
c
ontent
by
CD
MIO
MOD
NW
DWA
INTERNET
Cdnetworks
Cache
POP
Gomez
Agent
Gomez
Agent
KR
Origin
loca9on
:
Dallas,
US
MIO
&
MOD
loca9on
:
Dallas,
US
CDNW
Shield
loca9on
:
Chicago,
US
UK
Singapore
MIO
:
mod
image
op9mizer
MOD
:
mod
page
speed
Page
39

41. Performance
Comparison
Test
case
1.
between
gomez
agent
and
ori
gin
Test
scenario
origin
Gomez
Agent
Web
Contents
for
PC
&
Mobile
2.
between
gomez
agent
and
MI
O
MIO
3.
between
gomez
agent
and
CD
NW
DWA
4.
between
gomez
agent
and
CD
NW
DWA
+
MOD
MOD
5.
between
gomez
agent
and
CD
NW
DWA
+
MIO
MIO
CDNW
EDGE
CDNW
SHIELD
Page
40

42. Performance
Test
using
Gomez
PC
Agent
§
Gomez
Agent
loca9ons
§
§
All
:
San
Jose,
Atlanta,
New
York,
Seoul,
Tokyo,
Madrid,
London
Using
Gomez
FireFox
Agent
§
1.
origin
&
4.DWA
§ Total
Objects
:
195
§ Total
Bytes
:
1004KB
§
6.
DWA+MOD
§ Total
Objects
:
49
§ Total
Bytes
:
652KB
§
7.
DWA+MIO
§ Total
Objects
:
195
§ Total
Bytes
:
518KB
§
Gomez
UA
String
§
Mozilla/5.0
(Windows
NT
6.1;
WOW64;
rv:13.0
;
GomezAgent
3.0)
Gecko/20100101
Firefox/1
3.0.1
4
3
1
2
Page
41

43. Performance
Test
using
Gomez
Mobile
Agent
§
Gomez
Agent
loca9ons
§
§
All:
Tokyo,
Seoul,
London,
New
York,
S
anta
Clara
Using
Gomez
Mobile
Agent
§
1.
origin
&
4.
DWA
§ Total
Objects
:
41
§ Total
Bytes
:
323.3KB
§
6.
DWA+MPS(mod_pagespeed)
§ Total
Objects
:
28
§ Total
Bytes
:
188.4KB
§
7.
DWA+MIO
§ Total
Objects
:
41
§ Total
Bytes
:
146.5KB
§
Gomez
UA
String
§
Mozilla/5.0
(Windows
NT
6.1;
WOW6
4;
rv:13.0;
GomezRecorder
5.0)
Gecko
/20100101
Firefox/13.0.1
4
3
1
2
Page
42

44. Mobile
CDN
Page
43

45. Introduc9on
§ Mobile
operators
needs
:
§ Deliver
be[er
QoE
to
customers
§ Network
op9miza9on
§ Alleviate
mobile
traffic
conges9on
§ Reduce
traffic
and
costs
of
OTT
Content
§ Save
interna9onal
transit
traffic
§ Generate
new
revenue
Page
44

46. What
is
Mobile
CDN
§ Op9mize
the
delivery
of
content
to
end
users
on
any
type
of
wirele
ss
or
mobile
network.
§ Mobile
CDN
is
important
for
MNOs
(Mobile
Network
Operator)
as
t
hey
can
lead
to
significant
savings
and
avoid
network
conges9on.
§ Provide
be[er
UX
(User
Experience)
and
traffic
reduc9on
Page
45

47. Loca9on
of
CDN
inside
the
mobile
network
§ To
get
op9mal
reduc9on
and
accelera9on,
the
CDN
is
placed
inside
the
mobile
network
on
top
of
the
PGW
func9on.
In
case
of
LTE
Internet
*
Network
Address
Translator
IP
Core
LTE
Core
Mail
Web
*
Primary
Gateway
NAT
Cache
Edge
traffic
is
reduced
to
1/10
・・・
inside
Mobile
NW
PGW
-­‐ Video
pacing
SGW
SGW
SGW
-­‐ Image
Op*miza*on
*
Secondary
Gateway
eNB
eNB
eNB
-­‐ Text
Compression
eNB
eNB
eNB
eNB
eNB
eNB
-­‐ TCP
Accelera*on
Page
46

48. Video
Pacing
§ Video
pacing
controls
the
bandwidth
for
progressive
download
video.
§ This
reduces
excessive
video
download
Without Video Pacing
With Video Pacing
Burst
sec*on
Media’s
bitrate
Smooth
sec*on
Page
47

49. Conclusion
Page
48

50. Conclusion
The
more
QoE
is
improved,
the
more
revenue
is
increased
QoE
[L7
improvement]
Content
Op*miza*on
Video
Pacing,
Image
Op*miza*on
and
etc.
• Op9mize
image.
As
reducing
image
size,
can
reduc
e
traffic
and
provide
be[er
QoE.
[L6
improvement]
Adopt
FEO
Technology
HTML
(Presenta*on-­‐level)
Op*miza*on
• FEO
provides
be[er
QoE.
And
tune
FEO
focused
on
display
9me,
not
network
download
9me.
[L5
improvement]
Adopt
SPDY/RE
Technology
HTTP
(Session-­‐level)
op*miza*on
[L4
improvement]
TCP
（Transport-­‐level）Op*miza*on
• Tune
TCP
depending
on
network
type
(3G/LTE/Wir
ed).
[L1-­‐L3
improvement]
Adopt
CDN
(beZer
performance
than
ISP
N/W)
• To
reduce
latency
on
mobile
network,
place
conten
t
closer
to
end-­‐user.
To
do
so,
u9lize
CDN.
Also
can
accelerate
middle
mile.
Page
49

51. Q
&
A
Page
50