Specifically, David Mainayar said in Woo Weekly #399 that it’s the fastest he’s seen, and I imagine he’s seen a lot.
This is a case study from Zeek, about their work for RUDIS, “a high-volume ecommerce brand” in a high growth phase. Built on WordPress and WooCommerce, RUDIS’ initial experience at scale was not good: A site crash during a product launch. Back-end slowdowns that impaired content management and customer support. Had they built on the wrong platform?
With user experience and performance as primary concerns, RUDIS needed to ensure their ecommerce site was engineered for speed from the ground up. Unfortunately, their questions were often met with answers like “WordPress wasn’t built for that” and “WooCommerce doesn’t work like that” or recommendations to secure more resources, change hosting environments, and use larger servers — which all lead to higher operating costs.
The solution was headless WordPress+WooCommerce with Gatsby, a JAMStack static site generator that uses GraphQL. Including WooCommerce in a JAMStack setup was a challenge because WooCommerce product, category, and shopping cart pages request a lot of dynamically generated content from the database with each page load. Zeek claims to have been the first to come up with a good headless Woo solution.
How they did it:
- Gatsby renders the page and product content and visual presentation as static HTML.
- GraphQL pulls in only the necessary, small bits of dynamic data like price, sales alerts, and quantity available in one request.
- Pre-loading ensures that as shoppers browse category pages, linked product pages are pre-built in the background so they load immediately upon click.
It’s really nice to see a positive ending to this headless WordPress story after laying out the difficult starting position many companies may find themselves in with WooCommerce. It reminds me of an insightful Twitter thread from Phil Crumm not too long ago, where more of the challenges and downsides to headless WordPress at present are broken down:
WP+WooCommerce is attractive because of its flexibility, and it doesn’t take highly specialized developers to work on. The challenge is high-volume stores, where David Mainayar (and others) identify “the lack of bulk post-meta query insertion support” as an obstacle, but custom order tables are a way forward. It’s easier to scale when your database is structured in line with the needs of your content and application instead of placing everything in the posts table by default.
Related:
- Press This: How Headless WordPress is accelerating Enterprise WordPress adoption with Adam Davey (Torque)
- Reasons for custom tables in WordPress plugins • More on Custom Order Tables (Post Status)
- Custom Tables come up in this discussion of core performance with Adam Silverstein (Do the Woo)
