The Fastest WordPress Optimization Setup: KUSANAGI + Cloudflare Achieves an 82% Improvement in TTFB in Real-World Tests

WordPress is the world’s most widely used CMS, but “slowness” has been a long-standing issue. There are many commonly recommended methods for speeding it up, such as image optimization and installing caching plugins. However, the reality is that adding more plugins increases the risk of conflicts and rarely leads to fundamental speed improvements.

In this article, I’ll introduce a configuration that combines Cloudflare proxy to achieve speeds even faster than VPS + KUSANAGI. I conducted 13 benchmark tests over 12 hours on a KUSANAGI environment running on the Xserver VPS 4GB plan and presented the numerical differences between using Cloudflare and not using it.

To summarize the results, the median TTFB for desktop improved by 82.89%. This significant improvement was achieved without any plugins, relying solely on server and CDN configurations. For those serious about optimizing performance, I’ve organized specific steps and concepts into three layers: the server layer, the CDN layer, and the frontend layer.

The Big Picture of WordPress Speed Optimization and the Three-Layer Structure

WordPress loading speed does not change dramatically with a single measure. Factors affecting speed are broadly divided into three layers, and appropriate measures must be taken for each.

Server Layer (Origin Server)

WordPress processing occurs on the server. Specifically, a web server like Nginx receives requests, PHP processes the WordPress code, retrieves data from MySQL, and generates HTML. The time taken for this sequence of processes directly affects users as TTFB (Time to First Byte).

To speed up the server layer, effective measures include selecting a high-performance VPS, optimizing Nginx settings, tuning PHP-FPM, optimizing MySQL, and implementing server-side caching. KUSANAGI provides all of these pre-tuned.

CDN Layer (Cloudflare)

A CDN (Content Delivery Network) is a system that caches content on edge servers around the world and delivers it from the location closest to the user. In addition to this role, Cloudflare provides a comprehensive suite of features, including a WAF (Web Application Firewall), DDoS protection, and HTTP/3 support.

No matter how much tuning is done at the server layer, latency caused by the physical distance between the user and the server cannot be avoided. By incorporating a CDN layer, this distance issue can be resolved.

Front-end Layer (Browser-Side Optimization)

This refers to what happens after the HTML reaches the browser. It includes image optimization (WebP/AVIF conversion, lazy loading), CSS/JavaScript minification and lazy loading, web font optimization, and removing unnecessary plugins.

Many “WordPress speed optimization” articles focus solely on this layer, but no matter how much effort you put into this alone, there is a limit if the server response is slow. The correct order for speed optimization is to start with the upstream layers (server layer and CDN layer) and work your way down.

How KUSANAGI Speeds Up WordPress

KUSANAGI is an ultra-high-speed CMS runtime environment developed by GMO Prime Strategy. It is deployed as an OS image on a VPS and includes pre-configured settings for Nginx, PHP, and MariaDB/MySQL that are optimized specifically for WordPress.

Two-Tier Caching with bcache and fcache

KUSANAGI provides two types of page caching: fcache and bcache.

• fcache: This cache utilizes Nginx’s FastCGI cache. It stores dynamically generated pages at the Nginx level and returns the cached page for subsequent requests without executing PHP. Since it completely skips PHP processing, this cache offers the greatest reduction in TTFB.
• bcache: This cache utilizes WordPress’s built-in caching mechanism. Like fcache, it stores and reuses pre-generated pages, but it runs via PHP and stores data in the database. Since it involves PHP processing, it is slightly slower than fcache, but it allows for more granular cache control.

Generally, enabling fcache is sufficient. It is recommended to use bcache in conjunction with fcache for cases that fcache cannot handle (such as switching views for logged-in users). Note that the cache targets HTML pages dynamically generated by PHP; static content such as images, CSS, and JavaScript is not cached.

Optimized Nginx + PHP-FPM Configuration

In KUSANAGI, the number of Nginx worker processes and PHP-FPM processes is pre-tuned to match the VPS specifications. OPCache (PHP intermediate code cache) is also enabled, minimizing PHP processing overhead.

Compared to WordPress on a shared server, it is not uncommon for processing times to be several to dozens of times faster in KUSANAGI’s VPS environment. In benchmarks conducted by the author in the past, the external TTFB ranged from 0.162 to 0.367 seconds on a shared server, whereas the VPS (KUSANAGI environment) recorded results of 0.103 to 0.158 seconds.

HTTP/2 Support and High-Speed SSL Processing

KUSANAGI natively supports HTTP/2, and SSL/TLS processing is optimized. Integrating Let’s Encrypt certificates can be completed with a single command. SSL implementation is beneficial for SEO, and HTTP/2 multiplexing allows page components to be fetched in parallel, leading to improved perceived speed.

Benefits of the Cloudflare Proxy

While KUSANAGI alone is sufficient for building a fast WordPress environment, enabling the Cloudflare proxy (the orange cloud icon) provides additional benefits in several areas.

Improved Loading Speed Through Caching

Cloudflare maintains edge servers in over 300 data centers worldwide. Static assets (CSS, JavaScript, images, etc.) are cached at the edge and delivered directly from the location closest to the user.

This increases the number of requests that are completed without reaching the origin server, significantly reducing TTFB. Specifically, for PageSpeed Insights’ desktop TTFB, we observed an 82.89% improvement in actual measurements, as detailed below.

Reduced Server Load

If you are using a VPS plan with limited memory (2GB–4GB), memory can become strained by bot crawling and scanning. In particular, brute-force attacks targeting wp-login.php and xmlrpc.php waste CPU and memory resources.

By routing traffic through Cloudflare’s proxy, many of these requests are blocked or cached at the edge, reducing the number of requests reaching the origin server. As a result, more resources are available to serve legitimate visitors.

Enhanced Security

Simply enabling Cloudflare’s proxy mode activates the following security features:

• DDoS Protection: Absorbs attacks involving large volumes of requests at the edge
• WAF (Web Application Firewall): Blocks attack patterns such as SQL injection and XSS
• Bot Management: Detects malicious bots and restricts their access
• IP Address Obfuscation: Prevents your server’s real IP address from being exposed to the outside world

Furthermore, by using Cloudflare’s custom rules (WAF Rules),wp-adminorwp-login.phpyou can restrict access to specific IP addresses. This allows Cloudflare to block unauthorized login attempts, preventing them from even placing a load on your VPS.

HTTP/3 (QUIC) Support and Free SSL

Cloudflare also supports HTTP/3 (QUIC), which improves communication efficiency, especially on unstable networks such as mobile connections. Additionally, SSL (Universal SSL) between visitors and Cloudflare is automatically applied simply by enabling the proxy.

Please note that to deliver content via HTTP/3, you must open UDP port 443 in your VPS firewall. This is an easy point to overlook, so please keep it in mind.

The Effectiveness of Cloudflare Based on Actual Measurement Data

Below, we present the results of a comparison between two configurations—”KUSANAGI only” and “KUSANAGI + Cloudflare proxy”—run on the same server.

Test Environment and Conditions

• Server: Xserver VPS 4GB Plan (KUSANAGI)
• KUSANAGI Cache: bcache ON, fcache ON (common to both configurations)
• Comparison Scenarios: No Cloudflare Proxy vs. With Cloudflare Proxy
• Measurement Period: March 30, 2026, 10:00 PM – March 31, 2026, 10:00 AM (JST); 13 measurement points in total
• Measurement Method: Automatically collected external benchmarks (TTFB) and PageSpeed Insights API data (mobile and desktop) every hour

Summary of 13 Measurement Results

The following is a summary of the 13 measurements comparing with and without Cloudflare.

External TTFB (Median): 22.97% improvement (improvement in 11 out of 13 measurements)

PSI Mobile TTFB: 47.37% improvement (improvement in all 10 non-tie measurements)

PSI Desktop TTFB: 82.89% improvement (improvement in 12 out of 13 runs)

PSI Desktop LCP: 3.28% improvement (improvement in 10 out of 13 runs)

PSI Mobile LCP: On average, there was a 1.45% deterioration, but outliers had a significant impact; looking at the median, it shows an improvement

