Prerendering Breaks Website

[James Frank]

Is there a way to disable prerendering on a per-site basis (by the
webmaster, not by the user)?

Prerendering is breaking our website in Google Chrome. Let me explain.
We identify themes by URL. If you go to example.com/A you get theme A
and if you go to example.com/B you get theme B.

Despite what I see on the forums, Google is prerendering pages even
when we don't have a <link rel=prerender> specified. It seems to be
guessing at the best chance for prerendering and doing that. In this
case if you're on example.com/A it's guessing that example.com/B is
the next page, and prerendering that.

Somehow this is confusing our server. It seems that the request for B
is happening at just the right time so that example.com/A is getting
served with theme B.

How do I know this is because of prerendering?

1. It only happens in Chrome.
2. If I disable prerendering the problem goes away.
3. I can see the extraneous prerender requests go through when I run
my browser session through a proxy.

My only solution for this at the moment is to do a <link rel=prerender
href=prerender-fix.xhtml> where prerender-fix.xhtml always renders
with the last theme that was used for that session. This way, any
prerendering requests don't mess up the theme.

This is rather unfortunate because now the site is prerendering a page
that does the user no good at all. But I can't find any way to turn
off prerending entirely via a header, etc.

Any ideas?

[Alex Komoroske]

Hi James,

Thanks for reaching out!  I'm responded to your questions inline.

On Tue, Nov 22, 2011 at 2:57 PM, James Frank <james....@gmail.com> wrote:

Is there a way to disable prerendering on a per-site basis (by the
webmaster, not by the user)?

There isn't at this time. As your response anticipates, users can turn off prerendering in Chrome by unchecking "Predict network actions to improve page load performance"

 

Prerendering is breaking our website in Google Chrome. Let me explain.
We identify themes by URL. If you go to example.com/A you get theme A
and if you go to example.com/B you get theme B.

Despite what I see on the forums, Google is prerendering pages even
when we don't have a <link rel=prerender> specified.

Note that a third party site (or, in some cases, Chrome itself) can request that your site be prerendered, even if your own site doesn't include a <link rel='prerender'> tag itself.  For example, Google.com makes use of the prerender tag to power the Instant Pages feature.

 

It seems to be
guessing at the best chance for prerendering and doing that. In this
case if you're on example.com/A it's guessing that example.com/B is
the next page, and prerendering that.

Somehow this is confusing our server. It seems that the request for B
is happening at just the right time so that example.com/A is getting
served with theme B.

If a third party requests that page example.com/A be prerendered but then the user actually visits example.com/B, then the prerendered page would be discarded by Chrome and example.com/B would be used.

Based on your description of the problem, our best guess is that you have a subtle race condition in the logic on your server (perhaps involving caching) that's only obvious when prerendering is happening.  Can you explain more about your setup?  Does the same thing happen if you navigate to A and B in two tabs in the same browser at roughly the same time?

[James Frank]

A few more details, and a few odd things going on:

1. Even if I disable prerendering in Chrome (uncheck "Predict network
actions to improve page load performance" in settings), it still seems
to be prerendering. I uncheck the box, restart the browser, check
chrome://net-internals/#prerender and see that prerendering is false.
But when I run my browser through a proxy, I still see it sending
prerendering requests for other pages. This is rather weird and fairly
annoying, especially since the browser is telling me that prerendering
is off. Is there anything else that could be creating these requests?

2. I'm not sure it's a race condition issue, as I seem to be able to
trigger it even in delayed circumstances. For more info, this only
seems to happen with postback requests. I think my theme may only set
itself on GET requests, not on POST requests, resulting in what I'm
seeing.

Page A has a button which just executes a postback to page A itself.
With my proxy intercepting all HTTP/S requests, I can:

- initiate a GET request for page /A (with theme A) and forward it
through the proxy (page loads)
- see a prerendering request for /B
- wait 5 seconds
- forward the prerendering request through the proxy
- wait 5 seconds
- submit the POST request for page /A and forward it through the proxy

Result: /A loads after the postback, but with theme B. Presumably
because the prerendering request triggers the server to set the
current session to theme B (by matching on url /B)

Alternatively I can:

- initiate a GET request for page /A (with theme A) and forward it
through the proxy (page loads)
- see a prerendering request for /B
- wait 5 seconds
- drop the prerendering request
- wait 5 seconds
- submit the POST request for page /A and forward it through the proxy

Result: /A loads after the postback, with theme A. Presumably because
the prerendering request never hits the server to trigger a switch to
theme B.

So, I don' think this is caused by a race condition, at least not in
the typical definition. It's simply caused by how the software is
built and the browser is interacting with it. Because the theme is
stored in the session and the prerendering requests trigger the theme
to change (by hitting a different URL), it unexpectedly changes the
user experience.

3. I don't know where Chrome is getting the link to /B from. That link
doesn't exist anywhere on /A. To be a little more correct with my
URLs, /A is /extranet/landing.seam and /B is /extranet/application/
name/create.seam. The latter never links to the former, but the former
is the default/home page for our website. I really don't know how
Chrome is ending up with the former as the link to prerender. Again,
there is no <link rel=prerender> specified

4. This is Chrome 15.0.874.121 on Mac OS X 10.6.8

It would be really nice to have some way to specify for a website that
the browser should not be prerendering anything on that site.

James

On Nov 22, 3:47 pm, Alex Komoroske <komoro...@chromium.org> wrote:
> Hi James,
>
> Thanks for reaching out!  I'm responded to your questions inline.
>

[Alex Komoroske]

Hi James,

Thanks again for reaching out.

The fact that you're still seeing "prerendering" requests even when you uncheck the applicable setting is extremely odd.  Do you see similar traffic happen if you disable all extensions?

To help diagnose what's going on we'll need some more information about how your site works. Could you give a high-level overview of how the logic to set themes works on your site (ignoring prerender for a moment)?  How does a user interact with it under normal conditions?  What types of values are you storing in cookies?  What is the purpose of the postback?  Even better is if you're able to share a URL to the site (although of course I understand that might not be possible).

--Alex

[Sreeram Ramachandran]

On Tue, Nov 22, 2011 at 14:13, James Frank <james....@gmail.com> wrote:
> 2. I'm not sure it's a race condition issue, as I seem to be able to
> trigger it even in delayed circumstances. For more info, this only
> seems to happen with postback requests. I think my theme may only set
> itself on GET requests, not on POST requests, resulting in what I'm
> seeing.

Based on what you described, it seems to me that you should be able to
reproduce the scenario without prerendering, and even in a different
browser:
1. Load /A in tab 1.
2. In tab 2, load /B. Presumably, this sets the theme to B, in some
cookie or server session state.
3. In tab 1, click on the button to POST to /A.
I'd expect to see theme B show up. If it doesn't, could you explain
why this is different from the prerendering scenario?

[James Frank]

That's absolutely correct. If I do those steps, it will switch the theme. Now the question is why Chrome is executing a request for /B.

I have tried this in Chrome on both Mac and Windows. I have disabled all extensions and even turned off JavaScript to rule out AJAX requests. When I load /A, soon thereafter there is a GET request for /B. Why would this be happening? Is there something other than prerendering that could cause that to happen? Is there a way I can make Chrome not execute that request?

[Sreeram Ramachandran]

On Tue, Nov 22, 2011 at 19:53, James Frank <james....@gmail.com> wrote:
> That's absolutely correct. If I do those steps, it will switch the theme.
> Now the question is why Chrome is executing a request for /B.
> I have tried this in Chrome on both Mac and Windows. I have disabled all
> extensions and even turned off JavaScript to rule out AJAX requests. When I
> load /A, soon thereafter there is a GET request for /B. Why would this be
> happening? Is there something other than prerendering that could cause that
> to happen? Is there a way I can make Chrome not execute that request?

At this point, I'll need to access the actual /A and /B on your site
in order to see what's going on. My suspicion is that, despite your
belief, there indeed is a reference to /B from /A. If you are
uncomfortable sharing the URLs publicly, feel free to reply to me
privately.

[James Frank]

For the purposes of this list, Sreeram helped me discover that Chrome
was auto-requesting /favicon.ico which didn't exist and the server was
redirecting the request to /B, thus triggering the theme switch. Thank
you!

So, a few things to note:

A) Prerendering was not breaking the website
B) Prerendering wasn't actually doing anything (especially after
turning it off)
C) There is no way to disable prerendering from the site side (to
answer the original question), only from the client side on a per-
browser basis

James Frank

On Nov 22, 11:00 pm, Sreeram Ramachandran <sree...@chromium.org>
wrote:

[Dominic Hamon]

Great to hear everything worked out!