Website refresh - part 2
At the end of 2025 I did a website rework, switching from my old Hugo + ForestryCMS stack to TinaCMS + Astro & QwikJS. As one of the main goals in that rework was to hit a perfect Google Lighthouse score, and I actually managed to do that, but despite the speed, there were still some issues (or features, however you like it) that needed to be adressed.
Lets go through my findings!
Goals
I had a pretty clear vision on what I wanted of my "round two" of my new website.
- Even better Lighthouse scores (target lower digits)
- Potentially change stack to QwikCity
- TinaCMS visual editing
- Resolve MDX renderer issues (eg. 2nd level lists were not working)
and ontop of these I had a nice to have feature that is still to be implemented:
- Search feature
The QwikCity experiment
As I already used Qwik in all the components on the site, and its Astro support was in Alpha/Beta state when I initially took it to use, I thought that perhaps doing everything the "Qwik way" would result in some improvements in speed, or at least simplifying the logic of my setup. As I discussed about this in the QwikJS Discord, one user pointed me in the direction of a repo that actually used QwikCity, all components as Qwik components, and TinaCMS visual editing was working flawless. As you can guess, I was hooked!
I pulled down the repo and started digging in. With the help of various LLMs, copying my content, structure and components over to this new base went very easily. As this was a test, I worked on this in a new repo to keep things clearly separated. It didn't take long before I had most of the features done. Migrating the content turned out to cause some headache as the MDX structure was not identical, 90% of the content migration went smoothly, and rest of the content needed special attention.
Alright!
So now I had my site running on QwikCity, looking identical as before, but having also the visual editing possibility. I was ready for the Lighthouse test. I ran it and the result was ... the same as before...
Turns out that in the midst of seeking the best bleeding edge stack to get maximum performance and/or feature benefits, I was fully oblivious to the main reason you want to use static sites, having the site be static. It turns out that it doesn't really matter how fast or slow your static site generator (SSG) is as long as the output is optimized.
In my case, we had the potential to get some benefits from having less wrappers for components, but the results speak for themselves as there was no clear benefit with the stack change. I do also prefer Astro over QwikCity as Astro's more flexible and has a more mature ecosystem, it's clear that the insignificant benefit that I might get right now from QwikCity is not worth it.
TinaCMS visual editing in Astro
And we are back with the old Astro site. Since I had experienced that QwikCity was possible to run with TinaCMS visual editor, I knew that Astro must also be possible to have run that way somehow. As the trend goes nowadays, I put a LLM working on said task, and after several trial & error iterations, we had the visual editor working in the same was as with QwikCity, this was (for the moment) my final nail in the coffing for QwikCity.
Content and parsing fixes
My old content parsing logic worked in a way that I turned every element into a JSX element, and this simplified the rendering logic for the most part. This still caused some issues with elements being at a depth, so eg. a list withing a list was not possible, and the LLMs of 2025 Q3 were good helpers but not yet so good that they wouldn't make mistakes in a niche-stack repository, hence the solution I had was hand made. It was time for the 2026 LLMs to give a shot!
It turns out that by simplifying the render logic and not doing the JSX-wizardy, the rendering of content sections started working properly! This is a good reminder that if you can do something in a simpler way, it is probably worth doing so.
While I was up to speed with the LLMs, I also had them cleanup unused CSS and deps. I also asked for a optimixation plan, but any potential speed/performance boosts that we tried applying were causing a lacking user experience or breaking the site. I knew that there was not much to be gained, but felt that it was worth a shot.
Search feature (drafted)
i've been thinking if I should have a search feature on my site. I do feel that I don't have too much content on this site, but if a user were trying to find something about tech/coding, a search could guide them in the right direction eg. to my CV or to some blog post about some mundane topic.
I got quickly drafted a initial version of the search, only missing microanimations to finalize it. I'm still tho twosided should I even have a search or not. Right now it's still drafted, but what do you think, should I implement it or not?
Final yappings
This update post was quite not dramatic, but I did learn my lesson with the static site logic.
I did also try various LLMs and services to redesign my site, but none of the redesigns really felt like "me", so I'm sticking to my old precious super barebones styles that I've used for years.
As for the text contents, I still write my blog posts by hand, and use AI to just polish the texts and handle typos. I feel that as content generation is easier than ever, having your own tone of voice brings a certain kind of human touch to the content.
It's odd that you kind of start to appreciate the non-perfect output since it sounds human, and that's the way I want to keep on making these blog posts.
