Demystifying Headless and Static Architecture with WordPress

Sam Brace: [00:00:00] Welcome to MX Matters. This is where we discuss amazing things that are happening in the space of the visual economy, whether that’s trends, best practices, case studies and more.

I am Sam Brace. I’m the Director of Customer Education for Cloudinary. And joining me for this episode is my friend Gary, who happens to be the VP of Technology Partnerships also at Cloudinary, Gary, welcome to the show.

Gary Ballabio: Thank you for having me, Sam.

Sam Brace: So Gary, we have a great guest with us here today, Miriam, who happens to be the head, the lead at Strattic. And I’m very excited to have this conversation because we’re gonna dive into lots of different topics when it comes to the concepts of headless architecture, we’re gonna get into what a static site generator is. We’re even probably gonna unpackage a lot of terms like Jamstack and microservices, and even more.

But Gary, before we do any of that, tell me a little bit more about what that means for you as somebody that works for [00:01:00] Cloudinary in a technology partnership role.

Gary Ballabio: I’m really excited to have Miriam here. We’ve been working with Strattic for the last year and a half or so, maybe a little bit more, something to that effect. They’re a great partner of ours. Strattic is based out of Israel and a startup slash emerging company I would say in the Jamstack space, but specifically focused on WordPress. So, we love working with her and her team. Miriam is filled with knowledge about this space and it’s gonna be a very interesting conversation for everybody.

Sam Brace: I completely agree, and I think it’s great for us to just now bring her on board. So, Miriam, do you agree with what Gary said here? Do you feel like this is gonna be the type of conversation?

Miriam Schwab: I think it can be a very interesting conversation. We’ll see how it goes, but I’m excited to be here and talk about all of my favorite topics with you guys.

Sam Brace: So tell us a little more about Strattic. I know that Gary gave us a good rundown of what this is from a high level view, but of course you’re in all of the details. So tell us a little bit more about the company.

Miriam Schwab: Strattic is a new approach to hosting [00:02:00] and deploying WordPress websites.

It’s an end to end platform where the WordPress site is hosted within Strattic, except for that site is not accessible to the internet. And in one click our users deploy a static replica of the site. And that is what the internet uses. Static doesn’t mean, not exciting, not dynamic. It can still have dynamic functionality.

The static replica of the site looks and acts the same. What static means is it’s referring to the architecture. So as opposed to with your standard WordPress site, which is a dynamic site and each page doesn’t actually exist in a standalone way, on a static site it’s actually a collection of prerendered static files – HTML, CSS and JavaScript.

And the benefit of that is that that site, that replica of the WordPress site is the most secure, fastest, most performing and most scalable version of the site that you can possibly have. That’s Strattic.

Sam Brace: I know that you’ve mentioned static architecture at this point, but I also have heard lots of people within this space talking about headless architecture.

Can you define like what the differences might be between something that’s static versus headless?

Miriam Schwab: [00:03:00] Static and headless overlap in some ways and are different in some ways. So what headless means is that you have a front end of the site, which is what users interact with, and that it is completely decoupled from the engine or backend or admin area that powers the content. Often in the headless architecture, the front end is built in some kind of JavaScript framework, like React and then the backend can be whatever you want it to be. It can be combination of APIs and headless CMSs and whatever you want.

That’s in the standard headless ecosystem how people approach it. But static and headless can overlap in that the front end of the site can actually be a statically generated version of the content. So some tooling around that is something like Gatsby and other static site generators.

With regards to Strattic, we see ourselves as living between those two worlds. The reason is that first of all, the WordPress site is statically generated on Strattic. So it’s definitely a static site, but also what we’ve done is we’ve completely decoupled the front end of the site from the back end.

[00:04:00] So that also makes it headless. So, you know, some people may agree or disagree with how we see things, but we see Strattic as fitting like pretty much within those two worlds in many ways.

