Optimization of modern web applications

Optimization of
modern web apps

Eugene Lazutkin

ClubAjax on 8/7/2012
Dallas, TX

About me
• Eugene Lazutkin
• Open Source web developer
• Majors: JavaScript & Python, Dojo & Django.
• Independent consultant
• Blog: lazutkin.com
• Twitter: @uhop, Google+: gplus.to/uhop

What’s new?
Browser landscape has
changed

What else is new?

• We are transitioning from static web applications
with JavaScript helpers to dynamic web
applications.
• One-page web applications.
• Interactive grids, charts, CRUD.
• Multimedia is on its way.

Important things
• Individual web requests.
• Event: DOMContentLoaded
• DOM is fully parsed, but not laid out yet.
• Event: load
• All external assets are loaded.
• DOM geometry is calculated.

When can we use it?

• After DOMContentLoaded.
• After load.
• Sometimes between them.
• Example: our app works, yet some images are
being downloaded.

Problem: batching

• A network diagram frequently looks like a staircase.
• Requests are batched.
• Browser limits connections per host.
• Usually 2-8 connections depending on browser
and on HTTP version (1.0 or 1.1).
• Prevents server overload.

Problem: bandwidth

• We need to download a lot of resources.
• Slow connections limit the app.
• The less we download, the better.

Anatomy of connection
• Lifecycle (add browser delays, and network latency
liberally):
1.Client does a DNS lookup (complex operation).
2.Client sends a request (data, headers, cookies).
3.Server gets it, processes it, and sends a
response.
4.Client receives and processes it.

Problem: connections

• Connections are expensive.
• We should reduce their number.

Solution: batching

• Sharding:
• Serve different resources from different hosts.
• Pro: if batching is a bottleneck, that can help
considerably.
• Con: more expensive DNS lookups.

CDN
• Can help with batching and bandwidth at the same
time.
• Can reduce latency for geographically distributed
clients.
• The same problems as sharding.
• You should factor in CDN service costs (usually
inexpensive).

Solution: bandwidth
• Let’s compress all we can.
• Images can be compressed lossy or losslessly.
• Text (JavaScript, CSS, HTML) should be
gzipped.
• It can be preprocessed (miniﬁed) to be even
more compressible.
• Use static compression whenever you can.

Solution: bandwidth

• If we bundle similar resources together usually we
can compress them better.
• Merge all JavaScript.
• Merge all CSS.
• Use sprites instead of separate images.
• Bundling conserves connections too!

Solution: bandwidth

• It makes sense to remove all inlined JavaScript
(<script> blocks, event handlers), and CSS
(<style> blocks) from HTML.
• Images should be converted to sprites.
• Example: <img> can be represented as <div>
with a proper background image.

What I use

