How much JavaScript do you actually need? And what for?
Since I’m living in Barcelona, I visit comedy/storytelling events from time to time. However, I was having some trouble with which event was what day as they all had different Facebook pages, etc. Then I remembered I was a developer and decided to create a simple list with all the upcoming events myself. As I wanted to create something quickly, I decided to bootstrap a project with Next.js so I could use both server-side and client-side React.
Getting the data
As you might have already assumed, I used Facebook’s API to get the event data. I could’ve used one or another NPM package to fetch the data easily on a request by request basis. This would’ve worked well together with how my project was set up, but it would’ve been a huge overkill. The data does not change that many times and also not based on user data or anything. That’s why I decided to create a CLI-script that could easily be run by a cronjob/CI system/(manually even??).
After that, I created a quick interface using some of the React UI components I released a long time ago. All went well, I had some index page and released this to production using now.sh. I was quite happy about the result and then I shared it with some friends.
Almost immediately after releasing this page, I got asked why the page was so slow. As a ‘professional’ Front End Developer, the last thing you want to hear is that your page is slow. I had to fix this… Somehow.
Does this actually need Server-side Scripting?
Server-side Scripting is really powerful nowadays. You could render the same component server-side as on the client-side. However, storing the data, filling in the data, rendering the components, assembling a page and sending it back is quite memory intensive. This was one of the reasons my page was quite slow. Was it actually needed? The page didn’t change that much.
To answer the question “Does this actually need Server Side Scripting?”, the answer was no. The page did not change based on user, session or related data and could be converted into a static page.
But it still needs to update, right?
To understand if I really really really needed server-side scripting, I tried to figure out under which circumstances the page actually needed to update. There was no perfect way, as I didn’t receive any updates from Facebook when an event got changed or was created. However, I assumed for the initial phase of this website, synchronizing once a day was probably enough.
So, rewriting all the code?
I still wanted to use react for code maintainability and also to use my UI components. I didn’t have to rewrite or change the code of the page, but rather the process on how it was being created.
The default Next.js setup I used, generated the pages on a request by request basis. I wanted to get rid of server-side scripting, so I decided to move this generation into the build phase of the project.
By using a simple CLI script I wrote, I could run React’s renderToString for each page that I wanted to create. The pages would be prebuilt before anyone requests them and the output got stored as plain HTML.
How does this update?
Now I got static HTML pages, which was great, but I also needed to update them somehow. For simply serving the website, I moved away from now.sh and decided to use Google Cloud Storage, as everything was static now.
To update the pages, I simply had to re-run my custom CLI script that generated the pages and uploaded them to Google Cloud. As this was already a simple script that had to run periodically, I decided to use Bitrise to solve this problem. Bitrise as one of many CI tools, that runs a script after each push or based on a time interval (which I needed).
By taking those steps, I was able to completely get rid of all server-side scripting and still getting the same page.
Does this actually need client-side scripting?
As the page straight up consisted out of some information and links, JavaScript was not a heavy requirement. My Next.js setup had lots of JS out of the box to hydrate and rerender components. However, none of that was needed for the initial view of the page. So, as you might’ve already gotten the vibe: I removed all of that as well.
Removing both server-side and client-side JavaScript on this page, improved the performance heavily (as expected).
I ran tests both through Google PageSpeed and web.dev and the results were amazing. On both websites, I received a score of 100 out of 100 and my Time to Interactive seemed to be 1.1s.
Should we go back to static websites?
Usually, I would answer that question with no, because most websites depend heavily on user data or are in several ways interactive. We should never sacrifice features and interactivity just for the sake of performance. On the other hand, there seems to be a crazy trend lately of using JavaScript everywhere all the time even when it’s not needed.
Years ago, server-side scripting was only used when absolutely necessary and JavaScript only got added in small snippets. Whenever Single Page Applications started to take off, more and more stuff got thrown into one single JavaScript file, slowing down websites drastically. Nowadays, a couple of years after that point in history, we found some ways of dealing with huge bulks of JS. For example, dynamic imports, which will split the JS into several files that only get loaded when needed. Also, service workers saw daylight, as an attempt to cache and control all resources better. All of these improvements are great, but sometimes they’re solving a problem that shouldn’t have been there in the first place.
In my opinion, every informative website (like the one I created) should be completely accessible without JavaScript. If there’s interactivity needed, fine, add it, but don’t block the page load. As proof of concept, I added support for soft links to my page. This is implemented with JavaScript, but will only be added after the page is completely loaded and is completely optional for interacting with the page. This principle can also be referred to as ‘progressive rendering’.
In short, only use JavaScript when you have to. And if you do add it, try to make it optional.
The website I was referring to can be found on https://expat.barcelona
