It seems like you've done a thorough job of setting up your local environment and have considered many of the common performance bottlenecks. However, since you're experiencing slow initial load times across multiple applications (Laravel, Magento, WordPress, Drupal), it suggests that the issue might be related to the common elements in your stack, such as Nginx or PHP-FPM.
Here are a few suggestions that might help you improve the initial load time:
-
DNS Resolution: Ensure that the domain names you are using (like
projectname.test) are resolved quickly. Since these are local, you might want to map them directly in your/etc/hostsfile to127.0.0.1to avoid any potential DNS resolution delays. -
Nginx Configuration: Review your Nginx configuration for any potential misconfigurations that could cause delays. For example, ensure that the
server_namedirective matches your test domain exactly, and there are no conflicts. -
PHP-FPM Configuration: The slow initial response might be due to PHP-FPM's process management. Since you're using a dynamic process manager, it's possible that on the first request, PHP-FPM has to spin up a new process to handle it. You can try changing the
pmsetting tostaticand setting a lowerpm.max_childrento see if that helps with the initial load time. -
Opcache: You have
opcache.validate_timestamps=1, which means that on each request, PHP will check for updated scripts. This can slow down performance, especially on the first load. For local development, you might want to setopcache.validate_timestamps=0and manually reset the cache when you update your PHP files. -
Xdebug: Even though you mentioned that Xdebug is turned off most of the time, ensure that it is indeed not running as it can significantly slow down requests.
-
Filesystem Performance: Since you're on a Mac with an M1 chip, there might be filesystem performance issues, especially if you're using Docker or any form of virtualization. Ensure that your projects are located on a native filesystem and not within a virtualized environment.
-
Network Configuration: If PHP-FPM is listening on a network port, there might be some network latency, even if it's just
127.0.0.1. You can try switching to Unix sockets for communication between Nginx and PHP-FPM to see if that reduces the initial load time. -
Error Logs: Check both Nginx and PHP-FPM error logs for any warnings or errors that might indicate what's causing the delay.
-
Tracing the Request: Use tools like
curlwith the-voption to trace the request and response headers and see where the delay might be occurring. -
Profiler: Use a profiling tool to get more insight into what's happening during the request lifecycle. Tools like Tideways, Blackfire, or even the built-in PHP profiler can help you pinpoint where the slowdown is occurring.
Here's an example of how you might adjust your PHP-FPM pool configuration to use a static number of child processes:
[www]
user = username
group = staff
listen = /var/run/php-fpm.sock
listen.owner = username
listen.group = staff
listen.mode = 0660
pm = static
pm.max_children = 5
And the corresponding Nginx configuration to use the Unix socket:
location ~ \.php$ {
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
Remember to restart both Nginx and PHP-FPM after making changes to their configurations. If none of these suggestions resolve the issue, you may need to perform more in-depth profiling to understand where the bottleneck is occurring.