Bryan McQuade
Richard Rabbat

What you will get from this talk

* How performance affects your site
* Become familiar with page speed
* Learn about four new product features
** Page Speed exports
** Page Speed SDK
** Apache module
** Page Speed for ads, analytics

Web performance 101

* Speed = eyeballs

A bunch of numbers from O'Reilly Velocity Conference, May 2009

Building Blocks

Processing time at the web server

Bandwidth and round-trip time on the network

Parse, resource fetches, layout and render and JavaScript on the client

Example page load

Client
DNS lookup
TCP connect
HTTP request ->

Server
Server processing <- Client Parse & layout Subrequests ->

Three speed guidelines

* Serve fewer bytes
** Compress at serving
** Optimize images
** Minify HTML, JS, CSS
** Cache aggressively: fastest serving is when you don't have to (including pre-caching)
* Parallelize resource downloads
** Optimize the order of styles and scripts (more late)
* Promote modern browsers

New and improved optimization rules

Minimize request size (including length of URL and size of cookie. Trying to fit in a single or as few TCP packets as possible). Particularly important for mobile.

Specify cache validator (need to learn more about this)

Specify character set early. Why? Otherwise browser guesses by buffering content and guessing the charset.

New features: the beacon, export to ShowSlow

Page Speed SDK

* Initially Page Speed was implemented in JavaScript, tightly coupled to Firefox
* Ported Page Speed rules to browser independent C++ library
* Recently released as a C++ SDK
* Download: http://bit.ly/cwx7JX

gomez: tool to be release soon. Looked like an app.
HAR to Page Speed (HAR? A new JSON format to transport info about page load speed) Steve Souders

har_to_pagespeed command line tool included in the Page Speed SDK
Reads a HAR file, emits Page Speed results

mod_pagespeed

Very early in the lifecycle for this product.

An attempt to not tell developers how to speed up their website, but would actually implement it for them.

Automatically optimize things for you.
* Minify HTML, JavaScript, CSS, images
* Content rewriting to reduce serialization
* Portable rewriting engine that can be re-used in other environments
* Open source, under development: http://code.google.com/p/page-speed/

Looks interesting, but possibly dangerous. Would rather do this at build, not at run-time.

Using MD5 for URL fingerprinting seems like a brilliant idea, though. Again, would rather do it at build time.

Looking at ads and trackers

Filter option to analyze ads only, analyze trackers only, analyze content only or analyze the entire page.

Possible future rules under evaluation

Use chunked encoding

* Dynamic responses can be expensive to compute
* But boilerplate header is usually static
* Send header chunk first, then dynamic body later
* Allows browser to begin fetching external JS and CSS sooner
* Big wins for Google properties such as Search and Calendar

Definitely need to learn more about this (will this work with JS declared near the end of the body or would this be a case to move it back to the head)

Minimize the size of early loaded resources

* Modern browsers are much more efficient when fetching resources declared in HTML
* But JS and CSS in the head still blocks the renderer!
* Users stare at a blank screen until these resources are finished being fetched, parsed and executed.
* Load only the minimal JS and CSS
* Use Page Speed "Remove unused CSS" and "defer JS"

Minimize fetches from JavaScript

[This is interesting.]
Modern browsers use speculative fetching to fetch JS resources in parallel.
Speculative fetcher only parse HTML.
Resources fetched using JavaScript are still serialized.

Page Speed for Chrome: There will be a Chrome extension integrated with Chrome Developer Tools coming later this year.

code.google.com/speed/page-speed/
http://code.google.com/p/page-speed/
http://groups.google.com/group/page-speed-discuss