Web Performance
New York, NY
March 19th, 2009
About presenter
- Doing web stuff since 1995
-
Director, Web Systems and Applications at
truTV
-
Personal projects
What is this talk about?
- Performance is how fast your site works
-
NOT how many users it can serve (Scalability)
-
NOT how often it's down (Reliability)
Why do we need to care?
- User experience
-
Money!!!
- +100ms → -1% sales (Amazon) *
-
+400ms → -5-9% full-page traffic (Yahoo! Autos front page) **
- +500ms → -20% searches (Google) ***
Backend
- Usually planned for along with scalability and reliability
-
Usual tree-tier
- Browser (front-end)
- Web/app server
- Relational database
DataBase performance
- use INDEXES!
-
Study set theory basics and use JOINs instead of cursors or code-level
iterations
-
Use correct datatypes to put as much stuff into memory as possible
- Use query cache
- Read documentation for your RDBMS *
Compile
- Compiled code is faster then interpreted
- C/C++ web apps are rare
- ASP.NET and Java compile into bytecode
-
But most of the web is interpreted, use opcode caches
- APC for PHP *
- mod_perl for perl
Cache
-
Cache results
- Shared memory (APC and EAccelerator for PHP)
- memcached
- Cache not even data, but chunks of HTML
- Reverse proxies (Squid)
CDNs or lightweight web servers for static content
-
CDNs are closer to the user and remove load your app servers
- Akamai (also has Edge Suite - reverse proxy)
- Limelight
-
mystaticfiles.net with lightweight servers
- nginx (also reverse proxy)
- lighttpd
Front-end
- Face of the web
- Heavily influenced by marketing, brand and etc.
- Performance wasn't planned for until Web 2.0
- Slowness became noticable by users
Amazon Waterfall!
- Total Requests: 88
- Total Time: 6.344 seconds
-
Back-end Time: 0.968 seconds =
just 15%
CNN Waterfall!
- Total Requests: 174
- Total Time: 4.406 seconds
-
Back-end Time: 0.171 seconds =
less then 4%
Yahoo!
**
YSlow
@ TechPresentations
Best Practices (34 already)
- Make Fewer HTTP Requests
- Use a Content Delivery Network
- Add an Expires or a Cache-Control Header
- Gzip Components
- Put Stylesheets at the Top
- Put Scripts at the Bottom
- Avoid CSS Expressions
- Make JavaScript and CSS External
- Reduce DNS Lookups
- Minify JavaScript and CSS
- Avoid Redirects
- Remove Duplicate Scripts
- Configure ETags
- Make Ajax Cacheable
- Flush the Buffer Early
- Use GET for AJAX Requests
- Post-load Components
- Preload Components
- Reduce the Number of DOM Elements
- Split Components Across Domains
- Minimize the Number of iframes
- No 404s
- Reduce Cookie Size
- Use Cookie-free Domains for Components
- Minimize DOM Access
- Develop Smart Event Handlers
- Choose <link> over @import
- Avoid Filters
- Optimize Images
- Optimize CSS Sprites
- Don't Scale Images in HTML
- Make favicon.ico Small and Cacheable
- Keep Components under 25K
- Pack Components into a Multipart Document
Top Best Practices
Most effective, tested by YSlow
- Make Fewer HTTP Requests
- Use a Content Delivery Network
- Add an Expires or a Cache-Control Header
- Gzip Components
- Put Stylesheets at the Top
- Put Scripts at the Bottom
Top Best Practices (cont'd)
- Avoid CSS Expressions
- Make JavaScript and CSS External
- Reduce DNS Lookups
- Minify JavaScript and CSS
- Avoid Redirects
- Remove Duplicate Scripts
- Configure ETags
More Front-end Best Practices
- Flush the Buffer Early
- Post-load Components
- Preload Components
- Reduce the Number of DOM Elements
- Minimize the Number of iframes
- Optimize Images
- Optimize CSS Sprites
Demo
- YSlow (Firefox)
- Firebug's Net panel (Firefox)
- Fiddler 2 Beta (IE)
-
AOL Page Test /
WebPageTest.org
(IE)
How do I start?
How do I start? Business people
-
use metrics that include site performance, tie it in to your bottom
line (e.g. can you afford loosing 20% of your traffic to 500ms
slowness? What does it cost you to bridge this gap?)
-
incorporate performance testing in QA process (developers should not
care more then you do). Use YSlow - it speaks business language.
-
but be careful, it might be too expensive to excel on all levels
(still cheap to get a lot of improvement)
How do I start? Designers
-
watch
Design Fast Websites
presentation by Nicole Sullivan (Yahoo!, co-author of Smoosh.it)
- start designing experience, not digital paper
- use consistent styles (reusable CSS, cached)
-
don't mandate effects that require heavy lifting on browser side
- Rounded corners can still be fast
- Transparent PNGs can still be fast
- use graceful degradation for less capable browsers (IE6)
How do I start? Front-end developers
- most of it is on your shoulders
- include YSlow grades in your year end review and resume
-
include performance into your definition of good craftmanship (it's a
rare case when you can use TDD effectively)
-
learn how browsers work, DOM, events, if that trick of yours really
makes it faster
-
reduce amount of requests, use one CSS file (load it first), one JS
file (load as late as possible), CSS sprites
- "smush" images, compress CSS and JS, automate it
-
change your code and publishing process to allow infinite expiration
of assets (if you can do that for HTML, ask to double your bonus)
How do I start? Backend developers
-
you should already know what to do - performance culture is ages old
here
-
still heavily depends on your apps and connected to scalability and
reliability
-
use indexes in your databases! Monitor how they perform as you dataset
grows
- use caches (RAM is cheap, disks are even cheaper)
How do I start? System administrators
- talk to designers and developers and even business people
- read RFC 2616 (HTTP) and Apache manual
- configure gzipping (mod_deflate) and expires
- install APC, memcached, Squid, nginx
Tools
-
Diagnostic Tools
-
Content Compressors
-
Server-side
