igrigorik

If you put a blocking script at the bottom you're still stuck waiting for CSSOM. If you put a script-injected tag at the bottom you're also blocked on CSSOM and your script is not discoverable by the preloader. For more details , see the comparison table in the post.

Yes, and that's what I'm implying. Even if we did speculative execution, that still wouldn't give us the benefits of being preload friendly. We have a better solution that works in all modern (and even old) browsers, and we can now drop the unnecessary baggage of script-injected scripts.

In order to know that you need to execute it - therein is the problem. One idea we've been kicking around (on Chrome team) is to do "speculative execution" where we create a snapshot and start executing the script, and rollback if you start doing anything crazy with the CSSOM/DOM... As you can imagine, this requires some careful engineering and has its own (long) list of gotchas. No ETA, but definitely something that's on the table.

Curious, could you elaborate? The wiki page is long, not sure what I'm looking for... It seems like "triple-entry" is often used alongside "momentum accounting", but its not clear to me why they are conflated. Disclaimer: I'm no accountant, so the simple terms are good. :)

Yes, it will be. The rate itself obviously depends on number of transactions and amount of data per transaction.. Both of those are specific to your implementation.

That said, as a reference, a Bitcoin transaction today is anywhere between ~160~1000 bytes, and the full block chain is on the order of tens of GBs. Is that a problem? It can be. To address this, Bitcoin uses Merkle trees and "Simple Payment Verification" (SPV) -- worth looking into, if you're interested.. long discussion on its own. I'll just note that SPV changes what you can say about integrity/security of the transaction.

Wikipedia has a nice list of various proof-of-work functions: https://en.wikipedia.org/wiki/Proof-of-work_system#List_of_p...

As for "lottery", I believe the answer is yes and no. The basic point is to raise the cost of "faking" a confirmation, and how you do that is completely up to you - e.g. captchas are a great example! That said, the random part of the non-deterministic process provides a lot of really nice properties for a distributed system - fairness claims, etc. That said, this is a deep topic (with lots of caveats) in its own right.

This behavior is not defined by the spec / left to the UA. At the moment, I don't believe either WebKit or Blink implementation will swap the image on (desktop) zoom.

They're complementary. <picture> uses subset of original srcset spec to meet the "resolution switching" use case - e.g. see Example 1 [1]. If you want to select an asset based on viewport width, then you'd either use "sizes" attribute on picture, or a combination of srcset + sources + sizes.

[1] http://picture.responsiveimages.org/#examples

As far as the browser is concerned, there is no distinction between icon fonts or any other fonts. If your icon font fails to load within 3s then it'll go ahead and try to paint the page with a fallback -- the results of that will vary based on how your icon font is setup / what glyphs it maps to.

If you want to define own load behavior: use the upcoming Font Load Events API.

We instrumented Chrome and measured the download times: approximately ~1.1% of font loads are longer than 3s. New timeout will help address that 1.1% by using a system fallback.

http://www.igvita.com/2014/01/31/optimizing-web-font-renderi...

I don't know the details of your benchmark methodology or setup (server / client), so not sure I can offer a meaningful response... short of: let's not confuse "my benchmark failed" with "the future doesn't work". Anything from a poorly implemented server (broken multiplexing, flow control, prioritization, etc), to bugs in past versions of Chrome...

Jetty guys had a couple of nice demos they showed off at various conferences. Here's one: http://www.youtube.com/watch?v=4Ai_rrhM8gA

Seems coincidental. Just highlights that we need HTTP/2, and the sooner the better... Inventing your own app-layer multiplexing on top of HTTP (via base64 chunks - ugh), is not an interesting problem to be solving in 2014.

We have a lot to learn on how to use server push effectively. That said, let's analyze some actual use case..

a) Page A currently inlines half dozen small assets on every page. These inlined resources inflate every page and are delivered at same priority as HTML. By contrast, a "dumb push" server delivers these same assets as individual resources via push. Net benefit? Basically same performance since inlining is a form of application-layer push. However, a smart server can at least prioritize and multiplex push bytes in a smarter way... Now, let's make the server just a tiny bit smarter. If it's the same TCP connection and the server has already pushed the resource, don't push it on next request. Now we're also saving bytes... <insert own smarter strategy here>.

