This post is intended for PHP devs. I'll show you four ways to improve the speed of your PHP app easily. I'll skip the part where I tell you to use PHP 7, you must know by now that the speed improvement is dramatic… (and PHP 5.x is EOL anyway so…)TL;DR: -a flag for composer, use opcache, use template engine cache, use fully qualified function names.<h2><a href="https://dev.to/elabftw/optimizing-your-php-app-speed-3hd4#0-use-composer-optimization" target="" rel=""></a>0. Use Composer optimization</h2>The prod and dev environments are a little bit different. It shouldn't be a surprise to you if I tell you that you should not install the dev dependencies in prod, right?<div><pre><code>composer install --no-dev
</code></pre></div><span>That's basic. But did you know you can optimize the autoloader? Because the classes won't be changing once it's deployed, you can add a flag to composer (-a) that will improve the speed of autoloading:</span><div><pre><code>composer install --no-dev -a
</code></pre></div>Ok, but what does it do you'll ask?<span>From the&nbsp;<a href="https://getcomposer.org/doc/06-config.md#classmap-authoritative" target="" rel="">help</a>&nbsp;it says: "the Composer autoloader will only load classes from the classmap". It also implies "<a href="https://getcomposer.org/doc/06-config.md#optimize-autoloader" target="" rel="">optimize-autoloader</a>" so you don't have to add it too. You can see it as a way to say "hey, no more classes will be added so you don't need to scan the filesystem for a new class, just use the ones in the autoloader".</span><h2><a href="https://dev.to/elabftw/optimizing-your-php-app-speed-3hd4#1-use-opcache" target="" rel=""></a>1. Use opcache</h2>When a PHP file is read, it is converted in opcode, and then executed by the engine. Because in prod your PHP files won't change, you don't want to convert them to opcode every single time. Enter opcache.<span>Using opcache can dramatically increase the speed of your PHP application. Make sure that&nbsp;<code>opcache_enable=1</code>&nbsp;is uncommented in your&nbsp;<code>php.ini</code>&nbsp;file. It will store the opcode for the executed files.</span><span>But don't enable it in your dev environment ;) (unless you enable&nbsp;<code>opcache.validate_timestamps</code>&nbsp;and set&nbsp;<code>opcache.revalidate_freq</code>&nbsp;to 0 (thx u/iluuu))</span><span>I recommend the&nbsp;<a href="https://github.com/rlerdorf/opcache-status" target="" rel="">opcache-status</a>&nbsp;tool to monitor the use of opcache (at least in the beginning).</span><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--r8Qb-zYl--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/1r1yu35mlw3km3ss6f6m.png" target="" rel=""><img alt="opcache-status" src="https://res.cloudinary.com/practicaldev/image/fetch/s--r8Qb-zYl--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/1r1yu35mlw3km3ss6f6m.png"></a><h2><a href="https://dev.to/elabftw/optimizing-your-php-app-speed-3hd4#2-use-a-template-engine-with-cache" target="" rel=""></a>2. Use a template engine with cache</h2><span>Templating engines like&nbsp;<a href="https://github.com/twigphp/Twig" target="" rel="">Twig</a>&nbsp;can create a cache of the generated PHP code. The speed gain here can be dramatic. Again, you only want to cache the templates in prod, not in dev. But make sure that the cache is setup. For Twig see the&nbsp;<a href="https://twig.symfony.com/doc/2.x/api.html#compilation-cache" target="" rel="">documentation</a>.</span><h2><a href="https://dev.to/elabftw/optimizing-your-php-app-speed-3hd4#3-use-a-backslash-in-front-of-standard-functions" target="" rel=""></a>3. Use a backslash in front of standard functions</h2>Normally your code is namespaced (right?). So what happens when you call a function from the standard PHP library? The "compiler" (opcode producer) will look into the current namespace, then go up, and eventually use the global namespace. This means that if you add a "\" in front of standard functions (so effectively namespacing it in the global namespace explicitely), it will result in less opcode instructions, and that means faster code execution. Think it's one of those useless micro-optimization like the use of single vs. double quotes? Think again. Let's take this code:<a href="https://res.cloudinary.com/practicaldev/image/fetch/s--4il4J_uC--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/qgs90wmy8pz0cih136tg.jpg" target="" rel=""><img alt="code" src="https://res.cloudinary.com/practicaldev/image/fetch/s--4il4J_uC--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/qgs90wmy8pz0cih136tg.jpg"></a><span>Without&nbsp;a backslash on the&nbsp;<code>count()</code>:</span><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--4dlBKW1i--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/8m1v3355ynddf3k7j4zx.jpg" target="" rel=""><img alt="no-backslash" src="https://res.cloudinary.com/practicaldev/image/fetch/s--4dlBKW1i--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/8m1v3355ynddf3k7j4zx.jpg"></a><span>With&nbsp;a backslash in front of&nbsp;<code>count()</code>:</span><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--T9iOeTEE--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/8i4absz1qnm1l3o4d4vv.jpg" target="" rel=""><img alt="backslash" src="https://res.cloudinary.com/practicaldev/image/fetch/s--T9iOeTEE--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://thepracticaldev.s3.amazonaws.com/i/8i4absz1qnm1l3o4d4vv.jpg"></a>As you can see, the difference is glaring and if you reproduce this on all the functions in your code it might make a palpatable difference at the end of the day ;)<h2><a href="https://dev.to/elabftw/optimizing-your-php-app-speed-3hd4#conclusion" target="" rel=""></a>Conclusion</h2>The little things I'm showing in this post won't make your app faster, at best it'll improve marginally. You can consider them as "good practice" because why not take some speed gains if you can, but if you want to get serious about optimizing your PHP app, get a profiler and optimize your SQL queries, because that's what is causing an issue, not the few milliseconds you might get with this kind of things ;)That's all folks, have fun coding!<span>And if you like PHP, I'm always happy with contributions on the&nbsp;<a href="https://github.com/elabftw/elabftw" target="" rel="">eLabFTW project</a>, an open source electronic lab notebook.</span>

Optimizing your PHP app speed

Useful links

Company

Information

Content Writers

Freelancers

Freelance Jobs

Online Jobs

Designers

Developers

Translations