The “Supercomputer” Paradox
If you develop WordPress on Windows 10 or 11, you have likely experienced a frustrating paradox: You have a powerful PC with a high-end processor and loads of RAM, yet a blank WordPress site on LocalWP takes 3-5 seconds just to load the dashboard.
Your PC isn’t broken, and you aren’t imagining things. This is a known architectural bottleneck specific to running servers on Windows.
The Technical Villain: Why is Windows Slow?
Before we fix it, it is crucial to understand why your hardware is sitting idle while your site crawls.
- The Missing PHP-FPM: On Linux and macOS, Local uses PHP-FPM (FastCGI Process Manager). This technology spawns a pool of “workers” that stay alive in memory, ready to handle heavy traffic instantly.
The Limitation: Windows does not support PHP-FPM. Instead, LocalWP uses the older
php-cgi.exe. This process is often single-threaded and struggles to handle concurrent requests (like the dozens of requests a WordPress dashboard makes). - Disk I/O Latency: Database operations on Windows file systems are significantly slower than on Linux. Default settings read from the disk constantly, causing massive delays.
- Xdebug Overhead: LocalWP enables Xdebug by default. On the single-threaded Windows setup, this hooks into every line of code, acting like a handbrake on your processor.
The following steps will “unthrottle” your environment by moving operations from your Disk to your RAM and removing the debugging overhead.
Prerequisite: Locating Your Config Files
For every site you create in Local, there is a specific configuration folder containing the “blueprints” for the server.
- Open LocalWP.
- Right-click your site name in the sidebar.
- Select “Go to Site Folder” (or “Reveal in Explorer”).
- Open the folder named
conf.
We will be working inside the mysql and php subfolders.
Step 1: Optimize the Database (MariaDB)
The Goal: Stop reading from the slow disk and force the database to live in your RAM.
- Navigate to
conf/mysql/. - Open the file named
my.cnf.hbsin a text editor (like VS Code or Notepad). - Find the
[mysqld]section. - Add or Modify the settings to match the high-performance configuration below.
innodb_buffer_pool_size. Set this to roughly 25% – 50% of your total system RAM.[mysqld] # --- HIGH PERFORMANCE WINDOWS SETTINGS --- # The Buffer Pool: Forces the DB to run in Memory, not Disk. # If you have 32GB RAM, use 8096M (8GB). # If you have 16GB RAM, use 4096M (4GB). innodb_buffer_pool_size = 4096M # Log File Size: Reduces how often the DB stops to write to disk. innodb_log_file_size = 512M # I/O Method: O_DIRECT bypasses Windows OS file caching for raw speed. innodb_flush_method = O_DIRECT # MyISAM & Temp Tables: optimize temporary data handling key_buffer_size = 64K tmp_table_size = 64M max_heap_table_size = 64M
Step 2: Optimize the Engine (PHP)
The Goal: Overcome the lack of PHP-FPM by aggressive caching and removing Xdebug.
Since we cannot use the efficient FPM process manager on Windows, we must make the php-cgi process as lightweight as possible.
- Navigate to
conf/php/. - Open the file named
php.ini.hbs. - Search for
[opcache]and[xdebug]. - Replace those entire sections with the code block below.
What are we changing?
- Disabling Xdebug: We are commenting out the extension entirely. Just having it loaded (even if off) slows down Windows CGI.
- Turbocharging OPcache: Since Windows destroys the PHP process frequently, we need to store the compiled script code in a persistent memory buffer so it doesn’t have to be re-compiled on every click.
[opcache]
{{#if os.windows}}
zend_extension = php_opcache.dll
{{else}}
zend_extension = {{extensionsDir}}/opcache.so
{{/if}}
# --- TURBOCHARGE OPCACHE ---
opcache.enable=1
opcache.enable_cli=1
# Memory for Code: 512MB is plenty for even huge sites.
# (This stores code files, NOT data/images)
opcache.memory_consumption=512
# Store strings in memory to avoid rebuilding them
opcache.interned_strings_buffer=64
# Increase file limit (WordPress core + plugins = thousands of files)
opcache.max_accelerated_files=50000
# Skip checking if files changed on every request (Massive speed boost)
opcache.validate_timestamps=1
opcache.revalidate_freq=0
opcache.save_comments=1
{{/unless}}
[xdebug]
# --- DISABLE XDEBUG FOR PERFORMANCE ---
# Xdebug is the #1 cause of slowness on Windows.
# We comment out the extension so it doesn't even load.
# To use Xdebug, remove the "#" comments below.
# {{#if os.windows}}
# zend_extension = php_xdebug.dll
# {{else}}
# zend_extension = {{extensionsDir}}/xdebug.so
# {{/if}}
xdebug.mode=off
[Pcre]
# Enable Just-In-Time compilation for Regex (Faster on Windows 11)
pcre.jit=1
Step 2.5: Increase Resource Limits
While you are in php.ini.hbs, ensure your resource limits are high enough so your powerful PC isn’t artificially restricted.
# Data Memory: Give PHP room to process heavy page builders memory_limit = 1024M # Execution Time: Prevent timeouts during large imports max_execution_time = 1200 max_input_time = 600 # File Uploads: Allow large plugin/theme uploads post_max_size = 1000M upload_max_filesize = 1000M
Step 3: Apply the Changes
This is the most common step users forget. LocalWP uses “Handlebars” templates (the .hbs files we just edited). The actual server configuration is only generated when the site starts up.
- Save all the files you edited.
- Open the LocalWP app.
- Stop the site.
- Start the site.
The Result
You have now manually tuned your LocalWP environment to bypass the limitations of the Windows file system and the legacy CGI process.
- Database: Now runs primarily in RAM.
- PHP: No longer has the heavy debugger attached.
- Scripts: Are compiled once and served from memory via OPcache.
You should immediately notice that the WordPress admin dashboard loads significantly faster, allowing you to work at the speed of your hardware.
