May 20, 2010 - Comments Off on Live blogging Google I/O: Optimize every bit of your site serving and web pages with Page Speed
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
Processing time at the web server
Bandwidth and round-trip time on the network
Example page load
HTTP request ->
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
* 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
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.
* 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"
[This is interesting.]
Modern browsers use speculative fetching to fetch JS resources in parallel.
Speculative fetcher only parse HTML.
Page Speed for Chrome: There will be a Chrome extension integrated with Chrome Developer Tools coming later this year.