Gary Ballabio: Yeah. Speaking of which, I think it is quite interesting, there’s been a debate that’s been happening on the WordPress side for, you know, I guess it was maybe again, like a year ago or so where there was a very famously at I think it was a Jamstack conference if I’m not mistaken where Matt Billman and Matt Mullenweg were debating over the the benefits, pros and cons of headless architectures and specifically around WordPress as well.

They had clearly, they were representing both sides of that conversation. I think it’s kind of interesting to hear your perspective Miriam of that debate of that conversation, cuz you seem to sit sort of right in the middle of it all. What’s your take on the debate?

Miriam Schwab: That debate is connected to kind of the history of Jamstack and where it came from and how it is positioned vis-à-vis WordPress. Matt Billman, the [00:05:00] co-founder of Netlify, the way I see it is he essentially created the Jamstack approach to kind of be the anti WordPress. WordPress at that time, he started kind of toying with this idea and developing products around it, let’s say 2015, 2016. So at that time, WordPress had been around, I don’t know, 15 years, 14 years, and continued to grow and gain more and more market share, but also continue to demonstrate the issues around managing a WordPress site. And the challenges, which kind of, as they went on became more and more present for users just as WordPress’s market share grew, it started becoming more and more hacked and performance because it’s on what’s known as the LAMP stack, you’re constantly kind of fighting against that architecture to make your site performant. All of that became constant pain points in the WordPress ecosystem. And Matt Billman came along and was like, okay, that’s too painful. It’s also not so developer friendly. Let’s try to figure out a different way to approach web development. And he started to work on and promote this concept of [00:06:00] static site generators.

And then eventually he coined the term actually for Jamstack. So just so you can hear it, Jamstack, LAMP stack, you know, that terminology even comes to be the anti LAMP stack and anti WordPress. From its infancy, Jamstack was basically meant to replace or aim to replace WordPress. And so that debate between Matt Mullenweg, the co-founder of WordPress, the open source project and the CEO of Automattic, which is a company behind WordPress and just full disclosure, Automattic is an investor in Strattic. And Matt Billman, the CEO of Netlify was based on their two seemingly opposing positions where Netlify is like WordPress you know, you did a good job. Your time is done. You’re legacy. Now it’s time to go to the future. And WordPress’ perspective, which is, you know, WordPress continues to be a great product. And there’s a reason that this market share grows so significantly all the time. So we’re here to stay and we’re here for the future. That debate never was shared. They kind of went at each other [00:07:00] almost in a pretty aggressive way. It was interesting to watch, that’s for sure. I was fortunate to have tuned in when it was happening live.

Chris Coyier was the MC, the moderator, and he was just sitting there, like Matt, Matt? It’s like a little bit awkward. But a few things have happened since then. So first of all, from my perspective and who am I versus them? But I’m just saying how I see it is that it’s not either / or, and I think they, in that debate, they kind of were both missing the point. Netlify’s approach depends on a content management system being involved in the stack, it needs a CMS and you can choose many different CMSs. One of which can be WordPress, which is a very legitimate option. And particularly with WordPress powering 43% of the internet now, there, you know, you can’t ignore it. And there’s a reason it’s growing, because it’s so user friendly and just people are so used to it, particularly marketing teams who are the ones who use WordPress sites on a day to day basis. You need to give them their power tools. So that I think that point was missed there. And Matt from Automattic, WordPress continues to grow and I think its [00:08:00] future is assured, but we are in 2022, which is different than when WordPress was originally created 18 years ago. The internet has developed further. Peoples’ needs and demands are different. And there are amazing new approaches in web development that WordPress can definitely look at and try to gain inspiration from.

What I’ve seen since then is that both sides can’t ignore each other and they shouldn’t ignore each other. Netlify did a survey of their own developers, 7,000 developers. And one of the questions was which CMS do you use? And WordPress like blew everything else out of the water in terms of adoption.

