Reduce server hits with JS history API

[peterwilsoncc]

This patch aims to speed up page loads by removing the extra hit required by a 301 redirect.

The patch loads the requested page/post on the shortlink, the JavaScript history.replaceState function is used to display the canonical URL to the visitor.

Individual results may vary but on my server it looks like it will save around 500ms.

[willnorris]

I'm all for making this kind of thing possible, but am hesitant to make it the default behavior. While it should work fine for browsers, I'm not sure what the implications would be for search engines, since you now have two URLs serving identical content with 200 OK responses. There are also URL pre-processors that follow redirects to get to the canonical URL for a post which this would break (I have an android app that does that, and I think brid.gy does that as well).

So if we need to add the hum_process_redirect filter to make it possible for a separate plugin to do this, that's fine. But I wouldn't want to change the default behavior.

[peterwilsoncc]

Makes sense, I'll update the patch & add a comment when I've done so.

WP adds canonical meta tags for big search, but I didn't think about the other use cases.

Sent from my mobile phone

On 29 Nov 2014, at 6:17 am, Will Norris notifications@github.com wrote:

I'm all for making this kind of thing possible, but am hesitant to make it the default behavior. While it should work fine for browsers, I'm not sure what the implications would be for search engines, since you now have two URLs serving identical content with 200 OK responses. There are also URL pre-processors that follow redirects to get to the canonical URL for a post which this would break (I have an android app that does that, and I think brid.gy does that as well).

So if we need to add the hum_process_redirect filter to make it possible for a separate plugin to do this, that's fine. But I wouldn't want to change the default behavior.

—
Reply to this email directly or view it on GitHub.

[pfefferle]

I think an action to replace the default redirect still makes sense. There are two options:

1. add a hum_pre_redirect action before the wp_redirect
2. replace the wp_redirect with a hum_process_redirect action and move the wp_redirect to a default handler

What do you think?

[peterwilsoncc]

Yeah. I haven't had a chance to work on this but coincidently going on a WP dev weekend this weekend so will add it to the list :)

[willnorris]

I'm fine with either of @pfefferle's options (you guys pick). I would also note however that the overhead of returning a 301 redirect and making a second HTTP request should be completely negligible with HTTP/2.