Step-by-step guide: Boost LocalWP performance on Windows and resolve the slow pc isues!

by Oleg Petrov | Dec 5, 2025 | Tutorials

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.

  1. 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).

  2. 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.
  3. 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.

  1. Open LocalWP.
  2. Right-click your site name in the sidebar.
  3. Select “Go to Site Folder” (or “Reveal in Explorer”).
  4. 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.

  1. Navigate to conf/mysql/.
  2. Open the file named my.cnf.hbs in a text editor (like VS Code or Notepad).
  3. Find the [mysqld] section.
  4. Add or Modify the settings to match the high-performance configuration below.
Note: The most critical setting is 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.

  1. Navigate to conf/php/.
  2. Open the file named php.ini.hbs.
  3. Search for [opcache] and [xdebug].
  4. 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.

  1. Save all the files you edited.
  2. Open the LocalWP app.
  3. Stop the site.
  4. 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.