Would you create a 301 redirect if it improved page load times?

[Sgt_Kickaxe]

If you had the choice between leaving your urls and page speed as is or redirecting them via 301 to a new set of urls that would improve page load times by a full second (say from 3 seconds to 2 seconds) would you make the 301 redirect or leave the current urls as is?

Pro = a significant page speed improvement
Con = a 301 redirect is required which *may* impact rankings

Where this is coming from: In another thread [webmasterworld.com] I mentioned creating a static version of a wordpress page and plunking it down in the root directory so that wordpress, and the database, are bypassed completely. The requirement for it to work is that current urls need to have the .html appended thus creating new urls to which the old must 301 redirect.

New urls with old content redirected vs page speed, which would you rather?

[lucy24]

I read the other thread but never got the underlying question sorted out: Why is it necessary to physically redirect, instead of simply rewriting to (serving content from) the static page?

[Sgt_Kickaxe]

The problem is the extensionless urls. If I have a static file @ example.com/somefile.html and a matching url with wordpress(without extensions) and I direct a browser to example.com/somefile wordpress is activated. If on the other hand I navigate to example.com/somefile.html wordpress is never activated and my static file is served.

I want all visitors to see the .html version and, unfortunately, wordpress doesn't redirect extensionless to .html version automatically unless other url changes are also made.

[g1smd]

I want all visitors to see the .html version

