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 :
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 :
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.