Nginx vs. Apache, All Things Considered

[danny.wood]

Hey Peeps,

I've been struggling lately with a new static site, and I'm looking for anyone's opinion who's had to optimize a site using Nginx. I understand that Nginx is recommended for static sites, however I want to avoid being in a situation where I can't do things like write redirect rules the way I want to.

Considering that it will be hosting a Static site, are there any features or functions that Nginx lacks when compared to Apache, such as ability to write rewrite rules, etc.?

[caseyhen]

Great to hear. Let me know if you have any question when you start that project.

Casey

[danny.wood]

Yup, I'm in the same boat as you, I'd much rather do server-side redirects..

As an update on this "project", we used the pageless redirects in our staging environment on S3 just now, but were unsuccessful. Certain redirects that we set up in pageless redirects, (such as adding a trailing slash to URLs without,) got clobbered by S3's default setting of 302ing to adding a trailing slash. Weak sauce, Amazon!

At this point, we're going with Apache, since it's the App that our developers know best and we've had too many problems to experiment with our live environment. This being said, our next project after we relaunch with proper redirects will be to begin testing on our stage with Nginx

Thanks for your input!

[caseyhen]

Hey Danny,

I've always done 301 redirects from the server and avoided any other method. This was more for my sanity to make sure that I was getting all the equity I could if there was a difference, not saying there is a difference but if there way, I wanted to be safe. Since it sounds like you may be constrained by your technology, the solution you are going with is fine but if you had both options available, I'd go with the server side redirect always.

[danny.wood]

Thanks Casey!

We've actually found a different work-around that we are looking at right now, using the "pageless redirects" plugin for Jekyll. Basically it uses the meta refresh + rel canon redirection method that Matt Cutts got called out on a while ago. This would allow us to stay on S3 and maintain our blazing fast site speed.

Through my research so far, this seems to pass equity in much the same way as a Server App 301.. Have you had any experiences/heard anything to the contrary?

[caseyhen]

Hi Danny,

The Moz.com website/blog are running on PHP/Nginx. As Matthew said, Nginx is much faster and less intensive on the servers for both CPU and memory. Nginx has some great documentation and is really easy to get things to redirect. It's as easy as adding lines like the following to your configuration and your good to go:

rewrite ^/q$ /community/q permanent;
rewrite ^/q/(.*)$ /community/q/$1 permanent;

Making the switch from Apache to Nginx was one of the best things we ever did and I would highly suggest you do the same thing for both static and any dynamic sites you may have. I'll most likely never use Apache again.

Casey

[MatShepSEO]

From the little I know of Nginx, I know it is meant to be faster, less intensive on server memory and able to handle more concurrent connections, but Apache is more widely supported across different servers and is more flexible out of the box.

The one thing I have had to get my head around in working on clients sites that run on Nginx is the different URL rewrite rules i.e. http://nginx.org/en/docs/http/converting_rewrite_rules.html

[danny.wood]

Thanks Jeff!

I think we're going to go with Apache for now, since it's what all of us are well-versed in. We'll probably be switching to Nginx at some point in the future, and focusing on other aspects that you mentioned, such as caching and compression, in the meantime.

Cheers.

[customerparadigm.com]

Danny - We use Nginx on our WordPress site, and it's pretty quick and easy.  We're able to use the same .htaccess rules to handle rewrites, and for the most part, there's very little downside. You do want to make sure that your site isn't going to break before you launch it on Nginx, so I'd test it with a test URL first before you push it live.

We're also running Varnish as a caching system, and our page load speed takes the page from a slowwww load time to a really fast 1.5 second load time.

Hope this helps...