A faster Knowness, with a redesigned AWS setup.
Knowness’s WordPress membership website was slow, especially for signed-in members and staff using the admin area. We traced the problem to its AWS server and configuration, redesigned the hosting setup, and brought page loading times down from 8–10 seconds to 1–2 seconds.
The challenge.
Knowness’s website was hosted on an AWS t3a.xlarge instance that a previous agency had set up. Caching and a content delivery network were already in place, but the WordPress website was still very slow. Pages took 8–10 seconds to load, and the delays were especially frustrating for signed-in members and staff working in WordPress admin. The client came to us to fix it, initially thinking the problem might be a WordPress configuration issue.
What our inspection found.
- We thoroughly reviewed the existing AWS setup and the software running on the server. The problem went beyond WordPress settings: both the server choice and its configuration were a poor fit for this website.
- The t3a.xlarge instance was not well suited to the processing work this BuddyBoss membership site needed. Each signed-in member’s page could require fresh PHP processing and database lookups.
- The existing server used Amazon EBS gp2 storage. As part of the redesign, we chose gp3 storage for the new setup.
- Caching and the content delivery network were already helping with saved pages and website files. They could not fix the underlying server and configuration problems affecting signed-in users and admin tasks.
We reviewed the existing hosting before deciding what to replace and how to configure the new setup.
What we changed.
- Redesigned the AWS architecture and created a compute-optimized Amazon EC2 instance, choosing a server better suited to the website’s processing needs.
- Used Amazon EBS gp3 storage for the new server, replacing the gp2 storage in the old setup. EBS is the storage that holds the server’s data.
- Configured the Linux server, Nginx and PHP to run the WordPress and BuddyBoss website properly. We also set up Redis to reuse frequently needed information and reduce repeated database work.
- Connected an AWS Application Load Balancer in front of the server, so incoming website traffic passed through it before reaching the site.
- Issued the SSL certificate through AWS Certificate Manager and attached it to the load balancer to handle visitors’ secure HTTPS connections.
- Migrated the existing website from the old server to the newly configured AWS setup.
- Configured AWS Backup to back up the new EBS volume, giving the client backups of the server’s storage.
How the new setup worked.
Visitors reached the website through the Application Load Balancer, with the HTTPS certificate managed through AWS Certificate Manager. The load balancer passed requests to the new compute-optimized server, where the website ran on the configured software stack and gp3 storage. Redis helped reduce repeated database work, while AWS Backup protected the EBS volume with storage backups. We built and configured this setup, then moved the client’s website onto it.
From 8–10 seconds to 1–2 seconds.
Pages that had taken 8–10 seconds to load were loading in just 1–2 seconds after the work. The website became much faster for members and easier for staff to use in the admin area. The client was highly satisfied with the improvement and the AWS hosting work we delivered.
Read another case study.
WordPress Performance Optimization
We worked on slow page loading by improving how images, fonts and tracking tools load, along with the hosting and caching settings.
WooCommerce & Server Performance Optimization
We fixed server settings, set up working caching and cleaned up WordPress issues affecting shoppers and staff managing the store.
Have an idea?
Let’s make it work.
Tell us what you want to achieve. We’ll help you find a practical way to get there.
Let’s talk about your project