#

On the last few weeks I have seen lots of discussions about speed in the Laravel community (and some other communities, for that matter) and I thought I share a few thoughts here.

First, as developers I would say we are always going to think about performance — we want to write good code that is performant. Period. With that said, I also think it is easy to misunderstand where we need to make optimizations and where the problems lie.

To be clear, I am thinking of a specific thread that mentioned Laravel was “slow”. Now, I am 100% a Laravel fanboy, so you might be thinking that I’m going to defend it… The first thing is that we have to define what is slow. It can’t be “slow” per se — is >20ms slow? Maybe 50ms? Maybe 100ms? We usually classify a language or framework as slow by comparing it to others.

I’ll give that Laravel is not so fast in the comparisons we often see, because it is usually compared to complete different beasts. Laravel is a full-stack framework with TONS of features, so it’s natural for it to be slower than something like Express (which is basically a router) or a barebones framework that doesn’t ship with almost anything. Now, that does not make Laravel slow. Laravel can be quite fast, actually — probably much more faster than most of us will ever need.

This email is not about Laravel though — it’s about early optimizations, micro-optimizations and speed. I already went a bit in depth about scaling Laravel on this article, but I want to share some extra thoughts here.

Every web application is a distributed system of sorts these days. You have the user on one end, a server running NGINX and PHP, maybe a different server running your database and cache service, your application might call several external APIs, etc — that is, you have lots of possible bottlenecks — your PHP application is just one of them.

​

We have lots of computing power these days, so even if you write poor, performant code, you’ll probably still be fine. I’m not saying that you should write bad code, all I’m saying is that our current tools do a lot for us. And, from my experience, the bottlenecks usually come up at different places than the application — a database without proper indexes and bad queries is a perfect example of this — you think your app is slow, you add an index and boom - it just works.

Now, to my main point about speed — speed definitely matters — we don’t want to run slow code, but as I said, most modern languages are fast enough and there are other factors we should be looking into: the community, the developer experience, the ecosystem, the familiarity of a team with a language, etc. — speed is just one of those factors. Were it the prime and definitive factor, we’d all be writing C and Go only — that’s totally not the case.

There’ll certainly be situations where you specifically need a lot of performance, and in those scenarios, you’d definitely want to pick the appropriate tool for the job, but I’d argue that’s not the norm in web development. Most languages and frameworks are more than fast enough, computing power is readily available these days, scaling is much easier than it was before and we have lots of distributed pieces that could cause slowness other than the app itself. There are also lots of things you can do to speed things up: add a caching layer, offload processing to background workers, etc. — so it’s not black and white.

Okay — I feel this email was a bit confusing. To try and summarize my thoughts: in my opinion, speed is important, but not the only important thing — most apps will be fast enough, you have other things to look at (database, API calls, random I/O) that could impact speed, you have several ways to make your app faster (queues, caching, etc) and as long as you don’t write very poor-performant code, you will likely be just fine.
I’ll also add that PHP is a very fast language these days — and we have lots of tools in the community to make it even faster (Swoole, RoadRunner, Octane, hyperf, etc). You can do wonders with it.

Alright, I’m out — if you’ve had any experiences where you needed to attain high performance or if you faced low performance even while doing things right, I’d be very interested to know. Shoot me an email!

Mateus