Some great stuff I’ve learnt from WordSesh 2022

The online conference WordSesh 2022 took place last week, featuring talks for all of us making a living of WordPress (whether as a theme or plugin developer, designer, SEO specialist, or marketer, working in an agency, as a business owner, or freelancing), offering valuable lessons that we can benefit from.

As I’ve been re-watching the recorded videos (which are free until Friday, May 27th for registered users), I thought it’d be very cool to summarize the talks in a blog post. So here we are! But as there are 23 presentations, I’ve decided to select only 5 and give a more proper summary of them.

My chosen talks are:

• From Agency Owner to Plugin Shop, by Lesley Sim
• Pressing for Performance, by Henri Helvetica
• Growing Traffic, Growing Problem: How to Prepare for a High Traffic Event, by Tiffany Bridge
• How Live Streaming Transformed My Career, by Ebonie Butler
• QuickPost: Hacking the Block Editor for Faster Content Creation, by Aurooba Ahmed

I’ve watched all 23 presentations, and I can attest that they are actually great! (Or at least 22 of them are 😁.) So I’ll encourage you to go check out the videos, and hurry up while it’s free!

Here are the summaries for my chosen talks.

From Agency Owner to Plugin Shop

Lesley Sim shares her journey launching plugin Newsletter Glue, the mistakes she made and the lessons she’s learnt.

First the background to the story. Lesley ran a digital marketing agency from 2016 to 2019. 2019 was her agency’s most successful ever, but it came at the expense of her sanity as she took many new clients and ended up burnt out. So she decided to shut it down, and set her eyes on a different challenge: creating a plugin for WordPress.

She first started working on a membership plugin, but it failed because the membership plugin industry is mature, so that people would stick to the plugin they already work with instead of trying a new one (even if it’s better), and she didn’t have a reputation to make people trust her. While shutting it down, she noticed that a small add-on, which let people send blog posts out as newsletters, did attract plenty of interest. And so she pivoted to creating a different plugin: Newsletter Glue.

Next, Lesley starts sharing the lessons she learnt from switching from running an agency, to creating, marketing and selling a WordPress plugin. At first she thought she’d be fine, as she already knew how to run a business and had several transferable skills (knowing how to build a website, hire and manage people, set-up processes) that she could also apply to the plugin business. However, she soon found out that she also needed to learn many new things:

• Doing customer support and writing documentation
• 0 to 1 marketing: getting a reputation in the WordPress community, to grow awareness about her product from scratch
• Product prioritization: building what customers want
• No excuses: you only have yourself to blame, not your clients
• Pricing: finding the right price for the product
• Picking your own pace: you set your own deadlines

If we are wondering if we should run a plugin business, Lesley recommends reading Nathan’s Barry article The ladders of wealth creation to help us decide.

In her own experience, and making it very simple, Lesley found out that running a plugin is riskier and more difficult than running an agency, but it also entails bigger rewards.

Breaking this down, she first explores the positive and negative sides of running an agency (and will compare them against the positive and negative sides of running a plugin business). The positive sides are:

• Can make money quickly: finding one client that pays can set you going
• Only need a handful of clients to be successful (depending on the amount of money you charge)
• Only need 2 skills: design and client management

The negative sides are:

• It’s difficult to sell the agency for lots of money down the road
• Time equals money, so to make more money you need to work more
• Unreasonable clients (self-explanatory! we’ve all been there… 😂)

How do these positives and negatives compare against running a plugin business? As it turns out, it’s exactly the opposite! So the positives become negatives, and negatives become positives. The only exception is “Unreasonable clients/customers”, which are a constant! 🤷‍♂️

Soooo… should you run an agency? Or should you launch your plugin business? Based on the positives/negatives we’ve just seen, and her personal experience, Lesley draws her conclusions, suggesting to run an agency if:

• You want money now
• You’re excellent at 1 skill
• You don’t want to juggle 100 things
• You like process

Instead, run a plugin business if:

• You have specific product options: do you get annoyed when using others’ plugins and think you could do it better?
• You can handle risk / You don’t need money right now: plugins are easy to fail, and it may take a while before the plugin starts making money
• You find doing 1 thing boring and prefer to do 100 things: support, writing documentation, optimizing website, development, fixing bugs, adding new features, etc
• You like experimenting

So what if you want to do both? Say that you have an agency, does it make sense to also create your own plugin? (There are examples of successful plugins created by agencies, such as Paid Memberships Pro and Gravity Forms.) This has benefits:

