Web sites can be fast and responsive once you understand the process web browsers use to load and run web pages. We'll look at using tools like WebPageTest to analyze and optimize web pages.
call girls in Vaishali (Ghaziabad) 🔝 >༒8448380779 🔝 genuine Escort Service 🔝✔️✔️
PrairieDevCon 2014 - Web Doesn't Mean Slow
1.
2. ● Maintains jQuery code and docs
● Supports web developers and standards
● Participates in standards process
○ W3C web standards
○ ECMA 262 (JavaScript)
jQuery Foundation
18. “Programmers waste enormous amounts of
time thinking about, or worrying about, the
speed of noncritical parts of their
programs, and these attempts at efficiency
actually have a strong negative impact
when debugging and maintenance are
considered. We should forget about small
efficiencies, say about 97% of the time;
premature optimization is the root of all
evil. Yet we should not pass up our
opportunities in that critical 3%.”
--Donald Knuth
19. “Programmers waste enormous amounts of
time thinking about, or worrying about, the
speed of noncritical parts of their
programs, and these attempts at efficiency
actually have a strong negative impact
when debugging and maintenance are
considered. We should forget about small
efficiencies, say about 97% of the time;
premature optimization is the root of all
evil. Yet we should not pass up our
opportunities in that critical 3%.”
--Donald Knuth
20.
21. Client-side issues often can be solved by
"peephole" optimizations and don't require
massive architecture changes
Many — most! — speedups can be done near
the end of the project (or even after
deployment, cough)
Finding and Fixing the 3 Percent
22. With all the other things going on in a web
page, it's unlikely the run time of your
JavaScript is in the 3% worst case.
However, your JavaScript may be doing
things that cause bad performance by
making the browser do more work.
It's Not the JavaScript, Probably
23. Use the tools available (online and inside
the browser) to determine where the
bottlenecks lie, and fix them.
Don't Guess, Measure
29. ● HTML is fully loaded, may be partially
shown to the user already
● Images may not be loaded yet
● DOMContentLoaded event
● jQuery lets you have functions to run
○ $(document).ready()
● These may modify the document
Document Ready
31. Now It May Seem Obvious, But...
Resources outside the HTML file can't be
prefetched, resulting in further delays
e.g. stuff injected by JavaScript/jQuery
JS frameworks (Angular, Backbone) or
initial content from client-side templates
can make the prefetcher useless
32. From top to bottom of the page:
● Render-blocking CSS
● Fonts
● Scripts
Avoid CSS @import and font loading when
possible, they block rendering
Resource Order Is Important
35. ● Avoid 3xx redirects
● Start requests early
● Minimize number of requests
● Minimize byte size of requests
● Maximize browser cache usage
● Spread requests across domains
● Load non-critical stuff later
Rules of the Road
36. Redirecting to another page penalizes load
time by a full network round-trip!
Unfortunately this can't always be avoided,
search engines like "canonical URLs".
Avoid 3xx redirects
37. Put references to resources (e.g., images)
in the HTML first delivered to the browser,
so the prefetcher can "see" them.
Start Requests Early
38. Manual Prefetching
Lets the browser get a running start on
template content or later pages.
<link rel="dns-prefetch" href="http://media.mysite.com">
<link rel="prefetch" href="/img/kitten.jpg">
<link rel="prefetch" href="/step2.html">
39. Combine similar resources (scripts, CSS,
images) and download as a single file (or at
least a small number of files).
Weigh tradeoff of combining vs. CDNs or
reusing subsets on multiple pages to take
advantage of browser caching.
Minimize Number of Requests
40. Use tools like CSSMin and Uglify.js to
squeeze out useless bytes in source files.
Compress images, avoid HTML cropping.
Enable gzip compression on the server.
Minimize Size of Requests
41. Make sure your server sets appropriate
headers on content so the client can cache
it. Don't expire content quickly unless it
changes quickly! (Hint: Your company logo
doesn't change quickly.)
Maximize Browser Cache Usage
42. To maximize bandwidth, request resources
from 2 or 3 domains at once; this is called
domain sharding.
A Content Distribution Network (CDN) can
provide high-speed delivery of commonly
used resources like jQuery.
Spread Requests Across Domains
43. Wait until after page load to fetch things
that aren't needed until well after the page
has been loaded:
● Content not initially visible
● Social media scripts and styles
● Advertising
● Page analytics
Load Non-Critical Stuff Later
44. Any code you include via a <script> tag has
complete control over the performance and
functionality of the page. It can do
anything it wants to the user.
Do You Trust Third-Party Code?
47. ● Revives old crusty cold inside IE
● Restores old incompatible behavior
● Removes new fast JavaScript APIs
● Makes IE much slower and stranger
● Makes me (and users) cry
<meta http-equiv="X-UA-Compatible" content="IE=8">
How Compat View Works
48. ● Don't use outdated jQuery or plugins
● Always specify a VALID doctype
● Don't use browser sniffing
○ Use Modernizr instead
How to Avoid Compat View
56. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" xmlns:fb="http://www.facebook.com/2008/fbml">
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" />
<title>Breaking News and Opinion on The Huffington Post</title>
IE Parser Restart (IE9 or earlier)
57. Blocking Resources (Horizontal)
Invalid doctype, restarts because
of an X-UA-Compatible tag
Ran out of connections, had to wait
for previous downloads
Some JS files loaded before CSS,
which will delay rendering
TOO MANY REQUESTS FOR
JAVASCRIPT FILES !!!!!1!ONE!
69. ● Simple scripting language
○ Lets you e.g. automate a login
● Share links to test runs
○ "Here's what our site looks like from Toronto
using IE8 on a DSL-speed link."
Even More!
72. You Have 16 Milliseconds … Begin
60 frames/second ~ 16 milliseconds/frame
Long-running operations can make the page
appear "janky" rather than smooth.
Really long-running operations can make
the page appear unresponsive to the user.
73. It Happens in 16 Milliseconds?
From High Performance Browser Networking by Ilya Grigorik (O'Reilly)
74. Your JavaScript shares a thread with the
browser's layout calculation and screen
painting; they can't happen in parallel.
Only a few things like downloading, image
decoding, and garbage collection are done
on independent threads.
To Make Things Worse...
75. Don't ask the browser to do a bunch of work
to answer a question if you could easily
find/remember the answer yourself.
Forced Layouts
77. "The Dot That Ate Performance"
console.time("init");
$("body").removeClass("activated");
$("p:visible").css("color", "blue");
console.timeEnd("init");
78. ● Select all <p> in the document
● Ask the browser if any are visible
○ Browser may need to recalculate layout
dimensions if the document has changed
What $("p:visible") Means
80. What If We Track Visibility?
console.time("init");
$("body").removeClass("activated");
$("p.visible").css("color", "blue");
console.timeEnd("init");
Note: Normally you'd use a more descriptive class name than "visible"!
82. ● Avoid document-wide style/class change
○ Use data- attrs or jQuery .data() to store
non-stylistic data unrelated to presentation
● Get JavaScript out of the path
○ CSS transitions
○ CSS animations
Avoiding Forced Layout
84. A page that loads quickly is great, but
letting the user accomplish their task is
your ultimate goal. Reduce the amount of
waiting, clicking, typing, and searching the
user must do to accomplish their task.
Optimize for User Tasks