Like, and this is in WordPress’ cutting edge, sophisticated developer community. They’re using WordPress, whether they like it or not, that’s what they are. They have to use for the marketing teams or the content managers. And in the world of WordPress, there’s some interesting projects that have come along related to headless and static WordPress, Strattic being one of them. If I do say so myself, it’s interesting. Like it’s weird to call my own product “interesting”, but it’s one of them. But even Automattic, the company [00:09:00] has deployed some headless projects for their own clients and customers. There’s like a convergence or at least a greater understanding that there’s no reason has to be either / or. Everyone can live together and everyone can learn from each other. Netlify shouldn’t ignore WordPress. It continues to grow. It’s got huge market share. It’s here to stay. And for good reason, cuz it’s an amazing platform. And WordPress needs to also look towards these modern trends and be like, what can we learn from here? What can we adopt to assure our future? So anyways, that’s my perception around that debate.

Gary Ballabio: Yeah. Makes sense. Neither can be ignored and both are gonna be part of the future. You know, they’re both still growing.

Sam Brace: So from what I understand, from what you just said, as well just in research that I’ve done is that WordPress can be a headless CMS in that scenario. What do you feel are the pros and cons?

Miriam Schwab: The pros and cons of using WordPress in a headless format are as follows. The pros are that you can gain the benefits around security, performance, and scalability because once you’ve decoupled the front end from the back end, that front [00:10:00] end can run more seamlessly and be more efficient.

And the other benefit of running a headless WordPress and a headless format is that developers like it more. So now, while that seems like, well, does that really matter? It does because developers definitely drive adoption of software. And so the more they like to work with something or in a particular way, that is what they’re going to promote within their organization. And often they’ll win out. The reason developers prefer that is because in that architecture, the front end can be built not with PHP. When you’re working with standard WordPress, the front end theme is built with PHP. And once it’s decoupled, you can use whatever you want, like React. Another advantage is this is relevant for like really big organizations, particularly media driven organizations like news sites, you can create a site that’s more API driven and then pull in content and information from different sources in maybe an easier way, which is kind of what React allows you to do to a certain extent, maybe better than PHP, although, by the way, I’m not convinced. But this [00:11:00] is often, you know what is said. And then the content is more portable and more malleable and just that can make it easier to mesh different content together.

Sam Brace: You mentioned something here though, like, so you’re talking about security and performance being increased when you moved to headless in the WordPress environment. Break that down for me because to me, I would feel like if you keep everything as is with WordPress, that actually would be more secure because you’re not pulling in all the different API calls and all these different places. But that’s of course me being a layman, not knowing the topic of the way that you do.

So what exactly are the benefits from security and performance by moving to something that’s headless?

Miriam Schwab: When you’re running WordPress in the headless format, the backend is not as visible or as, okay, it’s definitely not visible, but it’s also not as accessible to the end user who’s visiting the site because it’s somewhere else.

And so what are the causes of WordPress security issues? It’s when you’re running WordPress in a standard format, you have a lot of layers of potential [00:12:00] vulnerabilities. You have the LAMP stack itself, all of which is generally comprised of open source software and, you know, functionality that needs patching that can have vulnerabilities.

So that’s those four things, the LAMP. And then you’ve got WordPress itself, which is actually pretty secure. If you’re running a WordPress site just on its own, there’s very little to breach, but still every once in a while, there’s some kind of security update that’s released.

And so just having that, there’s a window of opportunity for hackers between when a vulnerability is published and people update their site. So you do have that window there of potential vulnerabilities. Then there’s all the plugins that people install on their sites. Plugins are the great source of power for WordPress users, because they can just like install something and then they’ve got new functionality without having to use developers, et cetera.

And there’s a lot of plugins that people use as like the main components of their sites. So some examples of that are Yoast SEO or Rank Math SEO. Elementor page builder, other page builders or form plugins. Like it’s just you, they [00:13:00] can’t run their sites without them. And they shouldn’t run the sites without them.

They are really valuable plugins, but the more plugins you have, each one is a piece of software in and of itself that could potentially have vulnerabilities. So you have to have like a really disciplined regimen of patching and updating. And if you don’t on time, then you also have a window there for hackers.