• It helps make ends meet and de-risk if the plugin fails (as you are still making money from the agency)
• Better market understanding: with the agency, you will understand the problems faced by your clients, so you can build a plugin that helps them, and then you can sell it to them

However, there are also drawbacks:

• It’s really hard: you’re now wearing 102 hats (2 from agency + 100 from plugin), and you are going to go crazy
• You need separate teams / twice the people
• The plugin is more likely to fail due to a lack of focus

These are Lesley’s takeaways from her switch to running a plugin business.

Pressing for Performance

Henri Helvetica makes the case for using data points to help make well researched decisions along with best practices in order to improve WordPress’s web performance and provide the best user experience possible.

Web performance is not what it used to be 19 years ago, when WordPress was created. It’s a lot more complicated. Web performance is today greatly rely on the Lighthouse score, consisting of 6 metrics:

• First Contentful Paint (FCP): how long it takes the browser to render the first piece of DOM content after a user navigates to your page
• Largest Contentful Paint (LCP): the render time of the largest image or text block visible within the viewport, relative to when the page first started loading
• Time to Interactive (TTI): how long it takes a page to become fully interactive
• Total Blocking Time (TBT): the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses
• Speed Index (SI): how quickly content is visually displayed during page load
• Cumulative Layout Shift (CLS): a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page

Just as important are the core web vitals, a trio of metrics measuring web performance around the user experience (LCP and CLS are the same as above, and FID is a new metric):

• Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
• First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of 100 milliseconds or less.
• Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of 0.1. or less.

Let’s share what is a well-known unsecret: the WordPress performance could use a little work.

Once we have the idea of web performance literacy, that will help us out. Let’s take a look at some web performance data. These are core web vitals across the web:

• LCP: 55.2% <= percentage of sites with good LCP
• FID: 94.9%
• CLS: 71.6%
• Good vitals: 41.2% <= percentage of sites with good LCP, FID and CLS

These are the same measurements concerning WordPress, from year 2021:

• LCP: 28%
• FID: 96%
• CLS: 61%
• Good vitals: 19%

These results from WordPress sites are disappointing, but the good news is that, when measured against the previous year, there were improvements:

• LCP: +4%
• FID: +7.6%
• CLS: +3%
• Good vitals: +4.1%

Paying attention to these numbers, we can analyze what is going on as to fix the problem in our sites. For instance, LCP is associated with images or large blocks of text, so we know where the problem might be. For another example, the median Lighthouse score across the web is 41%. Not a great thing. But the median Lighthouse score for WordPress is 26%! By knowing that two of the metrics, LCP and TBT, each represent 25% of the total Lighthouse score, we can take better decisions on where to look for the problem. This all goes back to the idea of web performance literacy.

Let’s analyze now images. For a good user experience, images are mostly always involved, and mobile images should always be smaller. The median image weight across the web is:

• Desktop: 984 kb
• Mobile: 885 kb
• Difference: 11%

The median image weight across WordPress sites is:

• Desktop: 1165 kb
• Mobile: 1129 kb
• Difference: 3%

The difference is much more narrow, evidencing that there are image management challenges right there. So you can do some investigations on your site, knowing where to search for the problem and try to fix it.

Concerning image formats, 48.5% of the images served by WordPress sites are as lossless, comprising:

• PNG: 30.2%
• GIF: 18.3%

Do you really need almost 50% lossless images? Couldn’t those PNG be replaced with JPGs o a more modern format?

The WordPress core performance team is attempting to transition to WebP images by default, a technology that is almost 12 years-old and is supported by most browsers, including all major ones. Why should it be done? Because with WebP we can get a significantly smaller image payload, without losing quality.

The White House site (built with WordPress, and discussed in WordSesh presentation “Rebuilding WhiteHouse.gov in Six Weeks”) has a Lighthouse score of 49, which is good. It is significantly above the median score for WordPress. However, taking a closer look using WebPageTest we can see that there is a trio of blocking resources, which makes the site get a lower TBT score and, hence, a lower Lighthouse score.

Summary: web performance is investigative work. Literacy is essential. With the tools (Lighthouse, WebPageTest) and knowledge, we can investigate where the performance problems are, and fix them.

Growing Traffic, Growing Problem: How to Prepare for a High Traffic

Tiffany Bridge gives us tips and what we can (and should!) do to prepare for traffic spikes, and how to know if our hosting plan is really “unlimited.”

