Forem: Bhaswanth Chiruthanuru

How I optimized the PHP application in 3 days

Bhaswanth Chiruthanuru — Tue, 03 Mar 2026 13:54:23 +0000

This happened nearly 6 years ago, around the year 2019. I was working on my first job at the time as a junior web developer.

At that time I was working on an e-learning platform. My work mainly revolves around building and maintaining the marketing website for the platform. That includes home website, blogs and courses section. I was working in that project as the lead developer along with another front-end developer. It’s a small startup, so I was involved on many things even though I was a junior developer.

The project was migrated from Wordpress, and rebuilt with Laravel & MySQL. I handled most part of the migration that time.

The website was smooth, everything working fine. In my perspective at that time, if the website loads, then it was smooth. I was naive.

One day my team lead, (There was only one team lead in the entire company) called me and explained his concerns regarding the website speed and performance. I didn’t understand it at first. The website was working fine. While it wasn’t loading at the same speed like a single-page application, it was decent enough. But for him, that wasn’t good enough.

He told me to do whatever I can to optimize the website to load faster. He gave me three days to do it.

At that moment, I was like a boy who had just been thrown into something much bigger.

I was just slightly better than a beginner at best. I knew how to build features, I knew how to make things work. But scaling? Performance? Optimization? I hand no idea where to even begin.

I couldn’t refuse the task. And honestly, I have no reason to refuse. He gave me complete freedom to research, experiment and approach the problem however I want.

Even though I hesitated at first because I thought I might break things that were working fine, I eventually agreed to do it. But to be honest, I had no clue where to start.

First day was all about researching and analyzing. I went through articles on Laravel optimization techniques, caching, query optimization, etc. I literally went through everything I found on Google.

I’ve analyzed the website through multiple tools like Checkbot, GTMetrix, etc., to find what’s affecting the performance.

I’ve listed out every suggested change I could. But honestly there wasn’t much I could do in the remaining two days.

I couldn’t risk trying to optimize queries in this stage and breaking something. We are using Laravel eloquent queries for database operations and I barely know basic SQL querying at that time.

I don’t know much about caching at that time and I don’t have the bandwidth to learn and implement it.

There were quite a few of limitations on what I could do.

First one is we are using shared hosting and hosted the website on cpanel. So, I can’t freely install additional software like Redis for caching. The server only supports PHP and MySQL.

Second one is, the website was working perfectly fine and I couldn’t risk breaking anything in the perfectly working system.

Third one is I’ve limited time. And whatever I do, I have to do it in the remaining two days.

So, I’ve listed only the issue that I was confident to work on.

a. This was the first and most important issue that I’ve listed. The website contains multiple components such as dynamic listing, infinite scrolling, dynamic filters, etc. And I was rendering all these contents through API from frontend at the time of page load using Javascript. This is one of the factors that’s increasing the page load time.

b. In the current website, I am serving uncompressed styles and scripts, even though Laravel comes with Laravel Mix by default.

c. Some of the images that were used in the website are of high quality and comes in large size, that were resizing on frontend from CSS.

There were some other issues too, but these were the main issues among the ones that I remember.

Then I’ve started working on the second day.

1) Reduced the usage of Javascript

Logically this was the best thing to do. But honestly, many components are working dynamically front frontend. So, I couldn’t fully avoid the usage of Javascript.

So I did this. I’ve listed out the content that’s dynamically on page load, and rendered it from server-side. This way I’ve mostly avoided API calls, and rendering content using Javascript on page load event. Now the DOM will only get modified when something’s changed or the events get triggered.

2) Building assets for production

At that time, I am not familiar with things like webpack, mixing assets etc. So, even though Laravel comes with Laravel Mix, I’ve served assets normally from /public folder.

But after some digging, I’ve learned how to use Laravel Mix. Honestly, it was super easy and fun. I still use it as my default bundler for my projects, even though the repository is abandoned.

I’ve removed all inline and uncompressed styles and scripts, moved them into the /resources folder, centralized them properly, and ensured that only production-ready compiled assets were being served.

It might sound small, but this reduced unnecessary load and made the application clearer and more maintainable.

3) Compressing Images

