igrigorik

8 ms·

31.
Capability Reporting with Service Worker(igvita.com)
10 points by igrigorik 12y ago|0 comments
32.
by igrigorik 12y ago
Once again, I'm not arguing against SW. We should be thinking about how to deliver the best of both worlds: a great experience for older (non-SW) browsers, and an even better experience for those that do. The underlying patterns are e
33.
by igrigorik 12y ago
And I replied on G+, but also in short: do a background version ping, force a revalidation if version has changed. Gnarly, yes, but works. :-)
34.
by igrigorik 12y ago
To be clear, my squabble is not an argument against SW in any way. SW affords a lot more control to the developer and makes this pattern significantly simpler to implement and deploy. I'm simply pointing out that you can get most (if n
35.
No need to wait for ServiceWorker – speed up your site today(plus.google.com)
21 points by igrigorik 12y ago|7 comments
36.
by igrigorik 12y ago
Actually, you're both right. With http/2 the server can push critical assets delivering similar results. But, that requires that the server supports http/2 and is smart enough to initiate the push, AND those resources are sam
37.
by igrigorik 12y ago
No, HTTP/2 has no effect on this. The insight here is that we're initiating the fetch for the HTML and its critical resources in parallel... which requires that the page initiating the navigation knows which critical resources a
38.
by igrigorik 12y ago
Yes, the hope is that they will be! That's why we're working on the "Resource Hints" spec, which documents "reactive prefetch" as one of explicit use cases: https://cdn.rawgit.com/w3c/resou
39.
by igrigorik 12y ago
Actually, this is already handled with <a ping>, see earlier post: https://plus.google.com/+IlyaGrigorik/posts/fPJNzUf76Nx - you're right it's a big latency improvement!
40.
Reactive prefetch on Google Search: 100-150ms speedup(plus.google.com)
169 points by igrigorik 12y ago|90 comments
41.
by igrigorik 12y ago
re 1: see https://istlsfastyet.com/
42.
by igrigorik 12y ago
For the record, it's worth noting that we're starting from a state that's nothing short of disastrous: https://alexgaynor.net/2014/nov/12/state-of-news-tls/ Let's hope that twelve mon
43.
Extensible Web Resource Loading Manifesto(igvita.com)
5 points by igrigorik 12y ago|0 comments
44.
Optimizing Webfont Selection and Synthesis(igvita.com)
1 points by igrigorik 12y ago|0 comments
45.
Learning from Apple’s livestream perf fiasco(perf.fail)
11 points by igrigorik 12y ago|0 comments
46.
by igrigorik 12y ago
Have a favorite perf fail story? Share it at: http://perf.fail/submit ... Let's fail forward together! :)
47.
Resource Hints: preconnect, preload, prefetch, prerender(igrigorik.github.io)
2 points by igrigorik 12y ago|0 comments
48.
by igrigorik 12y ago
It's a noop.
49.
by igrigorik 12y ago
Then you're "stuck" with a script loader. Make sure your script loader is itself not being blocked on CSSOM, and is not blocking DOM construction.
50.
by igrigorik 12y ago
Unfortunately defer is broken in bunch of browsers - doesn't preserve order, etc. As a result, if you need to preserve order, you're better off with the async function queueing pattern. Also, if you need to wait for DOM/CSSOM
51.
by igrigorik 12y ago
"Doesn't take up any real resources" is anything but true. An iframe in particular is basically a new render process, which adds a lot of overhead. Just because you've set "display:none" on an element doesn&#x2
52.
by igrigorik 12y ago
To clarify, both script-injected and regular <script> tags block on CSSOM: there is no difference there. Only the "async" attribute on script (i.e. <script async>) removes the dependency on CSSOM... which is why you sh
53.
by igrigorik 12y ago
If you want to initiate an early fetch, just put the <script async> tag at the top - you won't block DOM construction or block on CSSOM. If you need ordered execution, put your inline script block above CSS and add your logic the
54.
by igrigorik 12y ago
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 ,
55.
by igrigorik 12y ago
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 c
56.
by igrigorik 12y ago
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 rollba
57.
Script-injected "async scripts" considered harmful(igvita.com)
235 points by igrigorik 12y ago|56 comments
58.
by igrigorik 12y ago
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. Discl
59.
by igrigorik 12y ago
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
60.
by igrigorik 12y ago
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

More ›