First the context to the story. Hank is a puppy who needed to find a permanent home, for which Christine created a site called Please Adopt Hank. She was expecting to circulate it around where she lives, but it quickly spiraled out of control, with traffic increasing very rapidly, up by almost 100.000 percent.

But her site was not prepared for this amount of traffic, and it kept going down, even though it was on an “unlimited” plan by the hosting provider. So she’d call her host and ask for help, and all her host would offer was a series of upgrades, each one progressively costing more than the last one, until offering the definitive option: a dedicated server for the site. And all this for a single site attempting to find adoption for a single dog. (Christine would solve the issue by changing hosting providers.)

This situation can happen very unexpectedly. What should you do if you go viral? It doesn’t even have to be viral, it can also be a single hit in the national news that makes your traffic spike tremendously.

There’s basically 3 major categories of things that you should think about in anticipation of a sudden traffic surge:

1. Optimizations that will benefit your site every day, at every level of traffic (lower page weight makes the page load faster)
2. Temporary things you can do while a traffic is happening (but must think about them ahead of time, or you will spend much more money if you do it only when the traffic spike happens)
3. Throw money at the problem (but efficiently!)

First, let’s talk about optimization. The number one thing that you need to do is to run tests to check the performance of your site, using tools such as WebPageTest and Google’s PageSpeed Insights (which are free). These tools will help you find out where the optimizations are needed. The tests must not be applied to the homepage only, but to all key pages, such as product pages or the newsletter sign-up page.

Once you’ve identified the resource hogs, you need to eliminate them. For instance, really big images that are taking a long time to load, or slow-loading JavaScript code must all be dealt with: images can be optimized, a plugin that loads the whole of jQuery just for a single functionality can be removed, and others.

Then, use a CDN and caching to apply whole-site performance. The CDN places the site assets into servers all around the world, so that visitors access the resources from a server located near them, which is much faster. Caching converts dynamic functionality into static, so that instead of executing a connection to the database for each request, it only happens once and the site then serves the cached page, which is also faster.

Next, remove the database killers: those plugins which thrash the database, which are very bad for performance. For instance, a visitors’ stats plugin might write to the database each time a user accesses the site; when your site has thousands of visitors a day it can kill the database and bring the site down. Other examples include: broken link checkers, related posts plugins, and that kind of plugins. It’s not that you can’t have these features, but it’s better to use plugins that offload those features to an external service (like Jetpack does), so your webserver is not bogged down.

In addition, keep your WordPress themes and plugins lean, and up to date. For instance, avoid using themes that include a lot of functionality, because that stuff will possibly be loaded on the client too, or page builders that send a lot of requests, or load plenty of assets into the front-end.

Finally, once you’ve applied your optimizations, and all throughout developing your site (such as after adding a plugin, or making any change), please test, test and test, to make sure your performance is not degrading over time.

Alright, let’s continue. Now you know that some traffic is coming. What should you do if it starts getting out of control?

The first thing is to think about what’s the most important objective for your site (for Hank’s adoption site, this is accepting adoption requests via a form), and handle only that one task while in a massive traffic spike; everything else can be removed, and put back later when back to a normal situation. Which items can be removed, and which not, depend on your own considerations for your own site.

Here are some examples. An image slider on the homepage can be replaced with a static image. Animations can be turned off. Allowing users to add comments can be disabled. Also scheduled maintenance jobs, such as malware scans, can be disabled but don’t do it for long, only a day or two. Same with taking secondary backups of your database if a primary backup system is already in place (eg: by the hosting provider), or if your last backup is a good snapshot (so you’re not losing much data). And disable all plugins that kill the database (if you haven’t done already).

Finally, let’s see how we can help solve these problems with money. Cloudflare is a nice and cheap investment in additional capacity, at 20 dollars a month. And you don’t have to keep it for more than a month (get it before the traffic surge event happens, cancel it right after).

In addition, check your hosting provider to make sure it can withstand the traffic surge. You can do this by asking about how big is the bandwidth in the plan, since having more visitors means that more data will be served from the website (and so a higher bandwidth may be needed), and the number of supported “concurrent users”, which is extrapolated from the number of PHP workers on the server (the lower the number PHP workers, the more requests are queued and the user has to wait).

Also send tickets to your hosting in advance to make sure they can support you with the traffic spike, and ask if your plan can be upgraded right before or during the traffic spike, and then downgraded later; if their support is not good, or you can’t upgrade your plan only while needed, then you’d rather jump ship to a different provider.