PSI Mobile Score: Virtually unchanged (96.92 → 97.00)

PSI Desktop Score: Same (100 → 100)

Notably, there was an 82.89% improvement in desktop TTFB. TTFB, which ranged from 40 to 61 ms without Cloudflare, was reduced to 3–4 ms with Cloudflare. This is the result of Cloudflare’s edge cache being hit, meaning no requests were sent to the origin server at all.

Detailed Data by Time Slot

The following is measurement data for 13 time slots (CF = Cloudflare).

External TTFB (seconds)

• 22:00 ― No CF 0.064 / With CF 0.067 (4.2%)
• 23:00 ― No CF 0.082 / With CF 0.060 (-26.7%)
• 00:00 — Without CF 0.190 / With CF 0.059 (-69.3%)
• 01:00 — No CF 0.065 / With CF 0.063 (-2.3%)
• 02:00 ― No CF 0.067 / With CF 0.065 (-3.3%)
• 03:00 ― No CF 0.070 / With CF 0.055 (-22.3%)
• 04:00 ― No CF 0.060 / With CF 0.059 (-0.1%)
• 05:00 ― No CF 0.073 / With CF 0.062 (-15.1%)
• 06:00 ― No CF 0.069 / With CF 0.054 (-21.3%)
• 07:00 ― No CF 0.062 / With CF 0.058 (-6.0%)
• 08:00 ― No CF 0.087 / With CF 0.055 (-37.2%)
• 09:00 ― No CF 0.062 / With CF 0.060 (-3.2%)
• 10:00 — No CF 0.061 / With CF 0.063 (+2.9%)

PSI Desktop TTFB (ms)

• 10:00 PM ― No CF 43 ms / With CF 3 ms (-93.0%)
• 11:00 PM ― No CF 61 ms / With CF 3 ms (-95.1%)
• 12:00 AM ― No CF 40 ms / With CF 3 ms (-92.5%)
• 01:00 — No CF: 43 ms / With CF: 3 ms (-93.0%)
• 02:00 — Without CF: 50 ms / With CF: 3 ms (-94.0%)
• 03:00 ― No CF: 41 ms / With CF: 3 ms (-92.7%)
• 04:00 ― No CF: 53 ms / With CF: 3 ms (-94.3%)
• 05:00 ― Without CF: 48 ms / With CF: 3 ms (-93.8%)
• 06:00 ― No CF 40 ms / With CF 3 ms (-92.5%)
• 07:00 ― No CF: 40 ms / With CF: 65 ms (62.5%)
• 08:00 ― No CF: 40 ms / With CF: 3 ms (-92.5%)
• 09:00 ― No CF: 50 ms / With CF: 4 ms (-92.0%)
• 10:00 ― Without CF: 47ms / With CF: 3ms (-93.6%)

Only at the 07:00 time point did the TTFB with Cloudflare worsen; this is likely due to cache refresh timing or a temporary edge issue. Overall, Cloudflare is overwhelmingly advantageous.

Overview of KUSANAGI Initial Setup

Here is a brief overview of the KUSANAGI initial setup process. Since many services allow you to select the KUSANAGI image when signing up for a VPS, there is essentially no hassle involved in installing the OS.

VPS Subscription and KUSANAGI Image Selection

With services such as Xserver VPS, Shin VPS, and ConoHa VPS, you can select KUSANAGI as the application image when signing up for a server. The OS is typically AlmaLinux or CentOS Stream. We recommend at least 2GB of RAM, preferably 4GB or more.

SSH Connection and Initial Setup Commands

Connect to the VPS via SSH and perform the initial KUSANAGI setup. The main steps are as follows:

• kusanagi init: Initial setup (time zone, language, administrator password, etc.)
• kusanagi provision: Create a profile for WordPress (domain, database, etc.)
• kusanagi ssl: Obtain and apply a Let’s Encrypt certificate

With just a few commands, you can set up an SSL-enabled WordPress environment. While this may be a bit challenging for those unfamiliar with the command line, it’s not difficult if you follow the steps carefully.

Enabling bcache and fcache

After provisioning, enable caching.