This is where it got little trickier. For the website, the client provides the images. Normally the images are of high quality and heavy-weighted and too large. So, we are embedding the images using image tag and resizing using CSS on frontend.

After brainstorming a bit, I’ve decided to compress them and load the images with exact sizes to avoid the resizing from frontend. I’ve used PHPIntervention library to compress and resize images from server side.

I’ve created a new method something like this :

function load_image($filename, $width, $height) {
 $path = "new folder for resized images";
 $new_name = $width . "_" . $height . "_" . $filename;
 if(!file_exists($path . "/" . $new_name)) {
  resize_image_using_intervention();
  return resized_image_path();
 }

 return resized_image_path();
}

The role of this method is, it will check if the resized version of the given image is present in the file system and if not, it will compress and resize the image and store it in the file system. If exists, it will return the image URL as string.

I can use in blade template like below :

<img src="{{ load_image("image.png", 200, 100) }}" alt="" />

And it will display the resized image. As it won’t touch the original image and create resized copies of it, I can use the same image with multiple sizes in multiple places.

This way, the browser don’t need to adjust the image sizes on frontend as the images already loading with correct dimensions.

4) Rendering Minified HTML

Well, this isn’t actually a problem, but an extra I’ve decided to do. And this was easy, there were many packages available for Laravel to minify the templates before rendering. Honestly, I just went with the flow for this one.

5) Gzip Compression

At that time, I don’t even know anything about Gzip compression. I’ve found it in some article, and after looking into it, I’ve decided to give it a try, since I only needed to modify .htaccess file and thats it. No code changes, nothing.

That’s it. This is all I did and I’ve managed to do it in the given timeframe. And to my surprise, the speed of the page loading increased more than before, even client acknowledged it.

Looking back now, compared to the optimization techniques and tools available today, what I did might seem small, or may be even basic.

But at that time, I was barely more than a beginner. I don’t know advanced scaling strategies or deep performance engineering. I simply did what I was capable of doing with the knowledge I had. And luckily, it worked better than I expected.

When I look back at that project, I also remember something else.

The application was fully server-size rendered. I initially used web components, but later I removed them during optimization.

Today, things feel very different.

We ship large amounts of Javascript by default. Rendering logic that could easily live on the server is being pushed to the client. Using complete frontend frameworks has almost become the norm.

There was even a time when I disliked PHP and SSR. I was drawn toward modern shiny frameworks like React and Vue, believing they were automatically better.

But think what, after working on real-world projects that relied heavily on them, I’ve actually started to like and appreciate PHP and SSR more.

Conclusion

Developers today are, in many cases, taking Javascript for granted.

Javascript is really powerful, but it should be used for what it’s meant to be used. Handling dynbamic client-size interactions, managing complex UI state, and enhancing user experience are prefect use cases. But rendering everything on the client by default isn’t always the smartest choice.

Forcing one language or one ecosystem into every layer of an application may look modern and clean, but we must consider what we are trading for it, bundle size, performance overhead, complexity, and long-term maintainability.

I don’t hate modern technologies. In fact, I’ve worked with them and learned from them. What I’ve come to understand is simple. What I’ve come to understand is simple. Choose your stack wisely. Let the problem decide the tools, not the trends.

Originally published at https://bhaswanth.com.

Why legacy codebases are better teachers than greenfield projects

Bhaswanth Chiruthanuru — Thu, 12 Feb 2026 12:00:54 +0000

Almost every developer must've worked on at least one legacy project in their career.

And the first reaction is almost always the same.
You open the codebase and think,
"Who wrote this code?"
"Why is this such a mess?"
"I can do a lot better than this"
... something like this.

I too thought the same. And this reaction is justified. Because the first look is rarely pleasant. Confusing structure, outdated patterns, and code that feels impossible to reason about.

When I was first assigned to a legacy project, I wasn't excited at all.
It wasn't new, it wasn't shiny, and it definitely wasn't something I could show off. The codebase was large, the logic was spread across files, and even a small change felt risky. I kept wondering how anyone managed to build and maintain something like this.