So when all of that is not there, meaning not like as accessible to the internet, so you’ve removed a lot of the attack surface of WordPress. But in standard headless, and this is not the same as how we do it in Strattic, we do it differently. In standard headless, that WordPress admin or backend still always has to be up and running because it’s being pinged and accessed for its APIs to pull data into the front end of the site.

So it is accessible because it’s accessible from the front end. And one of the emerging security threats on the web today is API security. So we’ve just shifted the attack surface to something else essentially. [00:14:00] And then performance can also be an issue in a standard headless format because that front end of the site is pinging those APIs. And if not done in a very efficient way, it can actually overload that WordPress back end also, and then cause performance issues, which would then impact the front end. So headless offers a level of improvement for those aspects of WordPress, but doesn’t solve for them completely and they’re still there and they still need addressing to a certain extent even in standard headless format because the WordPress backend is always running.

Sam Brace: Does that mean that when you move to a headless environment with WordPress, does that mean that you can’t use plugins or does that mean that you just use ’em in a different way?

Miriam Schwab: That’s a really good question. Actually, a lot of plugins, you can’t use them anymore. So basically anything that impacts the front end of the site, like any plugins, I’ll just use Elementor again as an example, Elementor brings a lot of power to content managers, cuz they can just quickly lay out a page, design a page and they don’t need developers and they can see what that page will look like on the front end because the front end is completely tied to the back end. But in a headless [00:15:00] format, doesn’t matter how beautiful the pages are that they lay out in the back end, that will not be applied to the front end. So a lot of like functionality that’s easy to get in WordPress just becomes not easy to get in headless and you end up having to reinvent the wheel with so many things that we just take for granted in WordPress. So yes, you can’t use a lot of plugins in the headless architecture on WordPress, or you can, but you just won’t gain the benefit.

Sam Brace: And I guess, depending on who your audience is, that could be either a pro or a con, right?

Because like, I would see like some IT administrators would be like, “great! We don’t have to worry about security coming in through all of these plugins!” But then also as you’re pointing out, marketers, which are typically the main audience for a content management system, they are probably used to having Yoast, an amazing SEO plugin that’s used probably for at least a good percentage of WordPress instances, then that potentially pulls ’em away from the equation.

Miriam Schwab: I do just wanna say that Yoast actually has a headless implementation for its plugin, but that’s because they made the effort to do it. But still you [00:16:00] can’t just install it and be like, oh, well now it took care of everything, which is how it is on regular WordPress. You still have to tie it to the front end. And I think that it’s a much more limited support. Like Yoast has so much functionality and capabilities that replicating all of it for headless, I can’t imagine that they’ve done that, I don’t know for sure. But even so, let’s say they have, you still have to tie it in and that depends on developer resources to the front end. And so you’re in some ways still reinventing the wheel.

Gary Ballabio: What’s your best practice recommendation?

I mean, there’s a lot of websites out there. You mentioned 43% of the world’s internet websites are built on WordPress. There’s a lot of them that need to go through this, you know, migration to a headless architecture. I’m sure you’ve seen a lot of companies go through this already.

Miriam Schwab: First of all, if you’re exploring headless, make sure you really, really understand what that means. Understand how that will impact your marketing and content teams and your costs.

So for example, if you want to go the standard headless route, and again, this is not with Strattic and I’ll explain the difference, but if you wanna go the standard headless route, it means that if you have a WordPress website [00:17:00] today, you need to throw that website in the garbage and build a new one.

Okay. So that is a cost right there. And then add to that the cost of on average building a headless architected WordPress site costs 50% more than building a regular WordPress website. So there’s an additional cost. You had a perfectly good site you have to throw in the garbage, you have to build a new site and that site will in any case cost you more. Then on an ongoing basis, it will cost you more because stuff that your marketing team could do on their own, they can’t anymore. So there’s going to be greater dependence on developer resources. Plus you now need kind of two teams of developers, backend and front end. And like we mentioned, a lot of plugins that you could have used in the past to just get stuff done in one click, you can’t, so you have to develop it. So you really, really need to understand what that means for you. Do the benefits outweigh these disadvantages? From what I see, the main types of organizations where going headless makes sense are really the large media [00:18:00] companies that are like either themselves news sites or they behave like news sites, or they have many like web properties that all need to be linked together in some way.