b) Page B has two CSS and one JS file in the critical rendering path. Without push you either inline all three (ouch), or, you roundtrip to the client and get it to parse the HTML to discover these resources and come back to the server... With push, the server can avoid the extra RTT and push those assets directly to the client -- this is a huge performance win. How does the server know? Well, either you made it smart.. or you use some adaptive strategy like looking at past referrers and building a map of "when client requests X, they also come back for Y and Z" - this is already available in Jetty.

The fears of extra bytes are also somewhat exaggerated (they're valid, but exaggerated). The client, if they desire, can disable push. The client can also use flow-control to throttle how much data can be transferred in first push window (both FF and Chrome do this already). Lastly, the client can always decline and/or RST a push resource.

Some additional resources: - http://chimera.labs.oreilly.com/books/1230000000545/ch12.htm... - http://www.igvita.com/2013/06/12/innovating-with-http-2.0-se...

Short answer, yes. Longer answer, there are two ways QUIC can succeed:

a) QUIC makes headway on its own, delivers significant perf win, moves to IETF and becomes a standalone protocol in the long run. b) TCP and TLS leverage techniques & lessons learned from QUIC.

Either way, the users will win. It's too early to tell which of these paths it'll take.. But I do know that both TLS and TCP groups are paying close attention to QUIC and there are already discussions on how to improve performance based on some of the ideas being prototyped in QUIC.

Some recent SPDYv3 vs HTTPS performance numbers from various Google properties: http://blog.chromium.org/2013/11/making-web-faster-with-spdy...

Wohoo! https://twitter.com/jnunemaker/status/420634885552754688 :)

You guys are awesome. Kudos!

If by ouch, you mean AWESOME. Then I'm totally with you! Wohoo!

No need to buy anything, it's an MIT-licensed project, and a trivial implementation under the hood to boot. If I wasn't learning Go while writing it, I think it would take all of 5-10 minutes to replicate (including deploying to prod)... :-)

What I wish GitHub would do is allow us to specify our own GA profile in project settings and just add an extra two lines of JavaScript in their pages to beacon the right metrics directly to GA. They're already using GA on their pages, so adding an additional profile is trivial. [1]

A proper GA integration would eliminate the need to proxy requests, and give us (repo owners) more metrics: I'm most interested in referral information - aka, how are people finding my repo. Also, it would enable analytics on all pages (e.g. source files, etc).

If anyone from GH is reading this... Please? :-)

[1] https://developers.google.com/analytics/devguides/collection...

Yup, that's a great tip. For those not familiar with OSCP stapling: http://chimera.labs.oreilly.com/books/1230000000545/ch04.htm...

Doh! On it.. In the meantime, this is the link you want: https://developers.google.com/chrome-developer-tools/docs/re...

I think there is something else going on here. While it's plausible that different browsers may introduce some processing latency, we are definitely not talking about 100ms+ delays, or 30 to 8Mbit throughput drop. More likely.. try disabling your extensions, see if that helps. If that doesn't help, try creating a new profile.

AFAIK, no.. Maybe in private. If you're interested, checkout the Chromium source, there is a basic demo server checked in. Perhaps more importantly, we don't encourage people to at this point because it's a fast moving target with high code churn... unless you're willing to keep up. :)

For more, head to: http://bit.ly/quic-group

That's not a joke - it's true... The joke part of it is in: there are two types of systems at Google, the ones that are deprecated, and the ones that are not yet ready for production.

Effectively, you're describing socket pooling and re-use.. across sessions / tabs / windows. Most browsers already have this in place. :)

Some details on Chrome implementation here: http://www.igvita.com/posa/high-performance-networking-in-go...

The goals section in the design doc provides a high-level comparison (and motivation behind "why QUIC"): https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...

TCP is not going away anytime soon... If anything, the hope is that QUIC can help improve TCP in the long run -- but first, we need to validate a lot of the design assumptions. :)

A comparison of the different hints, and which browsers support them: http://chimera.labs.oreilly.com/books/1230000000545/ch10.htm...

I'm not even sure what side effects "display: none" would have here.. But that's beside the point. The point of prerendering is to to deliver an instant "swap" of the prerendered tab when the user navigates to that page - think of it as a hidden tab, which gets swapped in for your current one. As a result, the render is "instant". With iframe.. you obviously don't get that.

Yep, that's how it's implemented.