It was a scary experience. For every small change, I've spent most of the time navigating the code than actually writing it. A lot of syntax actually felt unfamiliar to me. There was no package managers, no third party libraries, no proper documentation. Everything was written from scratch.
For a modern programmer like me, who uses third party libraries and packages for everything like it is normal, it definitely was a scary experience.

At first, everything felt difficult. Progress was slow and mistakes felt expensive. At some point, I even wondered, why aren't we migrating it to some new and shiny tech.

But as I spent more time navigating the codebase, reading, tracing, and understanding the processes, it started getting easier. I no longer felt lost every time I opened a file. I know where to look, which parts were fragile, and which ones could be changed safely. Debugging became faster, changes became more deliberate, and the fear of breaking things slowly faded away.

Working on legacy projects taught me many things. I no longer solely rely on third party libraries. I was realized package managers and libraries are good to have, but not necessarily needed. I got to know how systems actually work on ground level.

As I continued working on, I've started to admire the developers that built those systems decades ago, from scratch without any of the modern resources available to them. At first, I thought that the legacy developers only wrote messy code, but as time passes, I've started to appreciate the fact that they did their very best with the limited resources available to them amid tight deadlines and the effort they put into building everything from scratch.

Working on legacy projects made me a better programmer than I can imagine. It gave me the confidence to take up new challenges and work on new things. I am no longer afraid of working on things I don't know, because I am confident that I can learn.

Whenever I am assigned to legacy projects, I've started to look at them not as obstacles, but opportunities. Opportunities to learn more about complex systems and get used to the code of programming languages.

I no longer advise on migrating legacy projects into new stack. In fact, I advise against it. Because I believe that legacy projects are more stable than most of the project that are developed with modern tech stack.
For everyone who are working on legacy projects, I want to share some things from my experience.

Legacy projects are not obstacles for your career, but great opportunities for you to learn and grow.
Legacy projects are not outdated. They are just simple, boring and stable.
Legacy projects often lack good documentation, so when you are navigating through code, make sure to take notes properly. So that it may help you in the future or others who work on it.
When you came across tasks that couldn't be done using legacy stack, try to bridge that gap using modern stack. But don't actually try to migrate entire working system into modern stack, just because it's outdated.

Conclusion :

Legacy codebases changed the way I look at software engineering.
They taught me that good software isn't always clean or modern, but it's software that continues to deliver value overtime. More importantly, working on legacy stacks helped me become a better programmer and a better architect.

Understanding, maintaining, and improving systems that already exist is deeply rewarding. That's why, today, I genuinely enjoy working with legacy code.

I will be sharing my project updates, my weird ideas, and the systems I design here.

I’ve always believed that knowledge grows when it’s shared. That’s why I don’t like the idea of locking it behind paywalls. This blog is just me learning, building things, sharing what I learn and learning from others too.

If you’d like to explore more of my work, you can find it at https://bhaswanth.com
If you want to reach out to me directly, feel free to email me at talkto.bhaswanth@gmail.com

Please let me know your thoughts in the comments.

I've moved away from PHP and then regretted it

Bhaswanth Chiruthanuru — Tue, 03 Feb 2026 07:22:18 +0000

I started my career with PHP. I was pretty decent at building things.
Not the “copy-paste a snippet and pray” kind, but a real Core PHP, Laravel, full-stack developer building things end to end. And honestly? I enjoyed it.

Then the internet happened.

New frameworks started popping up like mushrooms after rain. Node.js, React, Vue, Angular, Next.js and the-next-big-thing.js. And along with them came articles. Oh, so many articles.

“PHP is dying.”, “PHP is a dead language.”, “Serious developers don’t use PHP.”,….

Naturally, like a responsible developer who clearly has free will, I believed all of it.

I looked at PHP. The language that paid my bills, shipped my projects, and quietly did it job and said: “You are dead to me”. And I left.

At some point, I just decided PHP was obsolete. I didn’t analyze it deeply. I didn’t question the narrative. I just assumed that moving forward meant moving away from PHP. So I did.

After that, I worked with different technologies like Django, Spring Boot, Node.js. Modern stacks. Enterprise vibes. Serious developer energy.

At first, it felt great.
Everything was shiny. Structured. Opinionated. Respectable.