How Live Streaming Transformed My Career

Ebonie Butler shares her personal experience as a streamer, the things she’s tried, the lessons she’s learnt, the ways she’s grown, and how we can build on these lessons ourselves.

Ebonie created her own channel on Twitch and had her first ever stream a little over a year ago. She explains what are the benefits from live streaming on her own experience.

Benefit #1: Live streaming improves your ability to explain a problem and your solution.

After discovering that there’s a big programming community in Twitch, Ebonie took it as an opportunity to learn new things (particularly React after the release of Gutenberg) while holding herself accountable to other people. As visitors to her channel would ask her what she was working on, or why she was coding in this or that way, she’d have to talk through her thought process, processing it in real time, and explaining it to the best of her ability. A lot of times, upon hearing herself, she’d realize that the solution would not work, and so she’d try something else. As time went by and people kept asking, she got better and better at communication, she became more and more confident, and the quality of the work she produced as a developer improved.

Benefit #2: Live streaming improves your ability to demo functionality and applications.

As people asked Ebonie what she was working on (whether a chat bot, a music recommender app, or anything else that interests her), whenever possible she would explain it by showing and demonstrating the demo app, and walking the person through various use cases. Repeatedly doing so elevated her skills to demo products, which directly correlates to her professional life as a developer.

Benefit #3: Live streaming improves your documentation skills.

People would stop by her channel, engage her in conversation, get inspired by her work, and ask her to share her GitHub repo with them, so they could look at the code and try it out themselves. After overcoming her insecurities, Ebonie would share her code, but not before documenting it, creating a comprehensive README explaining how to use it, and even identifying and properly describing the edge cases that would be of particular help to other inexperienced developers. By creating this documentation regularly, she continuously got better at it.

Benefit #4: Live streaming makes you a hot commodity in the tech industry.

After a year of live streaming, Ebonie decided to enter the job market again. Surprisingly, many companies started contacting her about a job opportunity. Connecting the dots, she realized that it was because her Twitch channel was serving as a snapshot into the person that she is, her development skills, and what it’s like to work with her. By seeing her personally coding on Twitch, it was easier for these companies to want to hire her, so she got several job offers, all of them offering competitive salaries, and she could get a good job.

In conclusion, Ebonie feels she got elevated thanks to live streaming. Her ability to write technical documentation and explain how an application works improved considerably. More importantly, it also gave her plenty of confidence, as she’d need to explain to others what she was doing and why.

In her own words, after she started live streaming, she discovered “how important it is to put yourself out there while learning something new because you never know what’s going to happen.”

QuickPost: Hacking the Block Editor for Faster Content Creation

Aurooba Ahmed explores how the plugin QuickPost came into service of agencies using WordPress and professional end-users in the small business and non-profit space and covers some high-level technical details on how the plugin works.

The process to create a new post in the WordPress editor requires us to go to the Posts screen to click on the “Create new post” button, so if we’re already on the editor screen editing some post, we need to go back to the Posts screen first, just to be able to create another post.

Given this implicit process, Aurooba noticed that people were experiencing some “pain” when creating content in bulk in the WordPress editor. For instance, a friend of hers would often confuse the editor screen’s “+” button to insert a new block with the button to create a new post. And some people would click on the “Add new post” button as many times as posts they had to create, opening multiple tabs concurrently.

So Aurooba decided to create a simple plugin to make the content production experience better. The result is QuickPost: a plugin that adds a button in the block editor toolbar to create a new post without having to go back to the Posts screen first or get out of fullscreen mode. It also lets us easily duplicate our current post with our basic content intact, which can be useful when we need to create several posts where their content is similar to each other (such as using an Event CPT to create several events for the same festival). Aurooba calls this plugin a “block editor hack”.

Aurooba calls this plugin a “block editor hack”, and this becomes clear during the second part of her presentation, in which she shares the technical details on how she created the plugin (which I’m not including in this blog post). In particular, she explains in detail how she could add the button on the editor toolbar, since this is not supported by the Gutenberg API.

As she is proficient with JavaScript and React (the technologies on which Gutenberg relies), she managed to find a roundabout way to add the button, i.e. a “hack”. It works, but much better would be to have Gutenberg directly support this kind of features. (And indeed, the functionality provided by this plugin should already be part of core too.)

Wrapping up

Featuring wonderful presentations by amazing speakers, WordSesh 2022 was really packed with goodies for everyone working with WordPress. So go check the videos out!