• Both Dojo and RequireJS come with a build tool.
• It bundles, and miniﬁes JavaScript.
• It bundles and miniﬁes CSS.
• SmartSprites (http://csssprites.org)
• It can handle vertically and horizontally tiled,
and untiled images.

Problems with
bundling

• 3rd party resources cannot be bundled easily.
• Bundled resources should have the same
expiration.
• Dynamic data cannot be easily bundled.

Solution: connections

• We bundled all we could. Now what?
• Now it is time to go back to basics: network
protocols starting with TCP/IP.

Oh, yes!

• The standard-compliant server sends 3 (three)
packages and waits for ACK.
• It is a part of congestion-controlling algorithm.
• What does it mean for us?
• Client gets 3 packages relatively fast.
• Useful payload is just over 1.5k.

TCP 3 packets rule

• How can we use it?
• If we send an HTML page, try to ﬁt all
external resource requests in the ﬁrst 1.5k.
• If you can keep your HTML page under 1.5k
(compressed) — awesome!

HTTP rules!

• HTTP/1.0 creates one connection per request.
• Expensive.
• HTTP/1.1 allows to reuse the same connection to
request different resources from the same host.
• Double check that you use HTTP/1.1 on
server.

HTTP pipelining
• Part of HTTP/1.1.
• Allows to request several resources without waiting
for response.
• Resources should come in the order of their
requests.
• Frequently turned off.
• Improves high-latency/mobile scenarios.

SPDY

• Introduced by Google.
• Will likely be a part of HTTP/2.0.
• Allows asynchronous requests/responses over a
single connection.
• Allows server push and server hint.

Who supports SPDY?

• Implemented by Chrome/Chromium and Firefox.
• Used by Google, Twitter.
• Announced by Facebook.
• Implemented by most vendors including Apache,
nginx (experimental), most app servers like node.js.
• Server push and hint are rarely implemented.

Ideal web app
<!doctype html>
<html>
<head>
<link rel=”stylesheet” type=”text/css” href=”x.css”>
<!— images are requested from CSS as one sprite —>
<script src=”x.js”></script>
</head>
<body>
<!— HTML here may be dynamically generated —>
</body>
</html>

Now what?

Where to include JS?
• Most gurus recommend to include it in a body as a
last node.
• That’s incorrect in general!
• It works only for “gradual enhancements” scripts.
• Scripts, which provide convenience, not main
functionality.
• Error checking, calendars, and so on.

Where to include JS?

• It is unwise to make it last, if our app functionality
depends on it.
• It renders signiﬁcant parts of out web page.
• It requests data from a server.
• It is the application.
• In our “ideal app” it doesn’t matter where to put it.

Can we reduce it more?
• We can inline CSS and JavaScript back.
• Images can be inlined too using “data:” URI.
• Cons:
• Usually it violates “the same expiration” rule.
• Prevents reuse between pages.
• “data:” URI can increase a ﬁle size.

Problem: dynamic data
• We optimized the web app. Now what?
• Usually the dynamic data requests stick out like a
sore thumb.
• Unlike static ﬁles, such requests do take some
server processing:
• SQL queries, disk I/O, internal network
services.

Solution: dynamic data

• We can try to consolidate several requests required
to render a page into one request.
• We can request this data ﬁrst thing.
• Literally.
• Both XHR and <script> can be used but I
prefer scripts with JSONP.

Data-first idea part 1

• Let’s request the data ﬁrst, if it takes a long time.
• In order to be efﬁcient we cannot rely on any other
JavaScript libraries.
• It will be loaded in parallel with the rest.
• Con: it will occupy a connection slot.
• The result would be stored in a variable.

Data-first idea part 2

• When our main JS is loaded we can check that
variable.
• If it is populated, we can wait until DOM is
ready to render data.
• Otherwise we can override our JSONP callback
function, and wait for data, and for DOM.

Data-first sketch
<!doctype html>
<html>
<head>
<script>
function __load(data){...}
var t = document.createElement("script");
t.src = "/api?timeout=2&callback=__load";
document.documentElement.appendChild(t);
</script>
<link...>
<script...>
</head>
<body>
<!— HTML, if any —>

Cache considerations

• If we expect our user to come again, or
• If we expect it to use other pages of our web app.
• We have to work with cache.

Server-side headers
• Determine expirations of your resources and set all
proper HTTP headers:
• Expires, Last-Modiﬁed, Cache-Control
• If set properly, browser would not even attempt
to connect within their expiration period.
• Set ETag header.
• Sometimes timestamp is not reliable.

Server-side headers
• Proper settings reduce number of connections.
• It allows server to send 304 (not modiﬁed) response
instead of a potentially big resource.
• Don’t forget that some companies and ISPs run
intermediate caches.
• Read http://lazutkin.com/blog/2007/feb/1/
improving-performance/ for more details.

Prime cache
• Sometimes it makes sense to load ﬁles not used by
this web page, which can be used by other pages.
• Usually it is done asynchronously several seconds
later after the page has started.
• Invisible image can be created.
• CSS and JS can be linked.
• They should not interfere with the page!

Or use manifest

• Part of HTML5 to facilitate ofﬂine applications.
• A text ﬁle that lists what should be downloaded and
placed into a permanent cache, network URLs,
and fallback URLs.
• Should be served as “text/cache-manifest”.
• Supported by FF, Cr, Opera, Safari, IE10.

Cache manifest
example
<!doctype html>
<html manifest=”cache.manifest”>
...

<!— cache.manifest example content —>
CACHE MANIFEST
/y.js
/y.css
/y.jpg
/y.html
...

Tools of trade

• Built-in debuggers of modern browsers.
• Firebug.
• Network sniffers.
• HTTPWatch, Fiddler.
• And...

Navigation timing

• For your debugging pleasure you can use
Navigation Timing API.
• A lot of resource-speciﬁc timing information!
• Supported by FF, Cr, IE9.

Picture credits

pie: http://en.wikipedia.org/wiki/File:Wikimedia_browser_share_pie_chart_3.png
really: http://www.ﬂickr.com/photos/zpeckler/3093588439/
http pipelining: http://en.wikipedia.org/wiki/File:HTTP_pipelining2.svg

Optimization of modern web applications

More Related Content

What's hot (20)

Similar to Optimization of modern web applications (20)

More from Eugene Lazutkin (19)

Recently uploaded (20)

Optimization of modern web applications

Editor's Notes