| ▲ | Tade0 10 hours ago |
| Pitch this to whoever is in charge of performance at Wordpress. A Wordpress instance will happily take over 20 seconds to fully load if you disable cache. |
|
| ▲ | rectang 6 hours ago | parent | next [-] |
| Are you talking about a new, empty WordPress instance running the default theme? Because if so, that doesn't match my anecdotal experience. If you're talking about a WordPress instance with arbitrary plugins running an arbitrary theme, then sure — but that's an observation about those plugins and themes, not core. As someone who has to work with WordPress, I have all kinds of issues with it, but "20 seconds to load core with caching disabled" isn't one of them. |
| |
| ▲ | lossyalgo 4 hours ago | parent [-] | | Can concur. I bought a plugin a few years ago after using the free version for many years, wanting to support the devs for making such a useful plugin. I installed it on a few sites, and left my PC running overnight with a tab open to the plugin and woke up the next day to a lovely rebooted Windows (I hate how default Windows behavior after BSOD is a reboot with ZERO indication that it crashed or if it was an update that rebooted). Re-opened all my tabs, and queue the same waking up the next day to a freshly rebooted Windows, which made me suspicious. I assumed at that point it must have been a BSOD, so dug into Windows event logs, eventually realizing it was Firefox. Restored tabs yet again, left browser open over night, while installing more and more debugging tools for Firefox, none of which helped me track down the culprit. What pissed me off the most was that Firefox even allowed a process to consume > 30GB of RAM and cause my PC to crash! I finally caught it one night after > 10 BSODs - the tab had been open for 20+ hours, and right as it started to spiral out of control and my PC was about to crash, as programs were starting to error out and Windows was madly paging things to disk. I got lucky, and was able to open about:memory to see the culprit - this plugin had some kind of memory leak that wasn't noticeable but then suddenly went nuts. I emailed the devs multiple times with the full debug output, and was ignored for weeks until finally they responded, which pissed me off even more having finally paid for the pro version, only to be greeted with this. The free version didn't seem to have this issue either, which was like an extra slap in the face. Naked Wordpress is plenty fast, but as soon as you start adding sketchy plugins and Themes, things can spiral out of control. |
|
|
| ▲ | embedding-shape 9 hours ago | parent | prev | next [-] |
| Microbenchmarks are very different from optimizing performance in real applications in wide use though, they could do great on this specific benchmark but still have no clue about how to actually make something large like Wordpress to perform OK out of the box. |
|
| ▲ | tracker1 5 hours ago | parent | prev | next [-] |
| Wordpress is something that I cannot believe hasn't been displaced by a service that uses a separate application for editing and delivery. It seems like something like vercel/cloudflare could host the content-side published as a worker for mostly-static content from a larger application and that would be more beneficial and run better with less risk, for that matter. Having the app editing and auth served from the same location is just begging for the issues WP and plugins have seen. |
| |
| ▲ | devmor 5 hours ago | parent [-] | | As someone who built full ecommerce websites on wordpress over 15 years ago, I can tell you exactly why it hasn't been replaced - the plugin/theme ecosystem. There are tens of thousands of plugins and themes to make a Wordpress website do whatever you want and look however you want, either for free or a very low fee. You have to replace that entire ecosystem for the same price to replace Wordpress. No matter how many times people get hacked, the perceived value of getting something for nothing outweighs the eventual cost. | | |
| ▲ | hparadiz 4 hours ago | parent | next [-] | | I did a short contract a few years back where multiple WordPress plugins were pulling different versions of guzzle and I had to use a namespace rewriter to be able to run multiple guzzle versions at the same time. The thing about WordPress is you can put it on a box and lock it down so hard you just treat it as an untrusted process on your server. | |
| ▲ | shimman 4 hours ago | parent | prev [-] | | Maybe it's just my poor imagination but how many plugins are truly unique to WP that you can't find on other CMSs? The only ones that come to mind would be those plugins that help connect to various B2B or B2C workflows, is that where the gold is mostly found? | | |
| ▲ | AlienRobot 4 hours ago | parent [-] | | WP essentially lets plugins do anything they want. The plugins are just scripts that register callbacks to events. WP calls events on BASICALLY EVERY FUNCTION. This is without exaggeration. I don't remember the exact names right now, but if you have a function like wp_get_title that gets the title of a post, there will be a "get_title" event that can modify which title is returned. So for every function first the data is computed using the default WP way, then plugins are allowed to discard all that work and replace it without something else entirely. There are events for deciding the canonical URL, for deciding the description of a post, for deciding whether RSS links will be displayed or not (the callback just returns true or false), etc. In other words, every property can be modified through global event callbacks. Some events are called very early in the whole pipeline that let plugins just render whatever they want (e.g. render custom XML sitemaps). |
|
|
|
|
| ▲ | rkozik1989 7 hours ago | parent | prev | next [-] |
| Much like anything else your performance is going to vary a lot based on architecture of implementation. You really shouldn't deploying anything into production without some kind of caching. Whether that's done in the application itself or with memcached/redis or varnish or OPcache. |
| |
| ▲ | slopinthebag 4 hours ago | parent | next [-] | | Either you use a slow language and deal with caching or you use a fast language and just put Cloudflare/Bunny/etc in front. | | | |
| ▲ | LoganDark 6 hours ago | parent | prev [-] | | > You really shouldn't deploying anything into production without some kind of caching. Citation needed? You only need cache if a render is expensive to produce. |
|
|
| ▲ | monkey_monkey 9 hours ago | parent | prev [-] |
| That's often a skill issue. |
| |