With Node.js especially, things felt fast and powerful. Javascript everywhere. One language to rule them all. The dream.

Until the projects grew.
Suddenly. The server always needed to be running. The configuration files multiplied. Small changes required touching five different layers and work that took one unit of effort in PHP now took two in Node.

Nothing was wrong, but nothing felt right either. I wasn’t building anymore. I was managing complexity.

I am not saying those technologies are bad. They are not. They exist for a reason, and they do their jobs well.

Then at some point, I realized I wasn’t enjoying the process anymore. I was solving problems? Yes. But I wasn’t building the way I used to.

Then I touched PHP again.

Not out of loyalty. Not out of nostalgia. Just because it made sense for a project.

With PHP, I didn’t need permission. I didn’t need a running daemon. I didn’t need to negotiate with a framework to do simple things.

I wrote code. The code ran. I shipped features.

I had control.

From scratch, from nothing, request comes in, response goes out, logic in between. No ceremony. Simple. Clear. Predictable. No ego. Just clarity.

I could start from nothing and build exactly what I wanted. No friction. No feeling like the tool was deciding things for me.

The hatred I once had for PHP slowly evaporated. Not because PHP changed dramatically. But because I did.
I finally understood its value after walking away from it.

The truth is, many of us don’t leave technologies because they fail us. We leave them just because the internet tells us we should. Because trends move. Because being “modern” feels safer than being honest about what actually works for us.

For me, PHP works. Then,

I stopped chasing trends.
I stopped needing validation from from tech Twitter.
I started respecting tools for what they enable, not how fashionable they are.

I am not claiming it’s the best language. I am not saying other stacks are wrong. They are great. For the problems they were designed to solve.

But for the kind of web projects I build, the way I think and the way I like to work. PHP feels like home.

If I want to build something on the web tomorrow. PHP will be my first choice. Not because it’s popular. Not because it’s fashionable.

But because it gives me freedom.

And at this point, that matters more than trends.

Conclusion.

I am still working on PHP. For my personal projects. For me PHP continues to be my first choice for building web applications.

From now on, I will be sharing my project updates, my weird ideas, and the systems I design here.

If you’d like to explore more of my work, you can find it at https://bhaswanth.com
If you want to reach out to me directly, feel free to email me at talkto.bhaswanth@gmail.com

Please let me know your thoughts in the comments.

Revolutionizing JavaScript Form Validation: Introducing FavJS

Bhaswanth Chiruthanuru — Sat, 10 Feb 2024 17:37:26 +0000

In the world of web development, form validation is a crucial aspect of creating user-friendly and secure applications. As developers, we're constantly searching for tools that simplify our workflow and enhance our productivity. But what happens when the perfect tool doesn't exist? You create it yourself.

Introducing FavJS - a lightweight JavaScript form validation package born out of necessity and a passion for innovation. As a former PHP developer transitioning to JavaScript, I found myself longing for a validation solution similar to Davide Cesarano's Validation library for PHP. Unable to find one that met my needs, I decided to build it myself.

FavJS isn't about reinventing the wheel; it's about refining it. While it may not boast the extensive features of other validation libraries, FavJS is crafted with simplicity and effectiveness in mind. With basic rule validation and customizable error messages, FavJS empowers developers to handle form validation effortlessly in their JavaScript applications.

But here's where it gets exciting - I want your input. FavJS is a collaborative project, and your feedback is crucial in shaping its future. Whether you're a seasoned JavaScript developer or just starting out, your suggestions for improvements are invaluable. Let's work together to make FavJS the go-to choice for JavaScript form validation.

So, what can you expect from FavJS?

Simple and intuitive syntax that makes form validation a breeze.
Basic rule validation out of the box, with room for customization to suit your specific needs.
A lightweight and dependency-free solution that won't weigh down your projects.
An open invitation to contribute your ideas and suggestions for improving FavJS.

Ready to join the revolution? Check out FavJS on GitHub and become a part of the journey to revolutionize JavaScript form validation: https://github.com/bhaswanth53/favjs

Let's shape the future of form validation together with FavJS. Your input matters. Let's make it happen. 💡