And also that the organization already had developer teams that can support this move. And it fits in really nicely with the general company kind of ethos of web development. But really that tends to be larger organizations. I wouldn’t move to headless because of marketing messaging.

So what I, what we’ve seen is that people read about marketing like headless and it sounds cool. And then they’re like, well, this is the next best thing. So we really should probably use it except for that just because people say it’s the next best thing doesn’t mean it is the next best thing for you as an organization.

So it’s really, really important to understand what it means. If a company really wants to test the waters, I would say do it with a small site, some kind of mini site or something like that, or like landing pages, and then see what it means for you to operate for a few months, see how your marketing team reacts because they’re the ones who have to use it on a [00:19:00] daily basis. What does that mean for them? Are they frustrated or are they excited about it? And yeah, that’s what I would recommend for companies considering moving to headless.

Gary Ballabio: That’s a good point. I mean, it sounds like a monumental transition.

Miriam Schwab: It’s a really big ask to move to headless just because of those first steps, which is throw away your site now, build a more expensive one. Just that already is like really? Yeah. Okay.

Gary Ballabio: And then it’s when we’re gonna see the return on this?

Miriam Schwab: Yeah, exactly. Exactly.

Sam Brace: Let’s say, as a organization, an enterprise, something along those lines, do they need to be involved with CDNs? Do they need to have a tie to a content delivery network to be truly headless or truly static ?

Miriam Schwab: Once a company’s going headless, then they might as well use a CDN. It’s like, it only brings value. Hook it up into your CDN and then it’s fast everywhere. That’s basically what it comes down to. And you know, Akamai’s like super expensive and just, I don’t know. It powers the biggest companies in the world. It’s not for everybody, but there’s great CDN options out [00:20:00] there. So, on Strattic for example, what we do is we allow users to continue using WordPress as usual. So you get to use all the plugins, all that still works. But it’s containerized and isolated so that all you don’t have that attack surface. Hackers can’t access it.

And performance is an issue because the only people using the site are the team. Click a button, generate the static replica of the site. So it’s just a collection of static files. And then we tie it into a CDN. So all of our users get a Cloudfront CDN, which is Amazon CDN out of the box. It’s immediately tied in and their site then becomes fast everywhere.

So what happens is particularly in a static-ly generated site, as opposed to headless, it’s a collection of static files. So it’s already faster because every page has been prerendered and is ready to be served up immediately. And there’s no underlying processing server to potentially slow things down under load or whatever.

Plus then you serve it through CDN. So not only is it pre rendered and fast already, it means that if I’m in Australia, I’m going to access the replica of the site in the edge location nearest to me in Australia. And if I’m in the UK, [00:21:00] I pull it from the UK. And if I’m in the states, I pull it from the states. In standard WordPress, your WordPress site’s hosted in a geographical location.

So let’s say it’s in Texas. Means that people far away from Texas actually have to kind of travel across the world to get that data and pull it back to them. And that creates a level of latency. So CDNs offer a lot of benefits. They do need some management. So for example, when you update your site, you need to what’s called invalidate the cache, so that the changes appear immediately on Strattic.

We take care of that automatically. So nobody has to configure that when you’re using CDN on your own, you just need to make sure that you’ve configured that so that you don’t end up with a frustrating situation, which is, “all right. We launched our press release, but nobody can see it because the cache is not invalidating.” So, CDNs do demand a little bit more I don’t know, intervention, but other than that, they definitely boost sites that can use them. Just by the way, standard WordPress you can only use CDNs in a limited way because it, [00:22:00] CDNs can only support static files. Standard WordPress, the content pages are not static files. They’re dynamic. They don’t actually exist as files. So the only files you can serve up through CDN are CSS, JavaScript, and media like images and videos, which is something, but it just means the content pages, the user still has to crawl across the ocean and get it for themselves.

