Thursday, January 28, 2016

I'll give a quick overview about how AMP achieves its performance and then will be available for Q&A in this Hangout...

I'll give a quick overview about how AMP achieves its performance and then will be available for Q&A in this Hangout on Air tomorrow morning! Looking forward to all of your questions!

And there will be a video on YouTube after, of course.

Tune in at:
https://plus.google.com/events/ch231bul4ql7c2cer88fucq5n3k
https://plus.google.com/events/ch231bul4ql7c2cer88fucq5n3k

Thursday, January 21, 2016

I participated in a little Twitter discussion today (https://twitter.com/nolanlawson/status/690173930594766848) and...

I participated in a little Twitter discussion today (https://twitter.com/nolanlawson/status/690173930594766848) and was asked to write up my recommendations, so here we go:

One of the challenges of adding concurrency to web apps is that some APIs require sync execution – and a fully concurrent app, where the app runs on a different Worker thread from the UI thread, cannot directly make such sync calls.

Fortunately the number of APIs that are relevant here is pretty small:
- event.preventDefault(): E.g. if you want a tag to not actually directly go to that link. Also often needed with touch events.
- window.open(…): Because popups are blocked if they don't get opened synchronously from a click handler.
- Probably 1 or 2 more I forgot about.

At Google we've been facing this issue for years actually: We typically late load all parts of the apps, and that includes implementations for click handlers: So we might not be able to synchronously handle a click all the time – which brings us to exactly the same problem as having the app running in a different thread.

There are various solution flavors, but they all are derived from the same idea:
- window.open is rare, just do something hacky special thing for it
- preventDefault is the more important use case:

The base strategy is to install global event handlers on the UI thread that either always call preventDefault on all events they see or do so based on a DOM annotation. If you always call preventDefault, you need to have user land implementations of all default actions (like window navigation). We typically use a DOM annotation instead:

E.g. if you have an
tag, add and then the global UI thread click handler (which might need to look at ancestors of the target), calls preventDefault on events when it sees this.

One important considerations is that while window.open is rare, you need to use it to "implement" target=_blank for clicks on a tags that might have had preventDefault called on them. We typically handle this by putting a limited version of the app's router into the synchronous call path. That typically allows handling almost all cases of advanced preventDefault magic on the UI thread while keeping the rest of the app away from it.


https://twitter.com/nolanlawson/status/690173930594766848

Tuesday, January 5, 2016

What is the best way in 2016 to file a web platform feature request?

What is the best way in 2016 to file a web platform feature request? I'll just go ahead and write it down here and then can paste it elsewhere.

Visual completeness event

An event emitted on a browser some time after the browser determined using some heuristic that the page was visually complete. In practice this should expose https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index to the web platform.

It is important that visual completeness counts all cross origins resources in including iframes. There should also be visual completeness events per iframe and available to the parent frame.

It is not important the event arrives timely. E.g. a browser could delay processing until a good time if it retains necessary data and it would even be OK if the event was only produced at a certain sample rate.

Problem this is solving
There is currently not a single mechanism on the web platform for measuring how fast something loads that could be used as a trustworthy metric to assess how slow or fast something is. One can use the load event, but it is not a proxy for user perception and it is very easy to cheat (let it fire early and do all the work after).
To my knowledge the only thing one can do right now to measure the impact of an iframe is to measure time between animation frames while a resource is loading, which is a super rough proxy for the amount of CPU it is using.

I'm sure there are many problems with this, including timing attacks, information leaks and lack of a robust heuristic, but I think it is time anyway to get our act together and create a web exposed metric for website load time.

Patrick Meenan
https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

Sunday, January 3, 2016

The Most Mysterious Star in Our Galaxy - The Atlantic


http://www.theatlantic.com/science/archive/2015/10/the-most-interesting-star-in-our-galaxy/410023/?dom=pscau&src=syn

Lossless image compression: 43% smaller than average PNG.

Lossless image compression: 43% smaller than average PNG. 14% smaller than WebP. Any number of read bytes can be used to render a lower resolution version. Very interesting.
http://flif.info/

Friday, January 1, 2016

My projection for 2016: exponential growth continues: will have doubled number of kids in less than 3 years....

My projection for 2016: exponential growth continues: will have doubled number of kids in less than 3 years. #GrowthHacking