This article shows non-technical and technical users how to create a high-performance yet featureful website with WordPress at a low cost. You will learn about the software development concepts and implementation I used to load the static pages of my WordPress website — which uses 40 plugins — in ~1 second.
My Website Development Journey
My website development journey started seven years ago (at 15 years old). I created a website to sell hip-hop beats to artists online. At that time, my programming experience was limited to AutoHotKey macros for various tasks (but not Runescape).
So what did I use to create the website?
Some developers may sneer at the name, but this article serves as proof that — in the right hands — WordPress is nothing to be ashamed of.
I’d continue to learn about software development through programming classes and robotics. However, this was not enough to show me how websites worked. So I kept using WordPress as I gained more software development knowledge.
I continued to update my website throughout significant periods in my life:
When I created SwitchUpCB (2017).
When I entered college for Computer Science (2019).
When I dropped out due to financial issues, followed by Yung Quant’s minor successes (2021).
And when I ran away from home (2023).
The main issue with WordPress is that many people who use it do not understand how websites work or how to optimize them. So when you have a problem, what happens?
You ask Reddit to receive several solutions that might solve your problem. But it might not...
You ask professors to receive information about data structures, algorithms, Big O notation, NP-complete problems, and more. Yet this doesn’t change the fact that most professors cannot build a modern website.
You ask employed engineers with $100,000 salaries to receive information without regard to your time or budget. You don’t have $500 per year to spend on a website. Not to mention that modern engineers typically focus on one aspect of web development.
So while a lot of information is out there, much of it lacks the context you need to build a fast yet functional website at a low cost.
I'm writing this article to show non-technical users how to develop a high-performance website with WordPress. However, it also covers concepts non-WordPress web developers must consider while developing their own solutions.
Basic Computer Terminology
You use a computer (server) to run applications (programs) that manipulate files (data).
Knowledge of these concepts are required to understand the next section, so here is a review.
A computer is a machine that performs computations, which are mathematical calculations. In other words, a computer is an automated version of a mathematician. It starts with a switch…
There are multiple words used to describe the concept of a digital computer on the internet:
Smart Phone: A handheld device that uses a computer to run various applications.
Laptop: A portable device with an attached monitor that uses a computer to run various applications.
Server: A computer whose sole purpose is to run a program that serves webpages.
Virtual Machine (VM): A digital version of a physical computer.
Virtual Private Server (VPS): A digital version of a physical computer (with marketing implications).
Cloud: A server or service that serves physical or digital computer resources (using virtual or physical machines).
While these terms can be confusing, each refers to a computer that functions similarly to the one you use to access this webpage.
The digital computer itself solely performs math (using 1s and 0s). However, humans cannot productively work with 1s and 0s. So we created programming languages to help us translate commands into 1s and 0s, and compile those commands in a type of file called an executable.
There are multiple words used to describe the concept of an executable on the internet:
Binary: File that contains machine code for a computer to execute.
Application: File or package of files that performs a specific task.
Program: File or package of files that performs a specific task.
Process: Uh… You get the point.
This article uses the term application, so here are examples:
Web Browser (i.e Chrome, Firefox) [Client]
Web Server (i.e Apache, NGINX, LiteSpeed) [Server]
Database (i.e MySQL, PSQL)
These applications are developed using programming languages by software developers.
Humans use applications to perform specific tasks and manage information: This data is stored on the computer as 1s and 0s in files, which are defined by their file extensions.
Here are examples of file extensions:
.txt (text file)
.jpg, .png (image file)
.zip, .gz (compressed file)
.html (Hypertext Markup Language file for webpage structure)
.css (Cascading Style Sheet file for webpage stylization)
So on and so forth.
In the context of this article, computers run web browser client or web page server applications that handle various webpage files: People refer to the collection of these files (i.e., .html, .css, .js) as a web page.
The Website Architecture
Job interviews in the software industry focus on solving algorithmic programming problems. However, achieving a fast website comes down to The Website's Architecture.
The performance gains from configuring your WordPress installation are limited. So while uninstalling an unwieldy plugin may help your website speed, you must eventually look beyond the installation.
What can you do?
Software Engineers have been working on these issues for a long time. The problem is that the application eventually becomes limited by the computer it runs on. The solution is to develop a software application that communicates across multiple computers.
When a website user requests a webpage from a web server, the user’s web browser requests the IP address of the web server from a Domain Name Server (DNS). Then, the web browser sends a request to the web server for the webpage.
When the web server receives the request, it sends the webpage files to the user’s web browser (also called the client). Then, the web browser parses the files and loads the webpage.
A WordPress Server works the same way, but instead of having the web server (e.g., LiteSpeed) send files instantly, a WordPress PHP script must generate them. This webpage generation might involve a round-trip request to the database for data. Then, the web server delivers the generated files to the web browser.
And this webpage generation is useful when the content of your webpage can change depending on a condition (such as the user being logged in).
So a single WordPress server is limited in speed by its PHP processing times. In other words, speeding up a WordPress website requires you to improve the PHP script processing times, right?
Multiple Server WordPress
Suppose that you hosted a copy of the first WordPress server on another server (computer). Then, you directed the website user to the server with the least usage on each request. This configuration would let you handle 400 requests per second without any other changes!
How would you implement this configuration?
You would use another server (computer) with an application called a load balancer that balances the website load by redirecting incoming requests to the WordPress server with the least usage.
Unfortunately, this exact implementation is not practical for scaling a WordPress website.
You cannot spend $800 per month for another 30-core server whenever you want to handle 200 more requests per second. Not to mention the complexity of replicating your database across each instance. So instead, you must determine how to reduce the processing time of the PHP script that handles each request.
Avoid PHP Scripts
If you generate the webpage before the website user requests it, you can serve it directly from your web server. This strategy lets you serve as many webpages as your web server can handle: That's tens of thousands of requests per second!
This strategy is known as caching.
When you cache a webpage on your web server, the webpage is instantly served upon request: This avoids the execution of a PHP script. However, caching has limitations.
First, this operation implies that the webpage's HTML, JS, and CSS files will not change once cached. Otherwise, you risk serving an outdated page to the website user!
Caching also doesn't avoid network bandwidth constraints: Your server must upload files over the network to deliver files to the website user, but the network's speed can prevent this from happening quickly.
If the bandwidth of your non-shared server's network is 200 Mbps, you can send 25 MB of file data per second. So if each webpage you send is 1 MB, you can deliver 25 requests per second.
This factor is why optimizing each webpage's file size (minifiers, compression, etc.) is essential but not the end-all-be-all of performance.
Internet data is delivered using physical cables that transfer electricity. That's because computers use electricity for their micro transistor switches, which represent 1s and 0s.
The time it takes to send data depends on the distance from the website user to your web server: This time is known as network latency and is why it takes a long time to load a single server website hosted in Europe from the U.S.
Content Delivery Networks (CDNs) were created to solve this problem by serving content close to the website user. These services host many web servers containing copies of web content, then send website users the web content from the closest server to the user.
Using a CDN speeds up your website because it combines caching and multiple-server hosting to minimize network latency.
Multiple Servers: The CDN hosts several web server applications on each computer across the globe.
Caching: The CDN serves each page from a web server's cache.
Latency: The website user is routed to the nearest web server when the CDN has cached the webpage.
So more webpages are delivered per second across the globe.
A pull-oriented CDN caches a webpage when a website user requests it. When the CDN has not cached the page, the website user is routed to the original web server.
This method ensures that high-usage webpages are cached and prevents unused webpages from taking up valuable storage space. However, this method also provides uncertainty about the cache status of your webpage.
One solution is to use a web crawler that requests all of the website’s static pages when the cache is purged: This will load each webpage back onto the CDN.
The main problem with using a pull-oriented CDN is that it only caches your webpage when it has been visited. So the first user to request a unique webpage from your website is always routed to your origin server, which takes longer to load.
God forbid you must purge the entire cache of your website… Like when you update a plugin which contains new CSS.
A push-oriented CDN expects the origin server to push content to the CDN’s web servers. When the webpage is cached, it’s delivered to the website user from the CDN. When the CDN has not cached the page, the website user is routed to the original web server.
This method ensures that your webpage is always performant. It also turns your website into a staging environment, which lets you make any changes and push them later. If your web server goes down, the website can still be served from the CDN.
The problem with a push-oriented CDN is that certain websites contain webpages that are difficult to route the respective URL to the respective webpage file: You may have to configure a cache vary(with edge functions) on the CDN, which is complex and time-consuming.
Traditional Content Delivery Networks concern themselves with delivering static “unchanging” file content. This definition typically refers to media (e.g., css, images), but most CDNs also let you cache HTML files.
HTML files are considered dynamic content because you will likely update the webpage's structure. So caching the HTML file could serve outdated content or, in the worst case, require you to change your webpage URL (when the browser cache is misused).
With that said, some CDNs specialize in caching the HTML of WordPress websites.
A webpage that is 100% dynamic must be generated upon each request. There are three approaches to serving a dynamic webpage in WordPress:
Serve the webpage using WordPress PHP server-side scripts. This implementation is the default behavior of WordPress.
Serve the file using WordPress PHP server-side scripts that request data from other servers. Instead of the WordPress server processing data, it fetches it from another service via an API.
Serve a cached webpage that makes a client-side request (from the user’s web browser) to fetch data from other servers.
Approaches 1 and 2 require the website user to be routed to an origin server that generates the webpage (using a script or template), then sends it to the website user. Since the origin server must be used, the dynamic webpage will not benefit from the CDN.
So your static pages will be fast, while your dynamic pages could be much slower.
Approaches 2 and 3 involve the usage of service architectures: This lets you develop a service in a faster programming language (such as Go) and use it in your WordPress website.
Approach 3 serves the webpage from a cache, then fetches its custom data from the user's machine. So this approach lets you use a CDN to serve your dynamic webpage.
So your dynamic page will be served quickly, but this approach has some limitations.
Here is the actual setup I use to load the static pages of my WordPress website — which uses 40 plugins — in ~1 second.
Disclosure: This section contains affiliate links which may earn a commission for purchases made at no additional cost to you. Thanks for helping me provide you with useful information.
Before you set up a website, you must purchase a domain name from a domain name registrar. This domain is a human-identifiable address that people will use to visit your website.
Cloudflare's Domain Name Servers are the fastest DNS servers on the planet (benchmark). In addition, many machines use 18.104.22.168 (Cloudflare) to resolve their DNS hostname. So setting your Domain Name Servers to a fast DNS resolver will lower your website's Time To First Byte (TTFB).
Content Delivery Network (CDN)
Cloudflare also functions as a CDN and provides DDoS protection, so you can use it for this functionality. However, I use a WordPress (LiteSpeed Web Server) oriented CDN called QUIC.cloud to implement dynamic content caching at the CDN level.
You must use a LiteSpeed Web Server to take advantage of this feature.
Web Server (Hosting)
VeeroTech is the Web Server Hosting Provider I use to host my WordPress Server: This provider has yet to fail me after three years of service and also contains extremely competitive shared and reseller hosting (with an NVMe SSD and 2 GB RAM minimum).
Here are additional features that come with a VeeroTech Subscription:
A Customer Support team that solves every technical issue within minutes.
cPanel Dashboard or Managed WordPress
File Manager, phpMyAdmin, RAID Backups
LiteSpeed Web Server (Brotli Compression) Support
Object Caching (Redis) Support
PHP Caching (OPcache) Support
PHP 8.2 - 4.4
SSL Configuration (TLS 1.3)
Node.js Application Setup
Python Application Setup
MySQL, MariaDB Database
*Allows the installation of hundreds of other useful software such as Drupal, Joomla, NextCloud, OwnCloud, Mautic, osTicket, EspoCRM, SuiteCRM, phpBB, MediaWiki, etc.
VeeroTech supports the LiteSpeed Web Server, which grants me the QUIC.cloud CDN LiteSpeed Enterprise free tier. So if you are planning to use QUIC.cloud, I recommend this web host provider.
You might prefer using a dedicated virtual machine to manage your own installation, backups, etc. If this is the case, DigitalOcean Droplets are simple, scalable virtual machines: You can use this referral link for $200 in credit over 60 days: https://switchupcb.com/r/digitalocean.
Application (WordPress Instance)
WordPress is a PHP application that uses a MySQL database. However, it’s recommended to swap the MySQL database with a MariaDB database that uses the InnoDB engine (with allocated memory) and has query caching disabled. You should use Redis to set up Persistent Object Caching for database queries.
I use the latest PHP version that my plugins support with the LSAPI PHP Handler, OPCache (caches PHP scripts into bytecode), and PHP Workers (concurrent request handlers). The memory limit is set to the maximum amount of memory I will let an individual worker consume.
The LiteSpeed Web Server uses Brotli compression on served HTML Files: This compression algorithm substantially lowers the size of the webpage the website user receives.
The LiteSpeed Web Server also comes with the LSCache WordPress plugin you can use to configure HTML, JS, CSS, and Image caching. So at this point, the following caches are enabled:
Edge Cache (Minimize Latency): CDN
Full Page Cache (Dynamic Content): CDN
Object Cache (Database Queries): Redis
Fragment Cache (ESI, Templating): Disabled
Browser Cache: 52 Weeks (with exceptions)
The webpage builder I use to design my website's frontend disables the WordPress theme system, which carries lots of unnecessary HTML, JS, and CSS content. I also use the Asset CleanUp plugin to further optimize pages by removing unnecessary CSS and JS scripts from individual pages.
There are a few techniques you can use to optimize your images.
Properly size images using the adaptive images technique to serve resized images to your visitor’s screen size upon each request.
Serve images in next-gen formats by serving images in the WebP and AVIF formats.
I use a specialized CDN called ShortPixel Adaptive Images to serve compressed, adaptive images (in next-gen formats) from the edge. This service provides the benefits of a CDN (in caching and minimizing latency) while also serving compressed adaptive images. You can purchase credits or a subscription for these benefits using this link: https://switchupcb.com/a/shortpixel.
You can optimize your website's fonts by hosting local woff2 files.
The Web Browser Cache is a cache that is stored on the website user’s computer. This cache lets the user save time by fetching a resource (file) from the user’s file system rather than requiring an additional network request.
Unlike the other caches listed, you have limited control over the state of this cache.
The Browser Cache Time To Live (TTL) is how long a website user’s browser will cache a resource. So when you set this value to 52 weeks, the user will not make a new request to your server for the given resource for a year (unless the cache is cleared manually).
This behavior can be worked around using a technique called cache busting.
You shouldn’t use the browser cache to cache HTML files because of the implications: When a user visits your website, the HTML file will be stored in their browser cache. So when you update the HTML file, the user won’t fetch it unless the cache is cleared.
This behavior is problematic because cache-busting techniques are impractical for URLs of HTML files that don’t use query strings (i.e., frontpage). So when you plan to upload a browser-cached resource, make sure you can bust it in the cache.
Webpage Speed Comparison
How does this webpage speed compare to other websites?
When it comes to website performance, Google sets the standard: “Two seconds is the threshold for eCommerce website acceptability. We aim for under a half second.”
GitHub is an internet hosting service for software development and version control. How fast does this Microsoft subsidiary’s developer-oriented frontpage load?
To be fair, its other webpages load much faster.
Let’s see how fast Reddit, the “Front Page of the Internet” and the 6th most popular website in the world, loads.
There are a few more ways to speed up your site, but I have yet to implement them. You can subscribe to my email newsletter to get notified.