I’ve been building wordpress sites for a few years now and have noticed a few things that bother me.
1. It’s fairly slow (awful blanket statement, I apologize)
My initial desire to create a custom front-end came from an observation. The WordPress sites I was building weren’t quite as fast as I wanted them to be (3-5 seconds, sometimes longer).
@Kenrik – They certainly were deployed on oversold shared-hosting, but they got good Yslow scores. I tried it out and found the sites to be approximately three times faster when I didn’t load the WP overhead. Same machine, same Yslow score, 3 times faster. I’m no expert on WordPress CPU usage, but I’ve read that it’s pretty intense, so I was not surprised by the speed gains I achieved.
2. It’s often overly complex for the needs of a simple website
Just a note: I’m mostly building sites for fashion lines and portfolio management, complex in front-end interaction, but with relatively little data. These sites are never going to be huge and they require very little code to retrieve the necessary content. My question is therefore largely theoretical.
I think that WordPress is a fantastic platform and that it has few limits for growth, however I think that loading all of its resources is overkill for a lot of smaller projects, destined to be served from shared hosting.
3. It has a lot of security issues (especially when using plugins)
Concerning security, I can see how my question was ambiguous and contradictory. What I meant is that from my understanding, a WordPress site, beyond any actual security holes, is vulnerable because attackers know that it is a WordPress site. This creates a challenge (to breach a popular platform) and an inherent cheat sheet (WordPress vulnerabilities are well documented). So, sure a custom solution might have more actual security holes, but I’m wondering if it this wouldn’t be balanced by the fact that it makes the inner workings anonymous. As @Kenrik said, “they most likely wont even bother because who cares about hacking a single site with iffy custom code?”
4. It’s difficult to optimize page-load times
What I meant by the difficulty of page-load optimization is that if one achieves interactive functionality via lots of plugins, many scripts are loaded and it becomes more tedious to go back and combine, modify, customize or optimize them. I find it easier to include jQuery plugins outside of WordPress and not have to deal with how they hook into wp_head.
So recently I decided to go about my development differently and use WordPress as only a back-end tool. I use the admin space to update content and populate the database but I use a custom data access layer and custom functions on the front-end to retrieve and display the content. For pages where login is needed, I include the blog-header file and use wordpress’ credential management functionalities.
As I see it, the pros of this independent front-end solution are that it makes development easier (you only write what you need, and it’s all your own work), it’s easier to optimize page-loads (you have better control over what scripts are used and how to combine them in optimal ways), you are not alerting the entire hacking world to the existence of a wordpress install (because the files aren’t loaded from a theme anymore) and more.
Potential Cons: Security, lack of scalability, lack of developer support for custom solutions… Anything else ?
I really enjoy creating sites outside of the wordpress constraints, I’m just worried I might be overlooking some major issues with this approach.
Please let me know if this is the case.
Cheers
To retroactively conclude:
I’m 100% sure that my sites are faster in the exact same environment when I don’t use the native WordPress front-end.
I’m doubt that my code is as safe as WordPress, but I think that I can lock it down and the fact that it has an anonymous front-end might make it less of a target.
I’m sure that I can code functionalities a lot faster when I deploy an extremely simple custom front-end solution.
So I’m just wondering, given my environment and my constraints whether doing this is still just a bad idea. And if so, what are the main reasons.
I’m sure there are other curious, ambitious, under-educated coders out there who might be wondering the same thing. They will likely benefit from whatever you have to say about the subject.
Thank you all
You do cite experience with WP going back farther than that of mine… Yet I do not see these issues as that major. What scale of sites are we talking about?
It’s fairly slow
I feel this is bit too much of generalization. Slow can be put in context of specific hardware, tasks and level of traffic. It’s blanket statement otherwise.
It’s often overly complex for the needs of a simple website
Complex for whom? Users? Developer? WP is trivial to install and get running. Create some content and you have that simple site. Where is complexity here?
It has a lot of security issues (especially when using plugins)
Again, bit too much of blanket statement. WP itself is relatively secure and most of security issues that had major impact seems to be from running grossly outdated WP versions.
State of plugins and security is definitely far from perfect, but nothing prevents to be very selective or developing secure and reliable plugins, right?
It’s difficult to optimize page-load times
Again, I am not sure what scale are we talking about. Optimization from low to mid sized sites seems trivial – install good static cache plugin, buff with opcode caching… Throw in alternative web server or reverse proxy if really needed.
I really enjoy creating sites outside of the wordpress constraints, I’m just worried I might be overlooking some major issues with this approach.
I pretty much have only one question for you – are you absolutely sure that you are doing it better, faster and more secure than native WP front-end?
I do not ask this sarcastically, I think it might be plausible that for very narrow task custom-made and locked down front-end might be reasonable. But I also notice that overconfidence about custom solution being “just better” than collective work of many developers/companies is not uncommon in web development.
Update
My initial desire to create a custom front-end came from an observation. The WordPress sites I was building weren’t quite as fast as I wanted them to be (3-5 seconds, sometimes longer). […] They certainly were deployed on oversold shared-hosting, but they got good Yslow scores.
YSlow (and PageSpeed) are excellent tools, but they are inherently limited. They can only analyze and advise on front-end performance and how site is processed by browser. They give no insight in your server performance and blindly chasing high front-end scores can actually be harmful to server load.
You should use such tools, but you should never limit your insight in how site performs to them alone.
On hosting – any dynamic site on shared hosting will choke under high load. Again, while it may seem easy to tweak and get high front-end scores, on the server side shared hosting critically lacks hardware and web stack flexibility, necessary for site with high traffic and/or striving for fast load times.
I think that loading all of its resources is overkill for a lot of smaller projects, destined to be served from shared hosting.
Had you tried static page caching? It effectively removes WP core out of most requests and it’s about as fast as you can get on shared hosting. If you tried and not satisfied with pages, served from static cache, WordPress is not your problem – hosting is.
What I meant is that from my understanding, a WordPress site, beyond any actual security holes, is vulnerable because attackers know that it is a WordPress site. This creates a challenge (to breach a popular platform) and an inherent cheat sheet (WordPress vulnerabilities are well documented).
There are no public and known security vulnerabilities in stable WordPress version. Those that arise are fixed in matter of hours.
Poor server configuration (common occurrence on cheap hosts) or running outdated WP version is what gets you hacked, not the sheer fact of using WP.
What I meant by the difficulty of page-load optimization is that if one achieves interactive functionality via lots of plugins, many scripts are loaded and it becomes more tedious to go back and combine, modify, customize or optimize them. I find it easier to include jQuery plugins outside of WordPress and not have to deal with how they hook into wp_head.
Yes, some plugins have no clue how to properly load scripts. That is really arguments for picking plugins carefully, not against WordPress core.
Concatenating and optimizing scripts is trivial with good caching plugin.
Overall and after your updates I feel that you are too eager to discard WordPress for issues that are inherent to any complex and fully-featured CMS (you need decent hosting to get it snappy) and you hadn’t spend much time looking into caching solutions.
It just might not be a good fit for the type of sites you build and you are better off looking into lighter, simpler and less functional CMS that will perform better under your hosting constraints.
