I recall a couple years ago @alexander mentioning that Global Blocks were fine to use sparingly but that they weren’t great in mass due to performance concerns because WP was essentially doing the work of loading in a second, third, fourth, etc page (depending on number of on page uses).
So, more curious than anything, when we’re dealing with buttons as Components, you could theoretically have 10+ different buttons (or other components) on a page – is this forcing WP to load 10+ pages?
I suspect the difference is that components will be the individual elements rather than sections which were loaded as mini pages
Although I would love to hear from those more knowledgeable than my guesswork
@DoncoMarketing, I will confirm on the exacting specifications of Component instances and how they are referenced, but I know from certain use-cases I was very adamant about how I wanted certain features to perform.
For instance, each Component Set has a section for custom CSS / JS just like any other Document type (Header, Footer, Page, et cetera). Let’s say you have a Component Set for “Buttons” where you plan on designing up a few button Components to use all throughout your design. If you have to use custom CSS in that Document CSS feature for whatever reason, that will only get loaded once on the frontend no matter how many instances of your buttons you bring in.
So let’s say you design a page and you put in 10 instances of your “primary” button style, 8 instances of your “secondary” button style, and so on…that Component CSS stylesheet will only be output once in your entire page.
@DoncoMarketing / @scotbaston, just wanted to fill you guys in on this a little more after looking into things and confirming my suspicions:
Using Components directly through the “Component” Element (including any Global Blocks that are moved to the new system) involves a DB query to retrieve the Component Document, which is stored as a WordPress post type. This means if you have 5 separate components, you’ve just made 5 queries to the database for each “page request.”
However, using Component exports comes with the performance benefit of only one additional database query because Cornerstone caches them internally.
Anytime a Component Document is saved, the system cache is cleared (it’s also possible to manually clear the system cache). When any Component is encountered, the cache is regenerated. This involves retrieving all the Component Documents at once, organizing the data to the minimum requirements for rendering the Elements, and caching that entire result in one place.
Subsequent visits to the site only require one database call to get every Component export. This scales very well allowing sites to store hundreds of Components without significant change in rendering performance. We have actually built out some test sites internally that literally use hundreds of Component exports, including using Components within Components within Components (you get the picture). Overall, it’s a much more performance conscious method of leveraging a design system.
Hopefully that helps to provide some more context!