1. Web Languages and VMs: Why fast code is always in fashion
1.1. Same guys wrote the V8 vm/engine that is writing the Dart vm.
1.1.1. worked together for 12 years on vms
1.1.1.1. smalltalk, hotspot, crankshaft, cldc, jvm, v8, self, Dart
1.1.2. Lars Bak & Kasper Lund
1.2. Where is time spent in the V8 vm
1.2.1. gmail, google docs, google search etc
1.2.1.1. 50-70% V8
1.2.1.2. 30-50% Blink
1.2.2. twitter, facebook, youtube
1.2.2.1. 20-40% V8
1.2.2.2. 60-80% Blink
1.3. Moden JavaScript Engine
1.3.1. general process
1.3.1.1. parser
1.3.1.1.1. multi-teir adaptive compilation
1.3.2. Identify 'hot' heavily used functoinas, attempt to optimize, but if it does dumb js stuff, fallback to the conventional way
1.3.3. Converts prototypes to classes
1.3.4. Didn't invent this
1.3.4.1. 60's
1.3.4.1.1. lisp
1.3.4.2. 70's-80's
1.3.4.2.1. small talk
1.3.4.3. 90's
1.3.4.3.1. self
1.3.4.4. They just added all of them up to v8
1.3.5. Garbage Collection
1.3.5.1. Using generational was new to a browser
1.3.5.2. Has many problems that java has
1.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
1.3.6. BUT
1.3.6.1. It's still js...
1.3.6.2. v8 started at 100,000 lines, now almost 500,000 lines....
1.4. Welcome to the Dart Side
1.4.1. Why Dart is inately faster than js
1.4.1.1. real objects
1.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
1.4.1.3. fewer special corner cases
1.4.1.4. Prototype methods can be overridden in js... not dart
1.4.1.5. less generated code (minify etc)
1.5. Benchmarks
1.5.1. Richards & DeltaBlue benchmark
1.5.2. Richards
1.5.2.1. Dart 1.7x faster than v8
1.5.2.2. dar2js slightly behind v8
1.5.3. DeltaBlue
1.5.3.1. Dart 2x faster than v8
1.5.3.2. dart2js slightly better than v8 --- booyah
1.6. What's next?
1.6.1. Project OilPan
1.6.1.1. re-write the browser garbage collection
1.6.1.2. do all tracing removals so gc doesn't freeze as much and can be smarter
1.6.1.3. Entire web application can be serialized
1.6.1.4. Concurrent manipulation of the DOM
2. Cognitive Science and Design
2.1. Lost my notes
2.2. Mostly referenced some books that designers should read
2.3. Things like our peripheral vision can identify change faster than our direct vision
2.4. Make changes across the board
2.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
3. Upgrading to a Chrome Packaged App
3.1. Lots of api's available for chromeos type environments
3.2. very new apis, very specific
3.3. lots of js and other stuff is actually disabled for security
3.4. sounds like a pain in the butt and just not worth it right now
4. Get Unstuck - Gamestorming Not Brainstorming
4.1. Book - Must Read
4.2. Brainwriting
4.2.1. everyone individually writes ideas, one per note card
4.2.1.1. for a few minutes
4.2.2. next part pass the cards to the right and everyone elaborate on the previous card
4.2.2.1. after writing down an additional idea, pass it again to the right until time is up
4.2.2.2. for ~5+ minutes
4.2.3. Review cards
4.3. 6-8-5
4.3.1. Fold a single sheet of paper in half 3 times
4.3.1.1. produces 8 squares
4.3.2. Everyone individually elaborates on an idea
4.3.2.1. adds one idea per box
4.3.2.2. can be a single word
4.3.2.3. a picture
4.3.2.4. a phrase
4.3.3. Goal is to get 6-8 ideas within 5 minutes
4.4. $100 investment
4.4.1. All ideas are place don the wall
4.4.2. Everyone writes down $ amounts that would add up to $100 and invest in certain ideas
4.4.3. This is to reduce ideas and get a feel for where people are leaning toward on the team
4.5. Gamestorming Cheat Sheet
4.5.1. bit.ly/gamestorming-cheatsheet
5. Google Visualization API
5.1. What
5.1.1. javascript charting api
5.1.2. timeline is new and looks pretty useful
5.1.3. Scatter chart
5.1.4. Bubble Chart
5.1.5. Geo / Map chart
5.1.5.1. differet projections
5.2. Why?
5.2.1. unsure of why, there are a lot of charting apis in js
5.2.2. the timeline one looks like the only real needed one
6. Feature Detection in the Real World
6.1. Basically walks us through a year of her trying to develop for the cutting edge and all the difficulties she had
6.1.1. lots of examples of checking for a feature is not enough, sometimes a feature is only halfway implemented
6.1.2. checking all the api calls needed to do it's job before ever needing them because it's the only safe way
6.2. Ultimate takeaway is don't live on teh chrome (or others) cutting edge for a real serious, money making product
6.2.1. only do it for the experimental and prototype projects needing to help stay ahead of the curve but not super reliable
6.3. Big Expectations
6.3.1. Do NOT assume it's going to be easy
6.3.2. Do NOT just copy the first stackoverflow answer
6.3.3. DO use tried and true techniques
6.3.4. DO try feature detection first
6.3.5. Mix & Match - modernizr, blacklist etc
7. Automating Performance Best Practices with PageSpeed
7.1. Lost my notes =(
7.2. Google released an apache mod and something else to do this many years ago
7.2.1. really no reason not to do this
7.2.2. ngx_pagespeed also
7.3. PageSpeed chrome extension
7.4. LOTS of very smart automations
7.4.1. Hacks the outgoing html to reference exact image sizes, of compressed versions of the image
7.4.1.1. photos/800x450wawesome_cat.png.pagespeed.ic.HASH.webp
7.4.2. Minify JS
7.4.3. Concatenate css files into one
7.4.3.1. yellow.css+blue.css+big.css+bold.css.pagespeed.cc.HASH.css
7.4.3.2. cc = combined css
7.4.3.3. hash = date modified hashing (or smarter)
7.4.4. 40+ optimizations
7.4.4.1. configurable
7.5. Google API services
7.5.1. can route your own website through google servers and control all the settings from a google dashboard
7.5.2. live demo, freaking awesome, freaking smart
7.5.3. first request when the mod enabled does nothing, because it doesn't want to slow down the first request
7.5.3.1. but it will concatenate and cache things for the next requests now that it knows how the page works
7.5.3.2. second page load had all the benefits
7.5.4. Showed a 3 image page example going from ~3MB to 300kb
7.5.5. developers.google.com/speed/pagespeed/service
8. WebM VP9
8.1. VP8 was getting finalized and now VP9 is new
8.1.1. yah, but it's better
8.2. Uses source frames throughout the video for reuse throughout the video
8.2.1. The source frame is highly optimized
8.2.1.1. vp8's source frame was the basis for WebP the new image format
8.3. Goal is 4th Quarter 2013 to integrate production ready software versions
8.3.1. hardware accelerated will be primary focus after release
9. Instant Mobile Websites
9.1. Bandwidth is not the problem - it's latency
9.2. Load required css in the initial html response to give the user a response right away before the leave
9.3. 14kb is of html before another round trip (even if it's one html file) so keep it less than that
9.3.1. prioritize visible content from there
10. True Grit: Debugging CSS & Render Performance
10.1. Chelsea Derric - Senior software engineer on gmail
10.2. Fast is better than slow - google 10 things philosophy
10.2.1. http://www.google.com/about/company/philosophy/
10.3. Use the Chrome Dev Tools timeline
10.3.1. it shows where rendering time is being spent
10.3.2. The Rendering Cycle
10.3.2.1. Build the DOM
10.3.2.2. Calculate CSS property values
10.3.2.3. Build the rendering tree
10.3.2.3.1. Boxes vs Elements
10.3.2.4. Calculate Layout
10.3.2.4.1. tall, wide, top left corner
10.3.2.4.2. height, width, padding, border-width, margin- coordinates (top, right, bottom left)
10.3.2.5. Paint
10.3.2.5.1. Transparency can be expensive, especially anti-aliased text
10.3.2.5.2. layers are painted individually
10.3.2.6. Compositing
10.3.2.6.1. layer bitmaps are transferred to the gpu, combined (composited) and drawn on the screen
10.3.2.6.2. opacity, transform etc
10.3.3. Timeline shows what stages are happening
10.4. Many animations etc cause calculate layout and painting which take a long time and make things look choppy
10.4.1. tricks can be used to do layouting early and only do compositing which is very light weight
10.4.2. transform translate3d 0,0,0
11. Never leaving the DevTools
11.1. Paul Irish
11.2. Workspaces
11.2.1. editing in dev tools can change the source also
11.2.2. And vice versa
11.3. SASS (css toolkit) support
11.4. ADB Extension to chrome dev tools for android
11.5. Lot of cool stuff, need to keep up on this because it would save lots of time
11.5.1. much of what was shown was in canary build so hopefully stable soon enough
12. WebP - enabling faster, smaller and more beautiful web
12.1. Why WebP is needed
12.1.1. 60 % of desktop sites are images
12.1.2. 59% of mobile sites are images
12.1.3. Screens are getting higher dpi (retina, pixel etc)
12.2. WebP is
12.2.1. Improved data compression
12.2.2. Lossy and lossless modes
12.2.3. Alpha channel, animation ...
12.2.4. Derived from VP8 keyframe (not vp9)
12.2.5. open-source, royalty free formats
12.3. Achievements
12.3.1. On average 30% smaller than PNG for lessless compression
12.3.1.1. Even better for slightly lossy
12.4. Encoding and Decoding
12.4.1. Encoding 5-10x slower than JPEG
12.4.1.1. only bad use case is dynamic imagery... like AFWWEBS
12.4.2. Decoding ~1.3x slower than JPEG
12.4.3. Bandwidth saving vs extra CPU time
12.4.3.1. Most encoding is done upfront, rarely dynamically
12.4.4. Lots of tools support this
12.5. Facebook trial
12.5.1. worked great - FB loved it
12.5.2. People could save a picture but not open it
12.5.2.1. chrome updated so that it will be an app that can open webp images
12.5.3. People would send a url from chrome to a friend using IE, they can't see webp
12.5.3.1. make urls extension agnostic and pick off user agent
12.5.3.1.1. requires 2 versions or a dynamic parser on the fly but it's a way to transition
12.6. Google Is Moving Toward it
12.6.1. google maps
12.6.2. docs
12.6.3. gmail
12.6.4. chrome
12.6.5. youtube
12.6.6. g+
12.6.6.1. on android already - got 50% bytes savings
12.6.7. google play
12.6.8. google image search