Gary Ballabio: Tell us a little bit more about where Strattic is going this year into next year if you can, if you get into that a little bit.

Miriam Schwab: We launched some really interesting functionality over the last little while. First of all, we have a new dashboard for our users. First in order to access the WordPress site, our users log into Strattic and we have a new dashboard, which also adds some additional functionality. For example, they can trigger backups from there and things like that, but also you can see who did a static publish and you can see what type of publish it was. In Strattic, we offer incremental builds. In this world of Jamstack and static site generation, one of the biggest challenges are larger sites because generally in order to update the site, you end up having to publish the whole site. And that can be a very lengthy process, particularly [00:23:00] for larger sites.

So what we rolled out in Strattic is in one click, our users can choose to do partial builds, like based on whatever they updated. And so that goes much faster. So if I write a new blog post. I can choose to only update the blog homepage and any related categories. I don’t actually choose it.

It’s actually like, that’s how it works. You just do quick publish and it does that for you instead of publishing the whole site again. We also have something called selective publish, which is literally like, I’m on this URL. I’m writing this blog post. I just need this to get updated or go live. Click. Done. Very, very fast.

So that’s this, those features are actually unlike anything that exists in this world of static site generation. So going forward, we have some interesting and practical things on our roadmap. So, we now can support larger media sites, but we can’t support really big media sites yet because they still, even the faster publish takes a long time with them.

So, we have some really exciting and interesting, innovative ways that we plan to support them. By com component… I keep saying this word that I think I’m making up, but I can’t [00:24:00] actually say it myself component componentizing

Sam Brace: I like it.

Miriam Schwab: so taking parts of the site and, and making them into components that are then pulled in rather than like having to publish everything and optimizing our own, our published speed in general. And we like to roll out initial steps in supporting WooCommerce, which is the largest eCommerce platform.

We have WooCommerce sites running on Strattic, but they use a third party headless shopping cart cause the shopping cart’s very dynamic, but the catalog and everything works fine on Strattic, but we just need to solve for that. And some other interesting things around workflows like for example one click rollback of the static version of the site. All of our users have two static sites actually. They have like a staging static and a production static so that they can make changes, test them on the staging static first, and then only then deploy them to the production. So, you know, you don’t add a plugin. You’re like, this should work great. And then you deploy to your public site and you’re like, oh, oops, actually. It’s not like perfect. They need to tweak it. So this way you can do that. So the idea is to be able to [00:25:00] publish from this preview static directly to the public product static and some other enterprise level features that our enterprise customers have been asking for.

So, yeah, so we have very exciting, big features and smaller features, which in many ways are revolutionizing this space of static and headless WordPress.

Sam Brace: I can definitely see the benefit of that, Miriam. Cause I’m just thinking about like large e-commerce sites that we buy things from. They have millions of products and if we’re saying we need to generate millions of products with every deployment, and I would think even in like a best case scenario that would still take at least three to four hours, if you were saying like certain things are done, that’s just, that’s not reasonable to ask. If you’re thinking about someone that’s like tied to the business line to the money and you’re saying, yeah, when we need to publish new stuff, three to four hours, That’s just not a reasonable answer. So it sounds like what you’re doing, you’re almost doing things in increments, the way that you’re breaking this down, rather than having to publish and deploy everything at once.

Miriam Schwab: Yeah, exactly. And also in this world of eCommerce or particular WooCommerce, whatever pain points we’re solving for WordPress, they are more [00:26:00] acute in many cases in this world of eCommerce because the sites are more complex. They have a lot more moving parts, which can negatively impact performance. And on eCommerce, performance is even more important. You know, for actually making sure that people buy from your site. And then security is more of a concern because people are processing more personal data through WooCommerce around shopping, you know, names, email addresses, things like that, that people generally aren’t doing on WordPress. So security’s even more of a concern there. It’s an exciting challenge that that we hope to tackle over the next year.