No. Forget URLs for a moment. You want all visitors to be served content from the static files (and that's not quite the same thing). This is very easy to set up.

Wordpress will not be activated if you install a new rewrite before the wordpress rewrite and divert (internally rewrite) the extensionless request to a different place in the internal server filesystem - the place where the static HTML files are.

URLs and files are not at all the same thing. URLs are used "out there" on the web. Files are used "here" inside the server. The server configuration determines for a given URL request where inside the server the content is served from.

So, why not
- leave the on-page links pointing to extensionless URLs,
- save all the pages as static .html files and place them in a separate folder,
- set up a rewrite so that extensionless URL requests are rewritten to fetch content from the static files instead of from Wordpress?

This system has no redirects and no change of URL.

Since you'll still need to access the Wordpress system from time to time, build in a exception that allows you to do so. The simplest way is to detect the browser user agent and change the UA of your browser when you need access (use some random string that will never occur in a real user agent). The rewrite to the static files occurs only when the UA is not quuxfoowibble.

There's a market here for an extension to cache wordpress pages as static files and to manage their update when the core page content or any navigation is changed on a page.

[Sgt_Kickaxe]

You know, I've never even considered setting up a rewrite to fetch content from the static files. That's in part because I really dislike setting up htaccess when I can simply just add the static file to the root folder(or not, it's not mandatory for all pages to be static this way).

If my site has two dozen or so pages I'd like served in this way, not the entire site, is it still efficient?

[g1smd]

Yes, as long as it is simple to identify which requests will be served by static files and which by wordpress.

Hopefully all the URLs to be served by static files have some common element/pattern within them.

I've used a similar rewrite to temporarily replace a CMS generated page with a static file for a short time. The last time was when a new product was added to the CMS pages, but not yet available. The rewrite was installed serving the content from a static page with much more basic "coming soon" information. On launch day the rewrite was removed revealing the CMS generated pages.

[Sgt_Kickaxe]

Hopefully all the URLs to be served by static files have some common element/pattern within them.

unfortunately no. example.com/some-page-name

Since this is wordpress adding something like the following to the index.php file might be the easiest route:

$getPageName=$_SERVER['REQUEST_URI'];
if ($getPageName='some-page-name') { 
echo file_get_contents('cache/some-page-name.html');

That's basic, there is no fallback if the page isn't in the cache folder and it's not as secure as it could be but just for this example... a question: What htaccess would display the cache contents of that page WITHOUT changing the url to /some-page-name.html and WITHOUT causing a browser redirect ?

[lucy24]

WITHOUT changing the url to /some-page-name.html and WITHOUT causing a browser redirect

Your two WITHOUTs are the same thing. A name change is a redirect. A redirect is a name change.

Rewrite (aka "internal redirect")
RewriteRule visible-url /real-source.html [L]

= user sees "visible-url" in address bar while page displays content from "real-source.html".

Redirect
RewriteRule original-url http://www.example.com/new-url [R=301,L]

= user requests "original-url" but is sent over to "new-url". This is independent of where the final page content will come from.

If you're dealing with a modest number of specific pages, you can list them by name in the RewriteRule:

RewriteRule (oneurl|otherurl|thirdurl|morestuff) /cache/$1.html [L]

= address bar says "oneurl" while content comes from "/cache/oneurl.html"

[g1smd]

A rewrite from extensionless URL to .html file in the cache folder would serve the contents of that file.

A rewrite connects a URL request (URLs are used "out there" on the web) to a folder and file (files are used "here" inside the server) to serve the content.

[Sgt_Kickaxe]

redirect vs rewrite... oi

example.com/this-example-page needs to serve the contents of example.com/this-example-page.html but cannot have the browser url change to example.com/this-example-page.html, it must remain extensionless (and this is whithin wordpress)... i'm missing something obvious no doubt.

[g1smd]

Use a RewriteRule configured as a rewrite.

(A RewriteRule that delivered a redirect would tell the user to make a new request for a different URL.)

[Sgt_Kickaxe]

RewriteRule configured as a rewrite ?

RewriteRule ^/this-example-page$ this-example-page.html

Wordpress returns a 404 unless I change permalinks to include .html and if I do that all of the extensionless urls not affected by this rule go 404. It's a lot of trouble to change just a few pages. I'm searching for quality pages about what you suggest but am finding a lot of crap. Most is also for sitewide changes despite my specifying a single page.

[manny123]

Maybe this was covered already, but how about just caching the page using a WP cache plugin? This will avoid the database calls and should be as fast as writing the file to disk. No need to change URLs this way which is the best possible solution, imo.

[Sgt_Kickaxe]

Plugins require wordpress. Id like just some pages to load a static file and bypass wordpress altogether. I can't figure out what g1smd is talking about, or rather I can't make it work with just some pages on wordpress without causing url changes or 404 errors. The extensionless urls vs .html static file is stumping me at the moment.

I'll figure it out.

Rewrite (aka "internal redirect")
RewriteRule visible-url /real-source.html [L]

For whatever reason this doesn't load the real-source.html content on a wordpress site.

Solved

RewriteRule ^visible-url$ real-source.html [L]

[manny123]

WP Super Cache can be configured to use mod_rewrite which will bypass WP and PHP for serving pages. Super Cache should also be able to handle the generation of the static files so that you don't have to manually update them.

Another option is to use AWS CloudFront [aws.amazon.com...] Point your domain at CloudFront and AWS will serve them cached files from Amazon's network. If the file is not cached or the cached file has expired, a fresh file will be pulled from your origin server (this is the server you currently run on)

There are lots of ways to speed up your site using a variety of caching services. Hope this helps.

[g1smd]

RewriteRule ^/this-example-page$ this-example-page.html

Not quite! In htaccess the leading slash of the requested path is stripped. You also need the

[L]

flag...

RewriteRule ^this-example-page$ /this-example-page.html [L]

This code must be placed after your non-www/www redirect and before the wordpress internal rewrite(s).

On the left, what the user requested in the URL.
On the right, where inside the server the content really resides.

URLs are used "out there" on the web. Files are used "here" inside the server.
A rewrite is a URL to filepath translation.
A redirect is a URL to URL translation.

[Sgt_Kickaxe]

Thanks g1smd, I added the [L] (see above) and knew enough to place it in the right spot.

re: cache plugins - 98% of the site can't be fully cached(at least not by standard plugins - geo targeting on top of dynamic content on top of...), this was a solution I can live with for a few individual heavily trafficked pages.

[netmeg]

My top WP site serves over a million p/v a day with no problem. We did some tweaking and put in fastcgi, but it runs like lightning with a couple thousand people pounding on it. It *can* be done.