I am seeing repeat view on chrome, giving multiple 304 responses.
However, when done locally on chrome browser, i see content coming from cache and no 304 validation.
Here is link: http://www.webpagetest.org/results.php?test=140617_NN_44032b60ce466dd61a51f18991ab7c46
Is WPT doing page refresh on repeat view, instead of opening a new browser window and loading page?
When you do it locally are you exiting the browser and re-launching it? Otherwise you’re hitting the in-memory cache which has different behavior.
My guess is you are tripping over this Chrome bug: 294030 - chromium - An open-source project to help move the web forward. - Monorail where Chrome always does an if-modified-since check for all resources when doing a form POST
So, I was doing repeat view using WPT (Chrome), and there I was finding 304 responses.
While locally, either exiting browser or doing on the same browser and opening a different window, I was not getting 304 responses. So I was wondering, if WPT was not opening new browser window for repeat view, and just doing refresh?
Nope, WPT closes the browser before the repeat view test and does a basic navigation. The 304’s on a POST is a known issue with Chrome which is why I’m surprised you’re not seeing it locally.
I see… btw, i saw this: Agent does not close browser between first view and repeat view tests · Issue #234 · catchpoint/WebPageTest · GitHub
guessing that this is recent fix releated to repeat view… i have not updated my WPT for some time, so may be because of that…
[hr]
oh actually, you are right. my bad – i wasn’t clearing cookies before opening a new browser window locally. so that was the issue… thanks for your help.
That was just for the mobile agents. The desktop agents have been closing the browser since like forever.
I see… so two questions:
a) on repeat view, you actually delete cookie, and open browser window, and then submit form with warm cache
and
b) Agent does not close browser between first view and repeat view tests · Issue #234 · catchpoint/WebPageTest · GitHub talks about using
in-memory blink cache vs on-disk/in-memory browser cache.
You mentioned that it is specific to mobile issue, – so for desktop, it was always the case for on-disk/in-memory browser cache in case for repeat view…
a - We don’t delete anything on repeat view. Just close the browser and open it again. If the cookies are session coolies then they will go away because the browser gets closed.
b - Yes, repeat view for desktop has always closed the browser causing the in-memory cache to go with it and causing the browser to use the disk cache in the next session. It was a bug that the mobile agents were not closing the browser.
I see… Yeah these are session cookies, but apparently on local desktop, these session cookies don’t seem to be deleted even after closing browser!
I have another request - I was wondering if we can also get response times for each of the resources, even if they are coming from browser cache in waterfall.
Nope, not with WebPagetest. Since the tests are done back-to-back, even though we close the browser to clear the cache the resources are usually in the OS-level disk cache and get served from RAM anyway.
In the wild it will be significantly more variable because it can be slow to get things off of mechanical drives.
You CAN however measure it in the wild using Resource Timing from modern browsers if it is something you are interested in knowing.