Sam Brace: One thing that somewhat selfishly that I do want to ask you about before we let you go. Obviously we’re talking about API based companies working with headless environments, and that seems to be static environments too, is where companies like Stripe for the e-commerce side of things. I know we’re talking about WooCommerce and the WordPress examples, but Stripe obviously benefits in a headless situation because it’s API based.

Somebody like Cloudinary, it is where the whole media management side of things, it’s API based. Do you see this as a [00:27:00] good thing, a bad thing? What should people that are deciding to make those decisions about going into headless and static? Is there any like considerations that should be taking about like what APIs they’re using or what companies are affiliating with? Anything along those lines?

Miriam Schwab: One of the great things about this trend in general, and it definitely applies to regular WordPress as well, people try to isolate and be like, it’s only about headless and it’s not true. In regular WordPress, it’s the same. Before founding Strattic, I had an agency that I founded and managed, and even there, our approach was the following. Always use the best tool for whatever goal it is that you have for your site. So WordPress is the best tool for the CMS, for content management, nothing beats it. Totally use that.

Do not use it as your CRM. like, really do not use it. I mean, there’s some great solutions out there, but in my opinion, don’t use it for newsletter management or, you know, emails. Like it’s not built for that. That’s not where it excels. Use the tools that excel for it. Don’t use it for e-commerce. Don’t try to be an e-commerce provider. Use Stripe or PayPal or whatever you want.

[00:28:00] And then I see Cloudinary, at least particularly in relation to Strattic as being the last mile optimization. So we do static site generation really well, like really well, but we do not do image like media optimization or management. That is not our strong point and it’s not part of our offering.

So while sites are going to be fast, after they’ve been published on Strattic, you can definitely gain even further performance improvements by implementing Cloudinary. And that’s why our partnership has always been really exciting to us because we’re not going there. Like we’re not gonna try to be, you know, Cloudinary has been doing this for so many years.

They’re like the best at it, because this is your focus. So it’s not our focus. So with an easy integration with Cloudinary, you get all of the performance benefits of statically generated site. Then, all of your media can be optimized properly and intelligently and media definitely impacts performance and page speed score.

So totally just add that as the last mile. It’s really [00:29:00] easy to do. And then you like covered so much ground. So from that perspective, in terms of looking at WordPress, I see WordPress is kind of like, I don’t know, the center of some kind of flywheel or I don’t know what to call it. And then you pull in or apply the right tools for each need. And so for that component, Cloudinary is a really great solution.

Sam Brace: I hope that people are using this now as a chance, if this is a first time experiencing Strattic, I hope they take the time to investigate the company. And then of course, if this is their third or fourth time that we’re hearing you on podcasts and other blog posts and whatnot, then hopefully they’ve been able to get new perspective from things that you shared here today.

I do wanna make sure that everybody knows that if they’ve enjoyed this episode, make sure they take the chance to like, and subscribe to all the different places where we happen to be. We’re on all the major podcasting networks like Spotify, Apple Podcasts, Google Podcasts, YouTube, et cetera.

And then Gary, it’s always a pleasure working to be on these projects. So hopefully we’ll have you back for another episode too.

Gary Ballabio: Same here. And thank you, Miriam. I enjoyed the [00:30:00] conversation and I always love listening to you. I learn a lot from you, so thank you for taking the time. It was awesome.

Miriam Schwab: Thanks for having me and I don’t know if it’s okay if I mention this, but anyone can go to Strattic and sign up for a free trial. No credit card needed and you can totally test it out. So when you sign up, you immediately can install a regular, fresh WordPress website. You can migrate another site into Strattic and test it out by clicking our static publish button.

It’s a third day free trial. If you want to extend it, just chat to our amazing support and they’ll extend it for you. So please check it out, kick the tires. And also we’re always open to feedback.