3 ms·
The Hidden Dangers of Beautiful Themes
- samarudge 15y agoW3 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.
- dogweather 15y agoThank 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.
- ovi256 15y agoRails 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.
- polyfractal 15y agoThis 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.
- drivebyacct2 15y agoThis 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.
- dogweather 15y agoWell, 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.
- zalew 15y agoI often criticize the wordpress ecosystem and mention the above as one of the reasons. Even recently a buddy of mine whined about the performance of his wp page, I've took a look at it and damn... the firebug network chart was one of the crappiest I've seen in my life. Literally dozens of request for images and css files, huge part of which raised 404, about 3 versions of jquery loaded locally thanks to plugins, and so on. What a mess. 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.
- pwim 15y agoWhy have requests for assets like CSS and images go directly to your blog? Setting up cloudfront only takes about five minutes to do.
- dogweather 15y agoI 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.
- mmccomb 15y agoI 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.
- mrsteveman1 15y agoServe 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.
- rograndom 15y agoThis 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.
- fookyong 15y agoAfter 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.