DE{CODE}: 2022—Year of the WordPress Developer
There has never been a better time to specialize in WordPress development. WordPress continues to eat the internet as the world’s favorite Content Management System (CMS), and even the most popular headless CMS.
In this keynote session from DE{CODE} 2022, WP Engine Founder and Chief Innovation Officer Jason Cohen discusses the challenges and opportunities that lie ahead for WordPress developers and the projects WP Engine is working on to make their lives easier.
Check out the full video below!
Session Slides:
Full Text Transcript
JASON COHEN: Hello and welcome to DE{CODE}, WP Engine’s annual conference where we celebrate the WordPress developer. My name is Jason Cohen and I’m the founder of WP Engine. I want to kick off this year’s DE{CODE} with a conviction, which is that 2022 is the year of the WordPress developer. I’m going to explain why I believe this year holds so much promise and opportunity for all of us and then I want to talk about how you can accelerate your career in this market.
So let me start off with a question, every community of software developers is known for something so what are WordPress developers known for? I’d say that WordPress developers are known for making beautiful websites that publishers love. So here’s what I mean, we all know that there’s millions of websites out there that use WordPress but you also have folks like Under Armour, a multinational apparel brand that uses WordPress and hires WordPress developers.
Now Under Armour did $5 billion in sales last year so they’re not using WordPress just because it’s free. They can afford to buy whatever software they want. They use WordPress because it meets their requirements and they employ WordPress developers because you know how to take those requirements and produce beautiful, easy to update websites. Like this one.
Or National Geographic, it’s one of the most revered media brands in the world and Nat Geo needs beautiful, easy to update websites with sophisticated digital asset management that can handle a media rich experience. So of course they hire WordPress developers. That’s a use case you’re famous for. And what about tech? Would a modern tech company use WordPress?
Yes, the team at Dropbox can build a CMS from scratch if they wanted to or they could use any of the Site Builder technology that appears all the time. But Dropbox chooses to work with WordPress and WordPress developers for the parts of their site that needs to be attractive and easy to publish to. What about a use case where the marketing team wants to use a different front end technology from WordPress?
So they want to use WordPress for the CMS but something different for the front end, can they still use WordPress? Of course, that’s what headless WordPress is. So they can make a choice like Android Authority did and go with headless WordPress. So Android Authority still uses WordPress as the CMS to manage writers, the content, media, all the things that are necessary to manage the back end of the website but the front end is handled by a different framework.
And when a brand wants the headless approach, like Android authority, they still call up WordPress developers because they want the performance and security of a decoupled website, sure but they need the site to match their publishing workflow and all of the other things they’ve come to expect over the last almost 20 years that WordPress has been powering their website. And WordPress developers know how to do that.
Making publishers happy is what WordPress developers have a well-earned reputation for doing and even the competitors to WordPress know this. Some of the most talked about startups and web development keep talking about WordPress. When you browse their websites one of the things you see in common is there’s always a page that pitches to WordPress developers. No matter where you look, everyone’s interested in WordPress developers.
That’s why I say 2022 is the year of the WordPress developer because you’ve mastered what every publisher needs and those needs haven’t changed, they’ve just accelerated. Like, every publisher needs organic traffic from search engines like Google, of course they do, and people still talk about how to do that all the time. Is that new? No, obviously not. Essentially the same articles have been posted about for years and years and WordPress developers are expert at doing this.
How about A/B testing? Or better yet, No Code A/B testing? That’s fancy. That’s innovative, right? Now you’re going have to scramble and learn these new tools. Well, except you don’t because you’ve been doing this for years. Like, this idea scored VC funding eight years ago too. Like, there’s no change here. There’s still No Code A/B testing and you already know how to do all of this. You’re already experts in all of this. That’s nice.
Many of you also know about recent changes in Google search that uses page experience as a ranking factor. Page experience means things like page speed and other things and you may also know about this as the Core Web Vitals update. Has Google ever made changes like this before that you’ve had to react to? Well, yes, all the time actually, right? And you know how to do that.
Yes, it’s a new tool but making websites fast, having that be important is not new and Google has used page speed as a ranking factor for a long time and it’s tried to infer whether a visitor to the site would be satisfied for a long time. These are all things you’re already expert in. So in some ways like that the world doesn’t change. And that’s nice to celebrate because when it comes to serving publishers in these ways, WordPress developers are already ahead of the curve. You’re already experts.
But there are other aspects to web development where I do see genuine change. Where the world is shifting rapidly. And that’s why I advise WordPress developers to think like an architect. So an architect combines requirements from the customer with art. An architect also combines requirements and art with the correct technology, whether that means building materials or software and infrastructure.
So that means you need to be capable of using all of the technology that is available and that means taking advantage of new innovations. Now that can be scary because having to learn something new can be disruptive but it’s also part of the job. When we decided to be software developers one of the things about software is it changes all the time. And so if we’re going to be good software developers or good architects, we have to stay up on the latest things so that we are picking the right technology for the different jobs that we have.
So things like A/B testing and SEO may be changing very slowly and fundamentally not really changing at all but technology is and you have to be on top of that and that’s what I want to spend the next 20 minutes talking about. What are some of those things? So what are some of these exciting new changes in technology that I think you should take a look at maybe even adopt? I want to give you a glimpse of what I see as the hotbed of interesting change in our space.
So the biggest shift in user expectation that you should become familiar with is called adaptive digital experiences. This is like personalization but more. Users want the look and feel and functionality of the site to adapt to their specific environment and conditions and even their history even if they don’t log in. Now when you deliver a personalized adaptive digital experience users will be more satisfied with their website and in fact, there’s a ton of data that when websites are adaptive, they convert better, people stay on the site longer, they click on more links and so forth.
In other words, as a media company, more clicks means more ad revenue. As an e-commerce company, more conversions means more revenue. As a technology company or any kind of company selling things online, even if it’s not e-commerce, more people engaged means more leads or more revenue. So in all cases, a more adaptive digital experience, meaning happier customers, quite literally means more revenue for clients. That’s why it matters so much.
Now the good news for us is that many of the advances of the web unlock the ability to deliver these adaptive experiences. So let’s explain this. Let’s show some examples. How does this work? So here’s a real example, an online magazine had a requirement to use HubSpot forums to collect leads. Why HubSpot forums? So HubSpot forums use a technique called progressive fields.
What this means is after user fills in a form, gives the information maybe to download a white paper or otherwise get something, HubSpot remembers that so the next time that person wants to get something, they don’t get asked for that information again. That means the person is more likely to go get more information, go engage with the site more and not be bothered.
This is a great example of an adaptive experience. But there is a trade off. Using this third party script, like HubSpot forums and there were others in this example, slowed down the website. In fact, their lighthouse mobile score was just 40 out of 100, which means their site is slow and means they’re not going to rank as highly in SEO. So you want this adaptive experience but it’s causing a speed problem. What do you do about that?
So that’s where this new technique called Partytown comes in. So Partytown moves third party scripts like this off of the main thread of the browser’s JavaScript engine and it loads it in a separate thread. So this means the site becomes interactive much quicker so users are not blocked from taking actions, interacting, and the lighthouse score moved from a 40 to a 90 just by using Partytown with the same cool, adaptive functionality.
So you can have the adaptive scripts that are really cool but slow and make it not slow. That’s cool. That’s, as an architect, the kind of things that you should be doing to make your customers websites great. So that’s a way to make JavaScript fast. Another big piece of performance is media, which you may know already, but wait. So anybody, but especially publishers with lots of media, want beautiful, large images that look great.
But if the images are simply large, then they’re slow to download and that will slow down the whole site, especially on mobile phones and on mobile networks. So now there are new image formats that look the same to a human but are much smaller and therefore load a lot faster. And you probably know about some of these formats, like maybe you’ve heard of WebP. But you may not know about AVIF, A-V-I-F, which is even smaller than WebP but still looks the same to the naked eye.
So just switching to AVIF images can dramatically speed up that magazine site or really any site. Now here’s the funny thing. I said, you probably know this. I gave a presentation about AVIF last year when it was just a few months old and now a year later, are you using it? No, almost no one’s using it. According to W3Techs, less than 0.1% of websites are using AVIF even with WebP it’s less than 4% of websites are using it.
So these are techniques which in some sense, are old or should be known and yet you’re still cutting edge if you use it. It’s a really easy way to speed up websites which of course, is good for users and good for SEO with image formats and people are still generally not doing it. Now, you may discover that WordPress doesn’t support AVIF but it does support WebP images.
So maybe WebPs good enough for your client, using regular WordPress or maybe this is another reason to use headless WordPress because then it’s a lot easier to automatically support AVIF. That’s up to you to juggle client requirements, juggle technical capabilities and figure out what’s the right way to put this together. But I think as an architect, just ignoring this altogether isn’t a good option. I think you should develop some technique here because it’s such an easy way to help your clients.
So let’s look at another innovation that’s happening on the front end, which is user settings on desktops and phones. There are now these new web based settings that didn’t exist five years ago and visitors to your client’s websites now expect those settings to be respected. So there’s things like reduced motion, font size for people like me who would prefer the web was all a little bit bigger, light and dark mode preferences, whether it goes from time of day or it’s just a user preference any time, or accessibility, making sure websites work well even for people with various ways of interacting with the web. Maybe for the blind or other special circumstances sometimes for regulation.
And this is neat for users, I guess but it’s a lot of work for you because you have to implement sites that support all of this. And there’s another problem here. When you build a site that’s adaptive, whether it’s to device capabilities like this or other things, things that are dependent on the user, how do you test it? How do you ensure this is going to work right in all these different circumstances?
So like one thing we’re all used to I think at this point is I’m going to take my site and I’m going to test it for the size of a mobile phone, and then test it for an iPad, and then test it for a laptop, maybe tested again for a super wide screen but that’s already three or four things I got a test. But now– well, what about in each one of those cases, what if the font size is set really big? Does it still look right? Are you testing that? What about light mode versus dark mode? That’s another times 2 number of things you have to test.
So each one of these things, font size, light mode, accessibility, using different kinds of browsers, all of it multiplies the combinations of things that you have to test. So that’s kind of hard. So for some people that’s what they reach for automated testing. Maybe some of these cases can be handled with through automated tests rather than a human being looking at everything every time.
So that is good but it’s not a complete answer because an automated test is not going to know whether dark mode site looks OK. That’s really something a human being has to judge. So this testing thing is still a puzzle and I’m going to come back to it in a little bit because I’m going to show you the next piece of technology which among other things also helps with this testing puzzle.
So the next thing I’m going to show is something really neat that I’m personally very excited that we’re getting in CSS and HTML, because I have wished for this. And in fact, I’ve even personally built code to try to do this in JavaScript, because I wanted it that badly. And now it’s coming natively to CSS and HTML, which means it’s going to be available everywhere. And Performant and all the other tools will support it. And so I’m very excited about this.
So what is it? So you may be familiar with CSS media queries. So this allows you to deliver a different layout or look and feel based upon the size of the entire screen. But now there’s something new for adaptive layouts which is called CSS container queries. So instead of a layout flowing differently because of the size of the entire screen, a single component can display differently just based on its size or just based on the components around it.
So for example, I may have a component like the ones you’re seeing here, which have a wider version and a more narrow version. Now I might need the narrow version on the phone and the wide version on a laptop. That’s the usual way we think about it. But what if in the wide version I actually have three columns? So in each column I do want the narrow one microphone.
Now see the current CSS doesn’t support that. It just says the whole screen is wide so you’re wide as opposed to yeah, the screen might be wide but you’re in a column so you still need to act like you’re on a phone. That’s what the container queries do. Super excited about that. Now, this is just part of an even larger trend which is a shift to thinking about web pages, not as an entire web page but thinking about it in terms of components. Pieces of a page.
Now as a PHP developer, you’re used to separating some things. Styles go here, functions go there, whole page layouts go there and so forth. But shifting to components is a bigger shift. It’s saying that the piece is inside of a page should be composed in these reusable individual components. The underlying technology of the web like CSS and HTML is moving toward components as you just saw with this component like thinking where my size should be based on myself not based on the wider page.
You can also see this kind of thinking of course in Gutenberg. So WordPress users are no longer writing these long pages. They’re assembling blocks. Blocks are components. Units that you can re-use and assemble any way you want, whether that’s pieces of content like text or a title or an image or layouts like columns and tabs and all kinds of other things.
And of course with full site editing this just goes even further. Now laying out the entire page, also with blocks which are components, is how we’re doing it with WordPress so this is a shift you have to embrace as a WordPress developer to not get left behind. Because whether you look at it from the underlying tech like HTML and CSS or whether you look at where WordPress has already gone and where it is going with Gutenberg and full site editing, all of it points to you have to think about things in components, maybe even develop things like components.
And this is even true when you look at the wider web of frontend development like in headless websites and the world of JavaScript, it’s exactly the same story. So JavaScript frameworks like these, react, view and angular, which almost everyone uses one of them, they’ve been component based from the beginning. For years. You don’t put things into separate files, you put components into separate files and you reuse them.
So this is the thing that whether you use JavaScript with headless or you use WordPress or you just write HTML and CSS raw, you still have to think about components. So there’s a lot of value to it. It’s sort of like how object oriented programming encapsulated data and code. Similarly, web components encapsulate the look and feel, the behavior, so the data and the code too, and make them reusable which is awesome.
Another thing, besides being reusable and composable, is that they’re individually testable. So this gets back to the testing thing we were talking about. So you can take a component, even just a button say, and then you can test it in these different contexts. What is the button look like when the text is large or small? What is the button look like on different kinds of browsers? What is the button look like in light mode or dark mode, and so on.
When you test just a button in isolation it’s a lot easier to test all kinds of combinations, it’s easier to fix bugs and so forth. And then you have this nice reusable button that you don’t have to keep testing after that. So by having an array of components that are individually testable, which is easier, you can now compose pages which just work the first time. So that’s part of the answer again to hey, how do I how do I test and build these websites that work well in all these different circumstances?
So components, it’s a way as an architect I think you need to approach websites. So as a WordPress developer you already understand so much of the world. You understand how to work with publishers. You understand how to convert their requirements into real life. You understand how to mix code and art and requirements and make websites that are wonderful and effective.
The trick is this new technology to learn and to bring in so that rather than being left behind, you’re leveraging things like adaptive experiences, and the tools behind those, and components in order to build these things. And so at DE{CODE}, the presentations here are designed to help you do just that. So at DE{CODE} we have a track for headless WordPress, you can learn when to use headless for a client, when not to use headless. We have workshops to help you get started with headless from scratch, really fast like in minutes. So if you’re curious at all about that, go check those out.
We also have breakouts for e-commerce and manage WordPress and other topics. And my advice is that as you go through the day, as you look through all these sessions, that you absorb what you can, take notes, etc but you look for that one, two, or three things that you say, OK, those are the things I’m going to try. I’m going to learn those things. I’m going to try to bring those things into a project. I’m going to get good at that. Maybe I even go back to my existing clients too and say, hey, let’s upgrade your site to use this.
So keep an eye out for like what are those few things that you’re going to take away and actually put into practice as an architect. So keep delighting those publishers, keep expanding into new frontiers, keep growing as an architect and this year, 2022, will be your best year as a WordPress developer. Thanks.
