Image for post: Laravel slow on Windows? How WSL2 fixed my performance issues

Laravel slow on Windows? How WSL2 fixed my performance issues

Summary

Laravel’s performance issues on Windows are not caused by PHP itself, nor by Laragon or XAMPP. The real bottleneck is the interaction between PHP’s execution model, Laravel’s architecture, and Windows’ NTFS filesystem semantics.

Laravel is extremely file-system intensive by design so it performs slow on Windows

Unlike compiled frameworks, Laravel relies heavily on runtime file discovery. During a single HTTP request, Laravel performs thousands of filesystem operations, including:

  • stat() calls to check file existence and modification times

  • include / require operations for PHP class loading

  • Recursive directory scans for:

    • Service provider auto-discovery

    • Route registration

    • Middleware loading

    • Filament resource, page, widget, and theme discovery

  • Blade view freshness checks and compilation decisions

  • Configuration file loading and cache validation

Even when caches are enabled, Laravel still performs many metadata checks, because PHP must ensure files are valid and up to date.

This design works exceptionally well on Linux, where filesystem metadata access is extremely cheap.


NTFS vs Linux filesystems: metadata is the real problem

The performance gap is not about raw disk speed. It’s about filesystem metadata operations.

Linux (ext4, xfs)

On Linux:

  • File metadata is aggressively cached in memory

  • stat() calls are extremely fast

  • Directory traversal is optimized for large trees

  • Permission checks are lightweight

  • File locking is simpler and cheaper

Linux filesystems are optimized for server workloads-exactly what PHP + Laravel represent.

Windows (NTFS)

NTFS is a powerful and reliable filesystem, but it has higher per-operation overhead, especially for small files:

  • Every filesystem call goes through:

    • NT kernel

    • Security descriptor checks

    • ACL (Access Control List) resolution

  • Metadata access (stat, file_exists, is_file) is significantly slower

  • NTFS favors data integrity and security, not high-frequency metadata access

  • PHP on Windows uses the Win32 API, which adds another abstraction layer

One file check is not slow.
Ten thousand file checks per request are.

Laravel turns this difference into a performance cliff.


Why the slowdown feels exponential

Laravel doesn’t just read files - it checks them repeatedly.

For example:

  • Composer autoloading checks class maps and fallback paths, scanning vendor directories

  • Compiling Blade templates and checking file modification times

  • Reading configuration files and caching decisions

  • Filament scans directories to dynamically register resources

  • Service providers are discovered on every request (unless cached)

  • Route file scanning and middleware loading

  • Service provider discovery across packages

On Linux:

“Thousands of cheap operations”

On Windows:

“Thousands of expensive operations”

The result is not linear slowdown-it feels exponential, especially as the project grows.

This is why:

  • Small Laravel apps seem fine on Windows

  • Larger apps (Filament, Nova, Livewire-heavy projects) become unusable


Why WSL2 fixes everything instantly

WSL2 runs a real Linux kernel inside a lightweight virtual machine.

When your Laravel project lives inside the WSL2 filesystem:

  • PHP runs on Linux

  • Files live on ext4

  • File metadata is cached efficiently

  • Laravel’s assumptions suddenly become true again

Nothing about your code changes-but performance improves dramatically because the filesystem now matches Laravel’s design expectations.

Important nuance:
If you store your project in /mnt/c/..., you are still using NTFS and will not get these benefits.
The project must live inside the Linux filesystem (/home/...).


Why Docker and Laravel Sail don’t magically solve this on Windows

Docker on Windows usually mounts project files from NTFS into containers.

That means:

  • Linux containers

  • Windows filesystem underneath

  • Same metadata bottleneck

  • Extra virtualization overhead

Docker only helps if:

  • Docker runs inside WSL2

  • Project files are stored inside WSL2

  • Containers access Linux-native files

At that point, WSL2-not Docker-is the real solution.


Is this a Laravel flaw?

No - and this is an important distinction.

Laravel is optimized for:

  • Linux servers

  • Unix-like filesystems

  • Environments where filesystem metadata access is cheap

That’s not a limitation-it’s a correct optimization for production reality.

Windows development environments simply don’t match Laravel’s assumptions.


Practical takeaway (clear and defensible)

  • Laravel is slow on Windows because NTFS is slow at metadata-heavy workloads

  • Laravel performs metadata-heavy workloads by design

  • WSL2 provides a Linux filesystem without leaving Windows

  • This is not a workaround-it’s architectural alignment

Conclusion

The Windows file system isn't going to get dramatically faster, and Laravel isn't going to reduce its file operations without sacrificing the features that make it powerful. WSL2 bridges this gap perfectly, giving Windows developers access to Linux file system performance without leaving their familiar operating system.

My Laravel 12 and Filament 4.2 project went from unusable to delightful purely through this change. If you're experiencing similar slowdowns, WSL2 isn't just a workaround-it's the professional solution.