PHP configuration errors that affect web performance rarely show up in error logs — they just make your site load slowly for no obvious reason. The good news is that most can be fixed in minutes by editing php.ini or using your hosting control panel.
This article walks through the most common mistakes, explains why they slow things down, and gives you the exact values to use.
Why PHP Configuration Matters as Much as Your Code
The PHP interpreter runs your application according to the parameters set in php.ini. A single wrong value can double memory consumption, disable the bytecode cache, or spawn hundreds of unnecessary connections — all without you touching a single line of your application.
The problem is that shared hosting environments often ship with conservative defaults designed for their most demanding tenant, not for your specific site. A freshly installed VPS inherits the Linux distribution's defaults, which aren't optimized for production either.
Mistake 1: OPcache Disabled or Undersized
OPcache compiles and stores your PHP scripts' bytecode in memory. Without it, PHP recompiles every file on every request — completely redundant work.
Check whether it's active by running phpinfo() or checking your hosting panel. If you see opcache.enable=0, change it right away.
Recommended settings for a typical WordPress or Laravel site:
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.save_comments=1A memory_consumption of 128 MB covers most sites. If you're running many plugins or a large framework, bump it to 256 MB.
Mistake 2: memory_limit Too Low — or Too High
A memory limit that's too low causes fatal errors or kills PHP processes mid-request. But an unrealistically high limit (like 2 GB) just delays the problem — a poorly written script can then consume all the server's RAM.
| Site type | Recommended value |
|---|---|
| Blog or informational site | 128 MB |
| WordPress with plugins | 256 MB |
| WooCommerce / e-commerce | 512 MB |
| Complex Laravel app | 256–512 MB |
Set the value in php.ini:
memory_limit = 256MMistake 3: max_execution_time Set Wrong
The default of 30 seconds is reasonable for normal web requests. The issue arises at both extremes:
- Too low (15 s or less): legitimate tasks like importing products or sending bulk emails hit the timeout and fail.
- Too high (300 s or more): a script that enters an infinite loop holds a PHP process for five full minutes, blocking server resources.
The right balance is keeping 30–60 seconds in production and raising the limit only for CLI scripts or scheduled tasks, not for the entire site.
max_execution_time = 30
max_input_time = 60Mistake 4: Session Configuration Generating Excessive I/O
By default, PHP saves sessions as individual files on disk. On a busy site, this generates thousands of read/write operations per second — and disk I/O is usually the server's slowest bottleneck.
Solutions ranked from easiest to most impactful:
- Sessions in Redis or Memcached: switch the session handler to memory instead of disk.
- Reduce session lifetime:
session.gc_maxlifetime = 1440(24 min) is enough for most sites. - RAM storage with tmpfs: mount the session directory on a memory partition (VPS/dedicated server only).
For sites on shared cPanel hosting, the most practical option is using a hosting service with pre-configured Redis, which eliminates disk I/O for sessions without needing root access.
Mistake 5: Unnecessary Extensions Loaded
Each PHP extension consumes memory when the process starts. A misconfigured server may load 40–50 extensions when your application only uses 10 or 12.
Check active extensions with php -m in the terminal. Extensions you rarely need in production include:
xdebug— development only, never in productionimagick/gd— load only one of the twosodium,intl,gettext— only if your app explicitly uses them
In cPanel you can enable and disable extensions from MultiPHP Manager → PHP Extensions.
How to Apply Changes Safely
- Back up your current
php.inibefore editing. - Change one parameter at a time and test the site after each change.
- Use a
.user.inifile in the site root if you don't have access to the globalphp.ini— the directives are the same and apply only to that specific domain. - Restart PHP-FPM (if you have access) or wait for
.user.inito propagate (up to 5 minutes due to PHP's own cache). - Validate with
phpinfo()that the new value is actually active.
For a deeper look at your full performance stack, explore the web performance articles covering everything from browser caching to Core Web Vitals.
Key Takeaways
- Disabled OPcache is the most expensive mistake — always enable it and size it to match your codebase.
memory_limitshould be realistic: not so low it kills processes, not so high it hides wasteful scripts.max_execution_timein the 30–60 second range is the safe zone for normal web requests.- File-based sessions generate excessive disk I/O on busy sites; Redis is the most effective fix.
- Disable PHP extensions your application doesn't use to reduce memory footprint.
- Apply changes one at a time and validate with
phpinfo()before moving on.
Want someone to audit your PHP configuration and tune it without the risk? At elenlace.com we offer performance and server configuration audits for Mexican websites — reach out and we'll get back to you the same day.
FAQ
Can I change php.ini on shared hosting?
On most cPanel-based shared hosting plans you can use a .user.ini file in your domain root, or access MultiPHP Manager to adjust key values like memory_limit and enable OPcache without needing server root access.
How do I know if OPcache is actually working?
Create a temporary file with <?php phpinfo(); ?> in your site root, open it in a browser, and look for the "Zend OPcache" section. If opcache.enable shows as On and the cache status is active, it's running correctly.
Does Xdebug in production slow the site down?
Yes, significantly. Xdebug can increase PHP execution time by 2 to 5 times because it intercepts every function call. Always disable it in production; use it only in your local development environment.
How often should I review my PHP configuration?
At minimum: every time you upgrade to a new major PHP version (e.g. 8.1 → 8.2), after installing heavy plugins, and whenever you notice performance degradation with no code changes. A biannual checkup is a solid preventive habit.
Further reading
Other providers and guides worth comparing:
