W3C home > Mailing lists > Public > public-web-perf@w3.org > March 2011

Re: [NavigationTiming] few comments

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 22 Mar 2011 18:35:12 -0700
Message-ID: <AANLkTikw1MFRcEERCGzNkf3R5+MP_U=-UsSEMvKddLco@mail.gmail.com>
To: Olli@pettay.fi
Cc: Olli Pettay <Olli.Pettay@helsinki.fi>, Tony Gentilcore <tonyg@google.com>, public-web-perf@w3.org, jmann@microsoft.com, Nic Jansma <njansma@microsoft.com>, Zhiheng Wang <zhihengw@google.com>
On Tue, Mar 22, 2011 at 3:47 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 03/23/2011 12:32 AM, Jonas Sicking wrote:
>> On Tue, Mar 22, 2011 at 3:05 PM, Tony Gentilcore<tonyg@google.com>  wrote:
>>>> How do current implementations handle cached DOM + back-forward?
>>> WebKit has a bfcache called PageCache, but it is disabled in Chrome.
>>> Since it is moot there, I haven't payed attention to the details here.
>>> Nic or Jatinder can probably comment on what IE does here. If they
>>> don't use it either, mozilla is probably the first implementation with
>>> a bfcache and you might suggest reasonable behavior to Zhiheng.
>> We should definitely simply leave the values untouched when going
>> back/forward to a DOM-cached page.
> Why? Then .navigation.type may actually lie what was the previous
> navigation.

It's not a lie. It's just contains the values that were relevant when
the page was loaded.

Put it this way instead. What is the value of getting some new set of
performance values for the "navigation" to the bfcached page.
Absolutely no network activity takes place when navigating to the
bfcached page and so it seems to me that there is no interesting data
to expose.

The only result that I can see is that pages will now have to be aware
that at any point the values in .navigation can suddenly be cleared if
the user navigates away from the page and then back. So pages will
*have to* register for pagehide/pageview events if they want to be
sure of consistency in the data. This is different from how things
work now when pagehide/pageview are there solely for optimizations.

> And writing tests for BACK_FORWARD becomes really hard,
> since you don't know what value browser returns in .navigation.type.
> Some browsers may return NAVIGATION (because they have bfcache), some
> may return BACK_FORWARD.

The fact that the test has to be a bit more intelligent does not seem
like a reason to complicate the feature exposed to web developers.

> Also, that kind of behavior would actually prevent one
> kind of performance timing - BACK_FORWARD + cached DOM.

What timing is there to do?

/ Jonas
Received on Wednesday, 23 March 2011 01:36:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC