WordPress Playground: A WordPress that runs entirely in the browser

Just come to WP.com and we'll run it super-fast, auto-updated, and secure for $25/mo.

you have to make sure you are on the right server, (apache vS enginx)

The problem is the ecosystem. You can get response times for the main page down pretty low (especially with caching plugins) and the time to serve static assets is the same for Wordpress or a static site. Most likely if your site feels slow, the culprit is your theme and one or more plugins on your site. You can usually track down problem plugin(s) using PageSpeed Insights since their frontend assets are served from the plugin folders.

> Is the problem PHP?

PHP is fast for a dynamic language (compared to say Ruby/Python and even JS). It has the disadvantage that it gets slow by default the more code you have, because it has a static execution model.

WP is extremely bloated and slow though. You can only make it fast by telling Apache to not execute it and hitting your cache (or with a caching layer in front).

With heavy caching (flushed on data changes), hand written themes and plugins, modern build tools for frontend assets, image optimization etc. You can get get top metrics.

However, that's just frontend. The admin panel is always slow.

If your use-case allows it, you rather build one with something like hugo. Hugo and similar are very easy to use and net you much better results.

My general tip is to not build websites with WP if you have web development skills.

First, seconding everything dgb23 said in this thread.

I think if you don't have a need for that dynamic stuff, yes a static site generator is a slam dunk in my humble opinion.

The PHP/Wordpress model where pages are composited dynamically for each pageview was an idea that made sense 20+ years ago. Whereas today, regenerating 1000 (or 10,000) static HTML pages can be done in a few seconds anytime a new blog post is made, giving up-to-date sidebars, homepage and stuff. Other code which needs to be dynamic can usually be fully client-side. And for comments, I don't think almost anyone uses the WP comment feature anymore. It's either off due to spam, or delegated to Disqus or similar. That, combined with the constant stream of WP 0-day exploits, really argues for having your actual WP instance behind your firewall and serving your files from an S3 bucket or plain Nginx (etc).

you also need a small footprint theme like (Neve), and customizing Apache with right modules to compress files, or with less customization ( nginx) might be faster

WordPress is very fast out of the box considering all its capabilities, it's not hard to get in the range of 100ms TTFB out of the box on dirt cheap VPS servers, which is pretty good in my book. The problem is that people add very heavy themes and plugins that push them well above acceptable TTFB numbers.

Full Site Editing with the new Gutenberg editor have amended a lot of that, it's very performant out of the box. Just as an example, I have a site averaging about 200ms for uncached requests, it has an FSE theme and 20 installed plugins, including heavy ones like ACF.

This is all out of the box without cache, but by adding a simple static page cache (either a plugin or something like Fastly, Varnish etc.) you can make it so that the p95 latency drops by 80-90% because most people will see cached page views any way.

Mine renders pages in under 50ms under BAU load and it's hosted on a $1/month cPanel. The only trick I have used is to run it on PHP 8.1 with Lightspeed Cache

I worked on a Strattic conversion some time back - they basically scrape all your pages and serve them statically, but you do have to do some things to support search, forms, etc and you'll end up pruning plugins that don't work well with it.

But, serving static pages is very very fast afterwards.

Redis or memcache plus a full page caching solution plug-in, mainly.

Use a plugin like 'Cache Enabler' by KeyCDN, it's very lightweight and does exactly one thing very well.

Get rid of as many plugins as possible, many of them add a ton of load time and browser load. Woocommerce is especially bad.

Use a lightweight theme, there are a few good ones out there for that. Or just the default one it comes with.

And yeah if you have zero dynamic content needs then a static site generator can work fine. But with minimal plugins and a cache enabler, response time should be very fast anyways.

The problem is architectural.

Wordpress at its core execute most of its user-facing code trough an un-parallelizable, self-modifying single threaded queue, which has to be run at every page reload[1] and everything and anything will have to inject stuff in it. From handling your pictures in your media library, to checking your server can actually send mails, to managing your page and posts content and layout, everything goes trough it. It's also a system that doesn't really play ball very easily with most PHP accelerators outside of baseline PHP opcache.

You may have better luck using a static cache or memcached. Depending on the theme you're using (90% of what's available from envato themeforest, for example) the improvement will be negligible due to the impact of all the uncachable third-party jquery plugins that are usually included on a commercial theme.

All of the data you're accessing is also for the most part queried from two tables of a single database instance[2] which again handles everything from your mail configuration, page routing and redirection, page layout, contents, stored forms, etc. No sharding, load balancing is natively available. Heck, most WP hosted solutions run MySQL on the same instance running Apache and PHP.

Also the data is usually stored as serialized php values, which have to be parsed and reformatted, again, at every page load using the system described beforehand.

[1]https://github.com/WordPress/wordpress-develop/blob/6.2/src/...

[2]https://codex.wordpress.org/Database_Description

> 1,135,948k of memory

That's 1.1GB.

That's horrifying because, theoretically, it should be a tiny, tiny fraction of that: on bare-metal we can run PHP + MySQL (let alone SQLite) + Apache within a few dozen MB of RAM.

(Historical personal anecdote: my first-ever dev-server machine I built before high-school ran Windows Server 2003, IIS, SQL Server, and Adobe Photoshop 7.0 (in a Terminal Services session) concurrently just fine well-within 256MB with little-to-no paging)

Let's be generous and assume that 64MB should be a reasonable upper-bound (though I think that getting it under 16MB should be possible), in which case what exactly is the other 1.09GB of RAM being used for?

The browser task manager may claim that, but actually watching Windows Task Manager, my total memory usage increases by about 300MB when I visit the playground, not 1GB. Maybe a lot of the memory is uncommitted.

Going to go out on a limb here and say that a sales pitch doesn't address parent's comment...but it does seem to be implicitly acknowledge that Wordpress is too cumbersome to maintain and even host yourself.

Very interesting, but I don't think sync from MEMFS to OPFS will work for my use case :( Is there a reason why using OPFS directly from SQLite doesn't work?

Replying to myself. I guess I read that a bit too quickly:

> In Node.js, the answer involves a WebSocket to TCP socket proxy, Asyncify, and patching deep PHP internals like php_select. It's complex, but there's a reward. The Node.js-targeted PHP build can request web APIs, install composer packages, and even connect to a MySQL server.

Hm, that sounds very interesting and promising

They estimate ~155MB just to get PHP running in Workers. It will be more to load WordPress. And there is extra work to get it running with Cloudflare D1. Plus everything else that likely won’t work by default there (e.g. image uploads).

Ghost can't be used on random shared hosting. Maybe Statamic can but it is probably not straightforward.

VPS is I think better solution anyway. However for many people it is overkill to have VPS just to run some simple website.

Primo is another

I am very sure the Github page I linked to doesn’t have any mouse animations. It has a README right on the page, with all the info. It also lets you clone the code and try it out, watch videos and much more.

Did you purposely seek out a different page, see a mouse animation, and then announce to everyone that you did not read further down THAT page because you were distracted by an animation? It seems like a petty thing to announce, but OK.

Then you don't get updates/fixes. And may need to edit the code after acquiring it, to stop license checks. And you'll need to go to the effort of extracting the relevant files from the environment in the browser.

Overall... yeah, sure, maybe, but anyone with any amount of money in their budget for this at all is just gonna pay instead of dealing with that.

Sure and you’d be open to liabilities but this is also relevant

https://developer.wordpress.org/themes/getting-started/wordp...

Now you have to build or configure a system for spinning those up and down at the command of anonymous visitors to your website. Or eat the cost of running a whole bunch of them all the time. And test that system. And monitor it. And secure it (and no matter how well you do that, you're now exposed to a wider set of risks than you were if you hadn't built this thing). And do maintenance development as dumb crap happens under & around you ("fucking [vendor] API broke on us again, with what was allegedly just a bugfix update, that they rolled out at local midnight on a Saturday without warning..."). And have another thing to look at & talk about in budgeting discussions and spending audits.

Yes, of course you can do it, and the cost of running it may be low, but the cost of bandwidth transfer to send the files to browsers so they can run these instead is probably a lot lower, and saves 100%[1] of that initial and ongoing development & operational spending. There's a largish complexity cost to the whole thing, that's all but completely absent if you run it in the browser instead.

The raw cost of running ephemeral VMs isn't the meat of the expenses I meant.

[1, edit] OK, not 100% exactly because they did have to develop this thing the link is about, but that's also a thing that can be used for other stuff, too, not just yet another way to press a button and spin up a cheap VM running Wordpress—this is a unique product, potentially, with many uses, one application of which happens to be filling the role of providing live demos in Automattic's theme/plugin marketplace.

WordPress is both free and open source, what are the extra dollars for?

Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about. Beginners tend to want a hard line with "coding" on one side and "not coding" on the other, but that's not a very useful way to model interactions with computers.

It's more of a spectrum of complexity, with WhatsApp on one side and full-blown software engineering on the other. In the middle is a vast gray area, much of which could very legitimately be referred to as programming, but which equally someone might consider to be simply using an application (like Excel).

Further, what tools you use is less significant for whether something should be considered coding than is how you're using them. I'm a professional web developer, and the way that I and my colleagues use CSS is unquestionably coding. On the other hand, someone who's just styling the fonts on their squarespace page might not consider what they're doing to be coding and that's also fine.

I hope we can make the .org Theme directory so good and Gutenberg + Patterns so usable you don't need to go to Themeforest anymore.

In my experience, I bought some pro/high sellers/high rated themes on Theme Forest for 3 sites, but all of them come with a bunch of pre-installed plugins, and was a mess.

Specially two who have a mandatory plugin to edit pages, called WPBakery, damn I hated it, is awful, the native WP editor is miles away (Gutenberg), but the design will brake if you use Gutenberg. Also, this and other plugins do not auto-update automatically, for each update you have to login to a site of the theme seller, download a zip, and update the plugin manually. And also on the admin you always gets upsells of the pre-installed plugins all the time, you can't disable it, sometimes you get a rack of 3 top banners simultaneously.

The end user sites looked really nice tho, but the editing experience was horrible.

I might have misinterpreted your comment, but there are plenty of site builders for WordPress (WYSIWYG-ish editors). Granted, you can only do so much without knowing CSS.

I'd happily put "completed a major Drupal version upgrade" on mine, if I'd ever successfully accomplished it. I think it was 6 --> 7; still gives me the willies to think about that attempt. Seeing that on a resume would be an immediate "wow, this person can handle a complex migration..."

Oh man, I have tons of experience with WordPress AND Drupal early on in my career. Good call, I'm not going to have these on my resume haha.

The plugins are both awful and brilliant at the same time. Well, maybe not so much today. But back before I knew I what I was doing, back before Ruby On Rails really took off, it was pretty awesome to have a Wordpress blog, install a plugin, and suddenly you've got a fully fledged forum section on your site.

Of course the architecture and the mode of installation for those plugins used to be horrendous and fraught with so many problems.

The customer support and testing are key challenges. You have to be ready to help people with things that aren't even your fault if you don't want your rating on the marketplace(s) to go to shit. Plus you'll need to do lots of sales/ads/marketing to get your zero-ratings zero-downloads plugin off the ground, no matter how good it is. Writing a decent and useful plugin is helpful (almost wrote "necessary", but it's actually not—at least the "decent" part) but isn't sufficient to have a successful plugin.

You could look into making single purpose blocks. Then you can get listed in the block inserter upon search an site owners an install your block right from there. Some plugin developers made great inroads in active installs with this more friction less process. Once your block/plugin is installed you can provide links in the sidebar to more expansive plugins or premium versions.

Yeah, I know there exist high-paying PHP jobs, it's just that finding a PHP job that pays as much as Swift or C# or Java or Javascript or [insert almost anything else here] is usually relatively challenging.

I don't mean that there are zero people making good money in PHP, just that it requires flying a rather tricker and less-certain course to get there, than with other options.

I really might put PHP top-of-page—at least, in some contexts—if marketing myself as a high-priced contractor, for the reasons you mention... but, in hunting for ordinary jobs, I no longer even bother looking at PHP listings. Too much chaff, not enough wheat, and it's been like that for a decade or more. Just way easier to find an employer with compatible pay expectations, with other languages, if we're talking run-of-the-mill jobs. Shorter searches, more-consistent outcomes.

Are you... asking when you'll get a feature in PHP while not knowing it employs sigils on variable names?