1. WebM VP9
1.1. VP8 was getting finalized and now VP9 is new
1.1.1. yah, but it's better
1.2. Uses source frames throughout the video for reuse throughout the video
1.2.1. The source frame is highly optimized
1.2.1.1. vp8's source frame was the basis for WebP the new image format
1.3. Goal is 4th Quarter 2013 to integrate production ready software versions
1.3.1. hardware accelerated will be primary focus after release
2. Instant Mobile Websites
2.1. Bandwidth is not the problem - it's latency
2.2. Load required css in the initial html response to give the user a response right away before the leave
2.3. 14kb is of html before another round trip (even if it's one html file) so keep it less than that
2.3.1. prioritize visible content from there
3. Web Languages and VMs: Why fast code is always in fashion
3.1. Same guys wrote the V8 vm/engine that is writing the Dart vm.
3.1.1. worked together for 12 years on vms
3.1.1.1. smalltalk, hotspot, crankshaft, cldc, jvm, v8, self, Dart
3.1.2. Lars Bak & Kasper Lund
3.2. Where is time spent in the V8 vm
3.2.1. gmail, google docs, google search etc
3.2.1.1. 50-70% V8
3.2.1.2. 30-50% Blink
3.2.2. twitter, facebook, youtube
3.2.2.1. 20-40% V8
3.2.2.2. 60-80% Blink
3.3. Moden JavaScript Engine
3.3.1. general process
3.3.1.1. parser
3.3.1.1.1. multi-teir adaptive compilation
3.3.2. Identify 'hot' heavily used functoinas, attempt to optimize, but if it does dumb js stuff, fallback to the conventional way
3.3.3. Converts prototypes to classes
3.3.4. Didn't invent this
3.3.4.1. 60's
3.3.4.1.1. lisp
3.3.4.2. 70's-80's
3.3.4.2.1. small talk
3.3.4.3. 90's
3.3.4.3.1. self
3.3.4.4. They just added all of them up to v8
3.3.5. Garbage Collection
3.3.5.1. Using generational was new to a browser
3.3.5.2. Has many problems that java has
3.3.5.2.1. many due to how js nodes is cleaned up with tracing while the dom nodes are cleaned up with a number of references pointer
3.3.6. BUT
3.3.6.1. It's still js...
3.3.6.2. v8 started at 100,000 lines, now almost 500,000 lines....
3.4. Welcome to the Dart Side
3.4.1. Why Dart is inately faster than js
3.4.1.1. real objects
3.4.1.2. straightforward language semantics makes it clear the intent and the VM does not have to interrogate an entire block of code to determine its use
3.4.1.3. fewer special corner cases
3.4.1.4. Prototype methods can be overridden in js... not dart
3.4.1.5. less generated code (minify etc)
3.5. Benchmarks
3.5.1. Richards & DeltaBlue benchmark
3.5.2. Richards
3.5.2.1. Dart 1.7x faster than v8
3.5.2.2. dar2js slightly behind v8
3.5.3. DeltaBlue
3.5.3.1. Dart 2x faster than v8
3.5.3.2. dart2js slightly better than v8 --- booyah
3.6. What's next?
3.6.1. Project OilPan
3.6.1.1. re-write the browser garbage collection
3.6.1.2. do all tracing removals so gc doesn't freeze as much and can be smarter
3.6.1.3. Entire web application can be serialized
3.6.1.4. Concurrent manipulation of the DOM
4. Cognitive Science and Design
4.1. Lost my notes
4.2. Mostly referenced some books that designers should read
4.3. Things like our peripheral vision can identify change faster than our direct vision
4.4. Make changes across the board
4.4.1. Don't just change a language, change it to go from right to left, change the back button to be on the right, reverse icons
5. Upgrading to a Chrome Packaged App
5.1. Lots of api's available for chromeos type environments
5.2. very new apis, very specific
5.3. lots of js and other stuff is actually disabled for security
5.4. sounds like a pain in the butt and just not worth it right now
6. True Grit: Debugging CSS & Render Performance
6.1. Chelsea Derric - Senior software engineer on gmail
6.2. Fast is better than slow - google 10 things philosophy
6.2.1. http://www.google.com/about/company/philosophy/
6.3. Use the Chrome Dev Tools timeline
6.3.1. it shows where rendering time is being spent
6.3.2. The Rendering Cycle
6.3.2.1. Build the DOM
6.3.2.2. Calculate CSS property values
6.3.2.3. Build the rendering tree
6.3.2.3.1. Boxes vs Elements
6.3.2.4. Calculate Layout
6.3.2.4.1. tall, wide, top left corner
6.3.2.4.2. height, width, padding, border-width, margin- coordinates (top, right, bottom left)
6.3.2.5. Paint
6.3.2.5.1. Transparency can be expensive, especially anti-aliased text
6.3.2.5.2. layers are painted individually
6.3.2.6. Compositing
6.3.2.6.1. layer bitmaps are transferred to the gpu, combined (composited) and drawn on the screen
6.3.2.6.2. opacity, transform etc
6.3.3. Timeline shows what stages are happening
6.4. Many animations etc cause calculate layout and painting which take a long time and make things look choppy
6.4.1. tricks can be used to do layouting early and only do compositing which is very light weight
6.4.2. transform translate3d 0,0,0
7. Never leaving the DevTools
7.1. Paul Irish
7.2. Workspaces
7.2.1. editing in dev tools can change the source also
7.2.2. And vice versa
7.3. SASS (css toolkit) support
7.4. ADB Extension to chrome dev tools for android
7.5. Lot of cool stuff, need to keep up on this because it would save lots of time
7.5.1. much of what was shown was in canary build so hopefully stable soon enough
8. Get Unstuck - Gamestorming Not Brainstorming
8.1. Book - Must Read
8.2. Brainwriting
8.2.1. everyone individually writes ideas, one per note card
8.2.1.1. for a few minutes
8.2.2. next part pass the cards to the right and everyone elaborate on the previous card
8.2.2.1. after writing down an additional idea, pass it again to the right until time is up
8.2.2.2. for ~5+ minutes
8.2.3. Review cards
8.3. 6-8-5
8.3.1. Fold a single sheet of paper in half 3 times
8.3.1.1. produces 8 squares
8.3.2. Everyone individually elaborates on an idea
8.3.2.1. adds one idea per box
8.3.2.2. can be a single word
8.3.2.3. a picture
8.3.2.4. a phrase
8.3.3. Goal is to get 6-8 ideas within 5 minutes
8.4. $100 investment
8.4.1. All ideas are place don the wall
8.4.2. Everyone writes down $ amounts that would add up to $100 and invest in certain ideas
8.4.3. This is to reduce ideas and get a feel for where people are leaning toward on the team
8.5. Gamestorming Cheat Sheet
8.5.1. bit.ly/gamestorming-cheatsheet
9. WebP - enabling faster, smaller and more beautiful web
9.1. Why WebP is needed
9.1.1. 60 % of desktop sites are images
9.1.2. 59% of mobile sites are images
9.1.3. Screens are getting higher dpi (retina, pixel etc)
9.2. WebP is
9.2.1. Improved data compression
9.2.2. Lossy and lossless modes
9.2.3. Alpha channel, animation ...
9.2.4. Derived from VP8 keyframe (not vp9)
9.2.5. open-source, royalty free formats
9.3. Achievements
9.3.1. On average 30% smaller than PNG for lessless compression
9.3.1.1. Even better for slightly lossy
9.4. Encoding and Decoding
9.4.1. Encoding 5-10x slower than JPEG
9.4.1.1. only bad use case is dynamic imagery... like AFWWEBS
9.4.2. Decoding ~1.3x slower than JPEG
9.4.3. Bandwidth saving vs extra CPU time
9.4.3.1. Most encoding is done upfront, rarely dynamically
9.4.4. Lots of tools support this
9.5. Facebook trial
9.5.1. worked great - FB loved it
9.5.2. People could save a picture but not open it
9.5.2.1. chrome updated so that it will be an app that can open webp images
9.5.3. People would send a url from chrome to a friend using IE, they can't see webp
9.5.3.1. make urls extension agnostic and pick off user agent
9.5.3.1.1. requires 2 versions or a dynamic parser on the fly but it's a way to transition
9.6. Google Is Moving Toward it
9.6.1. google maps
9.6.2. docs
9.6.3. gmail
9.6.4. chrome
9.6.5. youtube
9.6.6. g+
9.6.6.1. on android already - got 50% bytes savings
9.6.7. google play
9.6.8. google image search
10. Google Visualization API
10.1. What
10.1.1. javascript charting api
10.1.2. timeline is new and looks pretty useful
10.1.3. Scatter chart
10.1.4. Bubble Chart
10.1.5. Geo / Map chart
10.1.5.1. differet projections
10.2. Why?
10.2.1. unsure of why, there are a lot of charting apis in js
10.2.2. the timeline one looks like the only real needed one
11. Feature Detection in the Real World
11.1. Basically walks us through a year of her trying to develop for the cutting edge and all the difficulties she had
11.1.1. lots of examples of checking for a feature is not enough, sometimes a feature is only halfway implemented
11.1.2. checking all the api calls needed to do it's job before ever needing them because it's the only safe way
11.2. Ultimate takeaway is don't live on teh chrome (or others) cutting edge for a real serious, money making product
11.2.1. only do it for the experimental and prototype projects needing to help stay ahead of the curve but not super reliable
11.3. Big Expectations
11.3.1. Do NOT assume it's going to be easy
11.3.2. Do NOT just copy the first stackoverflow answer
11.3.3. DO use tried and true techniques
11.3.4. DO try feature detection first
11.3.5. Mix & Match - modernizr, blacklist etc
12. Automating Performance Best Practices with PageSpeed
12.1. Lost my notes =(
12.2. Google released an apache mod and something else to do this many years ago
12.2.1. really no reason not to do this
12.2.2. ngx_pagespeed also
12.3. PageSpeed chrome extension
12.4. LOTS of very smart automations
12.4.1. Hacks the outgoing html to reference exact image sizes, of compressed versions of the image
12.4.1.1. photos/800x450wawesome_cat.png.pagespeed.ic.HASH.webp
12.4.2. Minify JS
12.4.3. Concatenate css files into one
12.4.3.1. yellow.css+blue.css+big.css+bold.css.pagespeed.cc.HASH.css
12.4.3.2. cc = combined css
12.4.3.3. hash = date modified hashing (or smarter)
12.4.4. 40+ optimizations
12.4.4.1. configurable
12.5. Google API services
12.5.1. can route your own website through google servers and control all the settings from a google dashboard
12.5.2. live demo, freaking awesome, freaking smart
12.5.3. first request when the mod enabled does nothing, because it doesn't want to slow down the first request
12.5.3.1. but it will concatenate and cache things for the next requests now that it knows how the page works
12.5.3.2. second page load had all the benefits
12.5.4. Showed a 3 image page example going from ~3MB to 300kb
12.5.5. developers.google.com/speed/pagespeed/service