Each year, seasoned WordPress developers, agency owners, WebPro experts and beginner users come together at WordCamps. From around the world, we connect, learn, and celebrate all things WordPress. WordCamps have grown from the one held by Matt Mullenweg in 2006, San Francisco – to hundreds all over the globe. Each with their own flavour, speakers, sessions, and communities. It’s only natural that we want to get more WordPress Community Insights.
As we create many WordPress-related products, we’re proudly involved in the community that makes WordPress and make regular appearances at WordCamps. We support WordCamps both with sponsorship and by showing up with a booth, speakers, games, special offers, raffles, and interviews. In November 2019, we attended WordCamp US and joined the thousands of other WP enthusiasts and experts. Celebrating and evolving the thriving WordPress ecosystem, hosting educational and engaging games and raffles with special prizes.
In exchange for the grand prize (that any techy would love), we took the opportunity to gather answers to a few burning questions for the WP community. We collated the responses from over one hundred respondents in the infographic you see below. Now we’re going to dive into these findings in a bit more detail and discuss a few patterns and trends we noticed.
Community Insights from WordCamp US 2019
WordPress is such a diverse and flexible platform that it’s used daily by a million different people in a million different ways. To be exact, there’s over 75 million people using WordPress in over 50 different languages. Powering over 172 million websites (around a third of the entire web). And those numbers are still growing.
So who are the WordPress Community?
From our survey of WordCamp attendees, we discovered that, as you would expect, most of them are developers — nearly half at 42%. The rest are a diverse bunch of bloggers, graphic designers, agency owners, marketers, SEOs, freelancers, security researchers, software developers. There are also prospective dev students or small business owners who are newbies to the WordPress world.
As you can see, there’s a real mix of people using WordPress for everything. From personal projects and their own career development to running businesses and supporting client projects. This is reflected in the reasons as to why people were attending WordCamp US.
Most of the respondents were at the event for both personal and professional reasons. With overall the biggest attraction being the opportunity to network, make connections, and simply have interesting conversations with like-minded people.
Of course, some people were there because they were running a session or because they simply wanted the free swag. But even so, they may have been meeting up with someone they met online or were otherwise benefiting from the strong WP community. Similarly, when we asked what they hope to take away from the weekend, respondents mostly mentioned making new friends, contacts and connections.
Other top takeaways included new knowledge/learning, feedback, contributing to the community and learning new solutions for current WP challenges. Many also want to improve accessibility of websites, or get a clearer idea of hosting options and new features out there. And, of course, grab some swag while they’re at it.
How The Community Uses WordPress
When you get a bunch of WP aficionados together in the same place, you can’t not ask them about their experiences with WordPress and the tools they’re currently using. Starting at the top with hosting options, over a third of people (39%) preferred Managed WordPress Hosting, with Cloud and Shared Hosting following at 17%.
In line with these results is what they voted as the most important factors when working with WordPress. Speed and performance took the crown with nearly two-thirds of the vote. While 45% were happy enough to have WordPress work well. However, 44% also wanted stability, and 36% were looking for a user-friendly design.
With over 50,000 plugins available, the WordPress plugins marketplace is booming. Many look to WordCamp for insights into plugins to announce development of their latest ground-breaking product. Maybe even to improve the efficiency of their sites, or simply discover what’s out there.
Interestingly, SEO plugins like Yoast are the most-used WordPress tools, with 55% of respondents using them over others. Second were analytics tools with 37%, security tools at 31%, and page builders, CSS and email marketing plugins coming up the rear.
This shows a clear focus of WP users to quantify and boost their site performance in search engine results pages (SERPs) as much as possible.
Doing Our Bit For The WordPress Community
To finish off the survey, we asked the WordCamp US attendees a few more questions, including if they had any WP-related goals, and if so, what they were. The results revealed that WordCamps have a feel of being about socialising and educating people. However, they’re also pivotal for those serious about pushing their business goals forward.
Some of the respondents’ top WordPress-related goals were:
making their products known to the world
growing their WordPress client base
becoming web developers
blogging more consistently
building non-profit websites
Building awesome sites in general
teaching more
Increasing their traffic and scaling
Getting all the clients and dominating the world
To help fellow members of the WordPress community to achieve these goals, we’ve built a variety of WordPress tools like the Plesk WordPress Toolkit. The WP Toolkit is a single interface for easily installing, configuring, and managing WordPress, jam-packed with features.
We asked the community if they thought the Plesk Toolkit would benefit their work. Nearly half of respondents chose “yes”, with just under a quarter choosing “I think so.” A few of the things that are holding people back included the price. Some were also not sure if it would integrate well. And a few would not go for it, simply because they don’t like change.
Looking Ahead to The Next WordCamp
Go for the speakers, the opportunities, the insights, the lego prizes, swag – or all of the above. Attending a WordCamp is a great way to meet awesome people and stay in touch with everything WordPress.
There has been over 700 WordCamps in 70 cities around the world to date. We plan to attend more in 2020 to continue supporting the WP community and development of the incredible open source platform. Starting with WordCamp Asia in February. To find a WordCamp near you, or even set up your own, visit WordCamp central.
Will you be attending WordCamp Asia in February 2020? What content would you like to see us cover from the event?
There’s nothing wrong with the need for speed in coding. However, if you lack coding standards, your products will become fragile and liable to break down in the future.
As a developer and hopeful future contributor to the WP Core, I question what lies on the road ahead. So I sat for Felix Arntz’ talk at WordCamp London on how to sustain long-term contributions. Since joining his first core-contribution table at WordCamp Europe – Seville in 2015, he’s gained a lot of knowledge (and frustrations).
#Tip 1 – Hold your horses
He first talked about the headaches of reporting bugs and creating tickets when in this zone. That even though you’d want to go ahead and immediately patch – you still need to discuss first. This is not a solo project. You need to learn the philosophies of the circle you’re part of and make them part of your mindset.
Always place the project’s goals ahead of your own ego. It’s worth allowing others to try to convince you. In the same way that you should feel free to convince others when necessary. If you disagree initially – step away, think about it further, and come back later.
#Tip 2 – Sometimes you’re wrong
Understand that rejection’s part of the whole process. Your ideas Will not always be accepted by the group – and that’s OK! Here’s how Felix suggests you deal with that rejection.
If someone gives no good reason for saying no, ask for one explicitly.
Disagree? Then dig further. Ask for a third and fourth opinion.
Still disagree? Then, your thoughts may not comply with the project’s philosophies.
Always keep your calm and be polite. Don’t take anything personally.
#Tip 3 – Get your answers
Felix shared how when he joined Multisite in 2016, he struggled a bit with unanswered questions. He would say be persistent when you don’t receive an answer for a while. Your question is valid and deserves an answer too. But I think that it’s often up to you to chase your own answers. One way or another.
#Tip 4 – Find your focus.
First, you need to find out what interests you the most, before you can start placing your focus towards it. Then you’ll know which meetings you can participate regularly in for that component.
I may not like to sit back myself – I tend to dive right in and participate. Always keeping in mind that direct communication Works best. But Felix says it’s perfectly OK to just pop in with a hello at first and hang around a bit, seeing how it’s done. And the more you show up, learn and present ideas, the more you build trust over time.
#Tip 5 – It ain’t just code.
You’re not just gonna be sitting there coding the stuff all day, by your lonesome. Be open to new tasks. And when you accept them, document changes precisely so that others can follow. Or even recap so your colleagues can stay up to date.
Write precise ticket descriptions and commit messages. You may be the one interested in the core, but you’ll still need to collaborate with other teams, like design and accessibility.
Want to become a component maintainer? Once you’re more familiar with your component, start providing responses to new tickets. And make new contributors feel welcome.
#Tip 5 – Learn and repeat
You don’t need to be a coding virtuoso to land an important role in the core. All you need to do is keep contributing, learn from mistakes and never stop improving your skillset over time.
Why is this important?
Well, we advise that you pay attention to details. But keep in mind that even a small change might break something in another location. So write tests to verify functionality and integrity. Don’t break any through a commit. And always make sure your code is reviewed by other experts in the respective area.
#Tip 6 – Be time-aware
You need to be reasonable with the time you have to things. Don’t overestimate what you can do within those core-dedicated hours. Moreover, don’t get involved with too many components. Just stay focused on those select few, so you can make a real difference.
Wanna increase your core time?
Then know that making an impact on core development will spark your fellow coder’s attention. Already got a lot on your plate with the company employing you 9-5? Bring up your aspirations with your boss.
Many companies will be more than happy to grant their developers extra time to work on extra projects that grow their skillset. Also works if it’s time for a change. Because prospective companies may become interested in sponsoring you. So my advice would be to take a chance. You never know!
Is your website experiencing heavy traffic? Are you looking for a solution that will reduce server load and will improve website speed? Varnish might just be what you need. Varnish listens for duplicate requests and provides a cached version of your website pages, mediating between your users’ requests and your server.
So how do you activate Varnish? In this article, I will show you how you can easily increase your website speed by using Varnish as a one click Docker container. I will demonstrate how using a website caching solution like Varnish can easily improve both page response times and the maximum number of concurrent visitors on your website. To simulate real traffic and measure correct response times, I have used an external server similar to blitz.io, stormforger.com or loadstorm.com to generate lots of traffic and concurrent users to our site.
What is Varnish and why should you use it?
Varnish HTTP Cache is a software that helps reduce the load on your server by caching the output of the request into the virtual memory. It is a so-called HTTP accelerator and is focused on HTTP only. Varnish is open source and is used by high traffic websites such as Wikipedia.
If you have lots of daily visitors, we recommend using a cache mechanism. You’ll see your response time improving significantly because the server can send the already cached data, directly from the memory, back to the client, without the resource consuming process handling on the web server. Additionally, it reduces the load on the CPU so that the server is able to handle many more requests without getting overloaded. I will demonstrate this in the stress tests later.
Running Varnish in a Docker container
Docker is a great open source project that makes it incredibly simple to add Varnish to a running server. We don’t need to install Varnish on the production server, we simply use a ready-to-go Varnish Docker image. The main advantage is that if something goes wrong with the container, we can simply remove it and spin-up a new container within seconds. The way in which Docker containers are designed guarantees that Varnish will always run independently of our system environment. Do you want to know more about Docker containers? Read more about the 6 essentials on Docker containers!
For this tutorial, I will use the newly integrated Docker support on Plesk to activate Varnish. The Plesk interface makes it easy to get a Varnish instance running, only requiring small modifications of the Varnish configuration file to be done using the terminal.
A further improvement would be to rebuild the Varnish Docker image so that it takes our configuration as a parameter from the Plesk UI. For now, I’ll stick to the original Docker image and upload our configuration via shell.
Activate Varnish in Plesk and test on a static page
Okay, let’s try it first on the default static page of Plesk. In the default settings, Plesk uses Nginx as a reverse proxy server for Apache. This means that Nginx is listening to default port 80(443 for HTTPS) and Apache to an internal port (7080 HTTP, 7081 HTTPS) We will push our Varnish container in between of the two web servers. In this scenario, Varnish will get the request from Nginx and the content from Apache. Don’t worry, it’s easier than it sounds!
Go to Docker and search for the image million12/varnish in the Docker Image Catalog. Once found, click “run” and Plesk will download the image to your local machine. After the download, click “run (local)”, which will open the configuration page of the container. The only thing that we’ll change is the port mapping.
Varnish in Docker container on Plesk Onyx – Port mapping
Remove the tick at the option “Automatic port mapping” and set an external port (I will use port 32780 in this tutorial) for the option “Manual mapping”. This means that port 80 of the container is mapped to the external port 32780. By adding a proxy rule we can “talk” to the container through this external port. We will set the backend server in Varnish to the Apache port from where the data will be gathered if a “cache miss” occurred.
Test Varnish with a static page
Create a subdomain for testing our Varnish integration on a static page. After the subdomain was created, go to the “Hosting Settings” and deactivate the options “SSL/TLS support” and “Permanent SEO-safe 301 redirect from HTTP to HTTPS” because we want to test the Varnish functionality over HTTP first. Okay, but how do we redirect the requests to the Varnish container? This can be done easily with the option Docker Proxy Rules that you will find in the domain overview.
Varnish – Proxy rules for Docker container on Plesk Onyx
Click on “Add Rule” and select the previously created container and the port mapping that we entered manually. If you cannot make a selection, then your container is not running. In this case you should click on Docker in the menu and start the container first. If you open the subdomain after you’ve activated the proxy rule, you will see the error Error 503 Backend fetch failed. Don’t panic, this is an expected behavior. We did not configure the Varnish backend server yet!
Varnish – Error 503 Backend fetch failed
Configure Varnish properly in the Docker container using SSH
This is the only time when we need to access the server and the Varnish Docker container via SSH. Open your terminal and type
$ ssh [email protected] // Replace with your user name and correct IP address
Enter your password if required to get access to the server. Tip: use a private / public key pair to improve the security of your server!
First of all, we need to find out the ID of our Docker container. To list all active container type into the command line
$ docker ps
Varnish – Running Docker containers – Plesk Onyx
Copy the Docker ID and use the following command to access the Docker container
$ docker exec -it ID bash // Replace ID with the correct container ID
Okay, the most important thing to do is change the host and port value for the default backend server in the file. /etc/varnish/default.vcl
For .host we will enter the IP address of the server where Plesk is executed (in our example 111.222.333.444) and for .port 7080. As mentioned before, this is the default Apache HTTP port in Plesk. We have to use this port because, internally ,Varnish can only speak over an unencrypted channel!
Tip: Do we have a cache hit or miss?
How do we see that the content was loaded from the memory and not from the Apache server? You will see that the request was processed by Varnish through a special header entry in the response, you will not know whether the data was loaded from the memory or was requested from the Apache server.
To achieve it without having to use varnishlog in the console, we can set another header value with the corresponding value (cache hit / cache miss). We have to use the function sub vcl_deliver that is the last exit point for almost all code paths (except vcl_pipe). Add the following code within the curly brackets of the function sub vcl_deliver
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT";
} else {
set resp.http.X-Cache = "MISS";
}
Use the Developer Tools in your browser to examine the response
Save the modified file and exit the container. Switch to your Plesk UI again and restart the container in Docker with the “Restart” button. When you see the success message, go to the tab of the subdomain with the 503 error message. Do not reload the page yet but open the Developer Tools first (alt + cmd + i on a MacBook). Go to the “Network” tab and reload the page. Select the first entry (URL /) and take a closer look at the “Response headers”.
Varnish – Cache Miss
If everything was done properly, you will see some new header variables:
X-Cache – This is the variable that I’ve defined in the configuration file. After the first reload it should display a “MISS”. X-Varnish: ID – The internal ID for this file in Varnish {more information required} Via: "1.1 varnish-v4" – This shows that the request was redirected through the Varnish container.
Okay, it’s about time to see some Varnish magic! Click on the reload button in your browser to reload the page. This time it will be loaded from the virtual memory.
Varnish – Cache Hit
What about websites that are using HTTPS to encrypt the connection?
It also works and the best part of it is that you don’t have to change anything! Create an SSL certificate for the subdomain using the great Let’s encrypt extension. After the certificate was created and assigned (the extension does it automatically), go the the static page and reload it using https:// instead of http:// If you open your browser console, you will see a X-Cache: HIT in the response headers:
Activate Varnish caching on your WordPress website
We just saw that it’s technically possible to activate Varnish inside a Docker container with Plesk. Now let’s try it on a WordPress website!
The main difference is the configuration of the VLC configuration file within the Varnish container. WordPress is a dynamic CMS, thus we cannot cache everything without restricting the functionality of the system; the administration pages shouldn’t be cached since changes wouldn’t be possible any more for logged in users.
There are many pre-defined configuration files for WordPress available on the internet, from various developers. In most cases, you can use them right away without any modifications. For our test integration, we will take the configuration file created by HTPC Guides (with small adjustments – link below).
For this article and for the stress tests I’ve created a fully workable website with WordPress. I want to test under real conditions and not with a default WordPress installation. The website should also be secured with an SSL certificate and only callable over HTTPS. For this reason, I will also activate an SSL certificate with the help of the Let’s Encrypt extension for this installation.
Use a WordPress Plugin to activate support for HTTPS
Important: Do not use the option “Permanent SEO-safe 301 redirect from HTTP to HTTPS” within Plesk in “Hosting Settings” because this will lead to a redirect loop in our special environment constellation. Instead I will use a WordPress plugin to switch our installation completely to HTTPS. The name of the plugin is Really Simple SSL and can be downloaded from the official plugin repository.
Please make the same preparations like for the static page but add this time the additional required configuration data for WordPress to the default.vcl configuration file inside the Docker container. I’ve used the this Varnish configuration file (GitHub Gist) for my test installation. Don’t forget to adjust the backend server again like we already did for the static page!
Tip: Do not forget to restart the Docker container from the Plesk UI to reload the configuration information. If you forget to restart the container, then Varnish will not work properly with the WordPress website.
Now reload the front page of WordPress with the browser console open. The first loading process should throw an X-Cache: MISS but the second (and following) reloads will return an X-Cache: HIT.
Varnish in WordPress – Cache Hit
Let’s run some stress tests with Blitz.io!
We’ve seen that Varnish helps to improve the performance of the website. What is with the promised load reduction on the CPU? I can test it with the so-called stress testing which will load the website with many concurrent users per second for a certain time span. Without any security and overload protection, the server will start to respond steadily slower until the requests cannot be handled any more completely. With activated Varnish the server will be able to serve such intensive requests longer without throwing errors.
All right, it’s time to run load and performance tests with the external service provider Blitz.io.
Note: I used a very small server for this test instance (only 1 CPU and 500MB Memory), so the positive impact of Varnish should be much higher on a more powerful server!
Result WITHOUT Varnish:
Stress test – WordPress without Varnish
As you can see, I had to abort the stress test because the server already couldn’t handle the request after less than 5 seconds and less than 50 concurrent users. After just 15 seconds the server collapsed completely and no requests could be managed any more!
Result WITH Varnish:
Stress test – WordPress with Varnish
Varnish magic! As you can see, the Varnish cache allows us to keep the server stable even under heavy load. The small test server handled over 300 concurrent users and responded all requests over 30 seconds without any errors. After 30 seconds and over 300 concurrent users the server was overloaded and couldn’t accept further requests. With a more powerful server the numbers should be much higher! So, it’s also great to keep your website reactively if it suffers a DDoS attack, at least for a certain number of requests.
Summary: Varnish for WordPress within a Docker container on Plesk
Let me make a small checklist:
Varnish in Docker container? Yes.
Varnish in WordPress? Yes.
Varnish in Plesk? Yes.
Varnish for WordPress within Docker container in Plesk? Absolutely, yes!
Mission accomplished! 🙂
As you’ve seen, Varnish can greatly improve the performance of your WordPress website and reduce the CPU-load of your server. It’s relatively easy to setup a working environment using Varnish in a Docker container between Nginx and Apache within Plesk. The most important part is the correct configuration of Varnish for your specific CMS.
Thank you for reading. In the next blog post, I will take a look into another memory caching system, Memcached.