• kusanagi fcache on: Enable FastCGI caching
• kusanagi bcache on: Enabling WordPress Built-in Caching

That’s all it takes for page caching to start working. Since fcache is automatically purged when posts are updated, you can generally leave it enabled without any issues.

Overview of Cloudflare Setup Procedure

Here is a concise summary of the steps to set up Cloudflare on a VPS + KUSANAGI environment.

Creating a Cloudflare Account and Adding a Domain

The free Cloudflare plan is sufficient. After creating an account, add the target domain and import your existing DNS records.

Changing Nameservers

Switch the nameservers at your domain registrar to those specified by Cloudflare. After switching, it may take several minutes to several hours for the DNS changes to propagate. Setting a shorter TTL in advance can minimize downtime during the switch.

Configuring SSL Mode

Select “Full (Strict)” for Cloudflare’s SSL/TLS settings. If you have already obtained a Let’s Encrypt certificate via KUSANAGI, this setting will encrypt traffic between Cloudflare and the origin server. Be careful: selecting “Flexible” can cause a redirect loop.

Enabling the Proxy

Turning on the orange cloud icon next to the A record in the DNS records will enable the Cloudflare proxy. This will activate a suite of security and performance features, including CDN, WAF, and DDoS protection.

Optimizing Cache and Security Settings

Once you’ve enabled the Cloudflare proxy, adjust the cache and security rules for WordPress.

Configuring Cache Rules

Use Cloudflare’s Cache Rules to finely control what is cached and what is excluded.

• Cache Exclusions:/wp-admin/*、/wp-login.php、/wp-cron.php Exclude admin and login pages from caching
• Caching Static Files: Actively cache images, CSS, JS, and font files, and set the Edge Cache TTL to a longer duration.
• HTML Caching: Caching the HTML of article pages minimizes requests to the origin. However, since this may affect the display for logged-in users or immediately after posting a comment, it is safer to include cookie-based exclusion rules

Access Restrictions via WAF Rules

You can use Cloudflare’s custom rules to restrict access to the WordPress admin panel.

• wp-login.php Block access from IP addresses other than your own
• /wp-admin/ Similarly, restrict access to subdirectories (however, admin-ajax.php may be used on the front end, so exclude it)
• xmlrpc.php Completely block access to (if not in use)

By configuring these rules on the Cloudflare side, unauthorized access requests are blocked before they reach your VPS. This is particularly effective for VPS plans with limited memory.

Frontend Optimization Without Plugins

Once the server and CDN layers are set up, we’ll focus on optimizing the frontend layer. With the combination of KUSANAGI and Cloudflare, significant speed improvements are possible even without plugins.

Image Optimization

Images are the factor that most significantly impacts page load times. Keep the following points in mind.

• Convert to WebP or AVIF format: This can reduce file sizes by 30–50% compared to JPEG or PNG. On Cloudflare’s paid plans, automatic WebP conversion is available via the Polish feature.
• Specify appropriate dimensions: Upload images sized to match the display area. Unnecessarily large images waste loading time.
• Lazy loading: Native lazy loading has been included as standard in WordPress 5.5 and later. Images outside the initial viewport are automatically lazy-loaded

Optimizing CSS and JavaScript

CSS and JavaScript output by themes and plugins significantly impact page load speed.

• Removing Unnecessary Scripts: Remove CSS and JavaScript loaded by plugins you aren’t usingfunctions.phpwp_dequeue_script/wp_dequeue_styleto remove
• Deferred loading with `defer`/`async`: Add thedeferattributes
• Inline critical CSS: Output the minimum CSS required for the first view inline, and load the rest asynchronously
• CSS/JS minification: You can minify files without a plugin using Cloudflare’s Auto Minify feature

Disable unnecessary features

WordPress loads many features by default, but disabling unused features improves performance.

• Disable the WordPress emoji script (wp-emoji-release.min.js)
• Disable oembed-related scripts
• Limiting post revisions (in wp-config.phpAUTOSAVE_INTERVALorWP_POST_REVISIONSin wp-config.php)
• Deleting unused plugins (delete them, not just deactivate them)

Optimize web fonts

External fonts such as Google Fonts affect page load speed.font-display: swapBy specifying […], you can prevent perceived delays by displaying content using system fonts as a placeholder until the font finishes loading. Keep the number of fonts to a minimum and limit the weights used to only those necessary.

Database optimization

As your WordPress site ages, unnecessary data accumulates in the database.

• Deleting revisions: There may be hundreds or even thousands of past post revisions. You can delete them in bulk using thewp post deletecommand
• Deleting spam comments: If left unchecked, they will cause the database to grow excessively
• Cleaning Up Transient Data: Expired transient data may not be automatically deleted
• Table optimization: Use the MySQLOPTIMIZE TABLEcommands to resolve fragmentation

KUSANAGI also supports object caching using Redis. By caching query results in memory, repeated queries can be accelerated.

Optimizing the PHP version

The PHP version directly impacts processing speed. In some cases, simply migrating from PHP 7 to PHP 8 can improve execution speed by 20–40%.

KUSANAGI always keeps the latest PHP version available, andkusanagi php82and you can switch versions using a command as shown here. After verifying compatibility with your themes and plugins, try to use the newest version whenever possible.

How to Measure Page Load Speed

Once you’ve optimized for speed, verify the results with metrics. Here are some key measurement tools.

PageSpeed Insights

This is a free tool provided by Google. Simply enter a URL to view performance scores for both mobile and desktop, as well as Core Web Vitals (LCP, CLS, INP, etc.). TTFB and LCP are particularly useful for assessing the effectiveness of speed optimization.

GTmetrix

This tool provides more detailed waterfall charts than PageSpeed Insights. It’s useful for visually identifying which resources are causing bottlenecks.

Measuring TTFB with curl or External Scripts

If you want to perform regular measurements or analyze trends by time of day, it’s effective to retrieve TTFB externally using the curl command or a custom script. The actual measurement data in this report was also collected using this method.

Frequently Asked Questions

Is KUSANAGI free to use?

Yes. KUSANAGI itself is available as a free CE (Community Edition). However, you will need to pay separately for the VPS subscription. Services like Xserver VPS and Shin VPS start at a few hundred yen per month.

Is it worth migrating from a shared server to a VPS + KUSANAGI?

It is highly worthwhile if you prioritize page load speed. According to the author’s actual measurements, while the external TTFB on a shared server ranged from 0.162 to 0.367 seconds, it was reduced to around 0.060 to 0.100 seconds on a VPS (KUSANAGI environment). However, since VPS requires server management knowledge, if you are concerned about updates or maintenance, staying on a shared server and exploring other speed-optimization measures is also an option.

Is the free Cloudflare plan effective?

All of the performance data in this test was collected using Cloudflare’s free plan. Even with the free plan, you can access sufficient features such as CDN caching, DDoS protection, basic WAF functionality, and HTTP/3 support.

Are speed-optimization plugins unnecessary?

With a KUSANAGI + Cloudflare setup, caching plugins like WP Super Cache or W3 Total Cache are generally unnecessary. Since KUSANAGI’s fcache handles page caching and Cloudflare handles edge caching, it’s safer to disable these plugins to avoid the risk of caching conflicts. CSS and JS optimization can also be handled by Cloudflare’s Auto Minify.

Summary

The key to speeding up WordPress lies not in increasing the number of plugins, but in properly designing the three layers: the server layer, the CDN layer, and the front-end layer.

Here is a summary of the configuration introduced in this article.

• Server Layer: VPS + KUSANAGI, utilizing bcache/fcache, OPCache, and Nginx optimization
• CDN Layer: Cloudflare proxy, implementing edge caching, security, and HTTP/3 all at once
• Front-end Layer: Implement image optimization, CSS/JS optimization, and removal of unnecessary features without plugins

According to actual test results, simply adding Cloudflare improved desktop TTFB by 82.89%, while maintaining a PSI score of 100 for desktop and 97 for mobile.

If you’re unsure about managing a VPS or configuring KUSANAGI, try implementing Cloudflare first. Even the free plan offers significant speed improvements and enhanced security. For more detailed setup instructions, please also refer to our article comparing servers for WordPress.