The Hidden Dangers of Beautiful Themes(g33klaw.com)
g33klaw.com
The Hidden Dangers of Beautiful Themes
http://www.g33klaw.com/2012/04/the-hidden-dangers-of-beautiful-themes/
8 comments
W3 Total Cache plugin for Wordpress will combine all CSS and Javascript files into two requests, you can also use something like NGINX, or even better a proper CDN, for serving static resources.
Thank you - that was an excellent suggestion. I didn't know about this plugin. For sure, one needs to make sure the theme / site is efficiently designed, but this plugin is exceptional. It pretty much does everything I've done by hand on Rails projects.
Rails 3 has an asset pipeline that does the same thing as that W3 plugin: gathers js/css assets in one file each by default. I can't emphasize enough the "by default" part. It's a very nice default.
This is a great plugin and pretty easy to use - but be warned: many plugins will not work when W3T's minifying is turned on. W3T does what it can to minimize the conflicts and a few plugins are built with a W3T "compatibility" mode...but many just simply break.
That said, W3T is really great for caching and CDN setup...takes like ten minutes to get going.
That said, W3T is really great for caching and CDN setup...takes like ten minutes to get going.
This sounds more like "The Hidden Dangers of Having Apache Configured to Use More Memory Than I Have Installed".
It looks like the new theme caused each mod_php process to increase some amount, and that wasn't taken into consideration. Once the requests started piling up Apache started swapping, killing the server.
W3 Total Cache could've been installed to serve up cached static files direct from Apache, without spinning up PHP. All of the images could've been off loaded to cloud front or S3 or any other supported CDN to relieve that stress and W3 Total Cache also has a feature to combine all of your CSS and JS files into 1 to cut down on those requests as well.
You're running on a VPS, you should have some idea of how the system is setup and how memory is used. You've taken the time to setup the VPS and your rails apps, take 5 minutes to properly setup Apache and WordPress caching.
It looks like the new theme caused each mod_php process to increase some amount, and that wasn't taken into consideration. Once the requests started piling up Apache started swapping, killing the server.
W3 Total Cache could've been installed to serve up cached static files direct from Apache, without spinning up PHP. All of the images could've been off loaded to cloud front or S3 or any other supported CDN to relieve that stress and W3 Total Cache also has a feature to combine all of your CSS and JS files into 1 to cut down on those requests as well.
You're running on a VPS, you should have some idea of how the system is setup and how memory is used. You've taken the time to setup the VPS and your rails apps, take 5 minutes to properly setup Apache and WordPress caching.
After switching to Rails it's things like this I find quite amazing that people still have issues with.
Rails does so much good stuff "for free", such as when deploying to production it combines all static files (css/js) into one file automatically and also minifies it. That means your 15 external http requests get reduced down to 1 or 2 tiny ones.
I'm not saying Rails and Wordpress perform the same job - they don't, but I do find it amazing that other frameworks / engines don't adopt such obvious best practices like the one example I've given.
Rails does so much good stuff "for free", such as when deploying to production it combines all static files (css/js) into one file automatically and also minifies it. That means your 15 external http requests get reduced down to 1 or 2 tiny ones.
I'm not saying Rails and Wordpress perform the same job - they don't, but I do find it amazing that other frameworks / engines don't adopt such obvious best practices like the one example I've given.
Serve the static files from something that can handle it, sticking nginx in front of apache as a reverse proxy works well here and will both catch whole pages (once configured for it) and serve all those pesky CSS, js and image files directly so apache doesn't have to.
Letting the php app server (apache in most wordpress cases) handle things it shouldnt is the real issue here, everytime apache has to serve a static file, that worker process can't render or even serve cached pages.
Letting the php app server (apache in most wordpress cases) handle things it shouldnt is the real issue here, everytime apache has to serve a static file, that worker process can't render or even serve cached pages.
Why have requests for assets like CSS and images go directly to your blog? Setting up cloudfront only takes about five minutes to do.
I think that when the software itself is creating 47 http requests per visit, that's the thing that needs to be fixed. 36 of the requests are for images; an automatic optimizer can't help that.
I spent the passed weekend moving my blog off Wordpress to Octopress mostly for performance reasons. Wordpress has become a fantastic feature-loaded CMS. But a blog really doesn't need much of the functionality nor complexity that comes along with it. There's something beautiful and simple about blogging in static HTML.
This has less to do with "hidden dangers of beautiful themes" as much as it has to do with understanding basics of page loading. HTTP request overhead is well known as a major cause of strain. Most blogs, frameworks, CMSes, etc have decent modules for compressing and caching these resources. It's more friendly for your users, your server. Best of all, they're super easy to use, like, for this sort of thing, incredibly, incredibly easy to use.
Well, the thing I see is that even a person who's only reasonably technically savvy cannot just install Wordpress with an officially featured theme and have it work. In fact, doing so may kill your server.
Always some enthusiasts argue me, while some others say the mentioned 'oh, just cache it'. Some time ago there was also the post about the first page of google results on 'wordpress free themes' proving that most of it had malware. People (mainly amateurs) should understand that while wordpress (love it or hate it, there are lots of reasons) is legit, the whole ecosystem of themes and plugins is by many means occupied by amateurs who can set up a php website and some html but don't know crap about performance and/or security, and also spammers and other devs with malicious intentions. Use wp, but be aware of that and be careful what you're doing when installing third-party extensions.