Website redesign
Introduction
My website is my personal space, the only requirement is to follow my taste. This allows me to experiment with different ways to develop. Here, I choose not to use any framework, first because it is more fun and second because that allows me to understand how things work under the hood. In a world of web development that is full of frameworks and convoluted setups, it is quite an experience to go back to the roots and develop a website that is light, fast, and simple.
Workflow
I write the HTML files directly with a script to update the files, build and deploy them in AWS. I use a small HTTP server to test it locally, the JS and CSS are referenced in the HTML and run directly without a transpilation step. This allows me to add the source folder to the browser developer tools and have the changes made in the tool saved directly in the files. It is like getting HMR (Hot Module Replacement) for free and you don't have to copy and paste from the tools to the source code.
The include problem
The pages of a website have a lot of duplicated code. For example, the header, style, and meta tags should be the same. It is tedious to copy and paste this code on all pages, especially when you want to make changes, because you will have to remember to change it everywhere.
Instead of generating the code for all the pages with an SSG (Static Site Generator), I have a small script that finds the HTML files, parses them, and uses CSS selectors to find the elements that need to be updated. I use the home page as a reference, making sure that the only thing that changes between pages is the content. I also save the content in a separate file to make the SPA (Single Page Application) more efficient. And I even update the image tags with the correct width and height.
Performance
I ran a small experiment. I generated files ranging from 1KB to 1MB and measured the time it took to download them on cellular data.
The chart shows a linear relationship between the size of the file and the download time. The bigger the file, the more time it takes to download. However, a 100 times larger file does not take that much more time to download. Therefore, it is better to download one 100KB file than two 50KB files sequentially, one after the other.
This is the waterfall problem that we have in modern webpages. The browser first needs to download a small HTML file to then become aware of the CSS and JS files it needs to load. This problem is even worse because the user can only see the content on the screen after the JS is executed. This problem is mitigated by running the JS on the server, SSR (Server-Side Rendering) and HTTP/2 Server Push.
Since I don't have a lot of code, I can include all the code required to display the content in the initial HTML. For example, I inline the CSS to avoid this waterfall problem and I don't need the JS to render the content because I work with the HTML directly. This way, as soon as the first HTML file is received, the user can already see and interact with the page.
Single page application
Since all the pages exist and have their content updated during development, the website works even without JavaScript. However, it would be nice if, when navigating, instead of loading a new page, only the necessary content to display the next page would be loaded.
To accomplish this, I wrote a simple script that adds an event listener to the links. It fetches the content of the page you are trying to navigate to and simply replaces the content area with the HTML from that file. I also pre load the content on hover to increase performance. That way, if you have JavaScript running, your experience will be a little bit better, but if you don't, that's okay as well.
I also got code splitting for free. Since the content of the page is the only thing that changes between pages, if I put a script tag in the content of a specific page, it will be loaded only on that page. This page, for example, has some code to render the charts. That code is only present and loaded on this page.
Conclusion
It's interesting how by not using frameworks, you get some features for free. What is happening is that frameworks sometimes solve problems they themselves create. I am glad with the results and I got 100% on Google PageSpeed Insights. I hope that this setup is easy to maintain with as little configuration and code as possible, avoiding dependencies that need to be updated from time to time.