Way of allowing simple form-based navigations for Search

[tunetheweb]

Currently speculative navigation only works for links. This seems sensible as we only want to speculate safe, idempotent results.

However Search forms on sites are incredibly common and is usually a safe GET request too. They are also often slower pages (especially for client-rendered search results) that would benefit from speculating in advance. However at present Chrome does not see these as navigations that can reuse prefetch nor prerendered speculations.

Some have had success with prerendering search results, even though the prerendering search results page will not be used, due to the fact that the page (and it's assets like thumbnails) are then available in the HTTP cache for the subsequent form-based navigation.

While this pre-warming the cache does create performance benefits, it is not as good as allowing the the navigation to use the speculation directly. One reason for that is this benefit depends on the page being cacheable and sadly many are not. One of the benefits of the Speculation Rules API over <link rel=prefetch> is it does work for non-cacheable documents providing the speculation is activated (which, as I say, it is not with a form-based GET navigation).

Others are suggesting other ways of hacking around this by intercepting the form-based navigation and instead using JavaScript to speculate and then navigate, which does allow the speculation to be used, but at the cost of complexity and it feels a bit icky to have to do this.

Should we support this navigately? Maybe with a <form> attribute that can be added to the markup? For example:

<form allow-speculation="true" method="get" action="/search">
  ...
</form>

This should be restricted to get methods IMHO.

[jeremyroman]

re. intercepting the form navigation itself, I don't see why that shouldn't work already -- we should still be able to serve a prefetched/prerendered response to a GET form submission. If we can't, that's probably straightforward to address. (Document rules won't pick it up, which I suppose we could if this were common, but that aspect doesn't seem high priority.)

Experimentally this seems to work fine in Chrome for prefetch, so maybe this is just a prerendering bug? The given failure reason is "The prerender was not used because during activation time, different navigation parameters (e.g., HTTP headers) were calculated than during the original prerendering navigation request."

If you agree, maybe that can just turn into a Chromium bug against Internals>Preload>Prerender?

[jeremyroman]

For clarity, I'm still happy to keep the idea of document rules handling this in the future around somewhere, of course!

[tunetheweb]

Oh interesting. I didn't think to try prefetch. I did look at all the HTTP Headers, but couldn't see a difference. Bug raised: https://issues.chromium.org/issues/346555939. And thanks for the glitch to easily show this!

@tvereecke was asking about a non-JS way of this working. Currently he uses tabbing out of the search field, or hovering over the search button to kick off prerender which isn't the most complex JS, but maybe having this built into the browser would allow greater adoption for this common use case?

[westonruter]

Experimentally this seems to work fine in Chrome for prefetch, so maybe this is just a prerendering bug? The given failure reason is "The prerender was not used because during activation time, different navigation parameters (e.g., HTTP headers) were calculated than during the original prerendering navigation request."

See also a fork of the Glitch for which prerendering of the search form does work, enabled by the following workaround in a submit event handler:

  event.preventDefault();
  const formData = new FormData(event.target);
  const url = new URL(event.target.action);
  url.search = new URLSearchParams(formData).toString();
  location.href = url.href;