W3C

- DRAFT -

Web Performance Working Group Teleconference

20 Mar 2013

See also: IRC log

Attendees

Present
+1.626.379.aaaa, [Microsoft], Plh, +1.720.746.aabb, Rob, Daniel, +1.650.701.aacc, +43.732.908.2aadd, Arvind, +1.408.203.aaee, [GVoice], +1.503.264.aaff, ganesh, +1.408.203.aagg, JatinderMann, plh, simonjam, RobDickenson, DanielAustin, Alois, Ganesh, Ritika
Regrets
Chair
SV_MEETING_CHAIR
Scribe
JatinderMann

Contents


<trackbot> Date: 20 March 2013

<simonjam_> i keep getting "this passcode is not valid"

<simonjam_> did it change?

<simonjam_> that's what i'm trying :(

<plh> type 0 and one of our folks should be able to help

Prerender

Jatinder: Things that I believe we should standardize in the Prerender spec are the tag definitions (e.g., Link rel="prerender" and Link rel="prefetch"), Page Visibility impact (e.g., document.visibilitystate must equal "prerender" at the time the page prerenders), and also consider adding a HTTP request header to identify prerender requests.

Arvind: About the HTTP header, we came up with page visibility as the primary means for the page owner to understand how to behave when the page is prerendered.

Jatinder: I agree on the concept of page owners using Page Visibility as the script means. What about the page load impact on servers? With a http header, the server could decide to throw away the request.

Arvind: We saw with prefetch that some sites didn't like the prefetch. For examples, some sites were sending 200 response code but were sending a broken page.

Ritika: We can always send a 404 response code to indicate that the site is broken to indicate to the man in the middle that the prerender isn't happening.

Arvind: Yes, we considered that, but 404 is still a valid code for page not existing. We thought of instead of creating a new prerender http response code, but at the end of the day we thought Page Visibility is the best way to solve this problem. We can talk about it some more.
... On the topic of discarding the page, there is value in discarding the page after some time as the page may be out of date. For example, the browser prerenders but the user doesn't click on the link for two hours.

Jatinder: Navigation Timing should have information on when the user switched to the prerendered page. Getting the delta of loadEventEnd and prerenderSwitch will give the perceived page load time (delta == loadEventEnd is normal page load, delta < loadEventEnd is perceived faster page load, delta >= loadEventEnd is instant page load).
... We may also want to include information in Resource Timing for the page that initiated the prerender or prefetch. For example, any resource that was prefetch should be included in the Resource Timing with an initiator of "link:prefetch". Any page that was prerendered could be included as an entry similar to a subdocument with initiator type "link:prerender".

Arvind: I'm not sure we should add this kind of information to the Timing API, because it's somewhat tangantial.

Jatinder: What about the case where the page is adding the link rel="prerender" dynamically after the page itself has loaded, so it doesn't impact the current page's performance. It might be useful for that page to know when the prerender occurs, especially if the browser delays the prerender.

Arvind: If the page is prerendering immediately, then there is no problem. If the prerender is delayed, we can consider adding a handler or a event that calls a callback to notify the page owner when the prerender occurs.

Ganesh: Are there statistics for link taken or not taken once it's prerendered?

Arvind: I know Google tracks some stats but not sure if they are published. For applications like search, people do click on it often. In other applications, it may not be as much. E.g., new stories that spans multiple pages the hit rate would be high.

Ganesh: I wonder if want to include in the spec if the click or not click count was given to the developer.

Jatinder: You can use the onclick event on the link.

Arvind: We can definitely include information on the benefits of prerender.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-03-20 19:48:14 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: JatinderMann
Inferring Scribes: JatinderMann
Default Present: +1.626.379.aaaa, [Microsoft], Plh, +1.720.746.aabb, Rob, Daniel, +1.650.701.aacc, +43.732.908.2aadd, Arvind, +1.408.203.aaee, [GVoice], +1.503.264.aaff, ganesh, +1.408.203.aagg
Present: +1.626.379.aaaa [Microsoft] Plh +1.720.746.aabb Rob Daniel +1.650.701.aacc +43.732.908.2aadd Arvind +1.408.203.aaee [GVoice] +1.503.264.aaff ganesh +1.408.203.aagg JatinderMann plh simonjam RobDickenson DanielAustin Alois Ganesh Ritika

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 20 Mar 2013
Guessing minutes URL: http://www.w3.org/2013/03/20-webperf-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]