dev log 2
- The last 30-day devlog was fun, but my main goal there was not being consistent every day but to get to day 30 and learn 30 new things. This time I want to take it a notch up by trying to be consistent for 30 days and also learn newer things over next 30 days.
Jump to: Day 1 | Day 2 | Day 3
day 1:
learning about frontend web performance was sitting in my to learn list for a very long time and I do have my personal site up and running with content constantly added into it so I started to learn how to improve my static site performance to. got to know about unlighthouse (lighthouse for your entire site) ran that to see our baseline lighthouse performance is roughly about 80%
To do any of these I need to learn the bits and bytes of web performance, so I started off with understanding HTML performance considerations like ETAG, last-modified, max-age=n, Brotli compression over gzip, and static and dynamic compression. I also learnt about the critical path as well as understanding render blocking vs parser blocking.
day 2:
Today I spent roughly 6 hours continuing to go deeper into frontend web performance exactly where I left yesterday. Learned about how to optimize resource loading (HTML, CSS, JS), what are the problematic CSS syntaxes and why it is problematic, how JavaScript works when a request is sent, as well as how to prevent parser blocking. Got to know about various resource hints like preconnect, prefetch, dns-prefetch, and fetch priority tags. Got to know about image and video optimization techniques and how they affect the Cumulative Layout Shift (CLS) metric and load time. I figured out image optimization just via common sense because data is travelling via the network so smaller image size = better, but at the same time got to know about the AVIF format. Next, I tried to understand how to optimize web fonts (woff2). I used to write font-display: block for years but today is when I went ahead and learned what it does as well as various other font-display values like swap, fallback, optional, etc. The final big learning for the day was getting comfortable reading flame graphs. Today was the first day I opened a tab other than the network tab, and the Chrome DevTools performance tab is incredibly good. At first it felt intimidating, but after going through all the basics from yesterday I was able to read the flame graph and point out what’s going on. Fortunately, I have this very simple website to understand its flame graph and try to optimize (that’s for tomorrow), but after reading the flame graph I can now clearly see what parts need to be optimized in this blog to still improve its performance. Unlike other static sites, I just can’t directly change the code because my whole website is generated through my very own markdown-to-HTML engine and I have to figure out a way to make sure the engine does most of the optimizations that I am planning to do. So tomorrow is going to be interesting.
some of the resources that I used today to learn:
https://developer.chrome.com/docs/devtools/performance/reference https://nitropack.io/blog/chrome-devtools-performance-tab/ https://calendar.perfplanet.com/2025/chrome-devtools-for-debugging-web-performance/ https://www.debugbear.com/blog/fix-web-performance-devtools
day 3:
Today I spent my time on image optimization. Wrote a new module in my markdown parser to now convert source images in my markdowm files into WebP, also adding the ability to resize images.
"image": {
"enabled": true,
"outputFormat": "webp",
"backupOriginalFormat": true,
"quality": { "webp": 82 },
"presets": {
"banner": { "width": 1600, "breakpoints": [480, 800, 1200, 1600], "loading": "eager", "fetchpriority": "high", "sizes": "100vw" },
"content": { "width": 800, "breakpoints": [400, 800], "loading": "lazy", "fetchpriority": "auto", "sizes": "(max-width: 800px) 100vw, 800px" }
}
}
Added this new configuration where you can specify the output image format. backupOriginalFormat: true will back up the source image so if you use a newer format like AVIF in a legacy browser that won’t support it, it will fall back to the good old JPEG or PNG. You can also configure the image quality for compression. The presets part was slightly difficult to figure out on most pages of my website I have a banner image which is some random manga panel or meme, and then there are other content images. The banner can be optimized differently by prefetching since it’s what users see in their initial viewport, while content images can be lazy-loaded at a smaller size, etc (thanks to the yesterday readings!). So I created presets and you can wire them up as part of the frontmatter. This also helps reduce the CLS score.
Also, there can be cases where individual images need to be resized, so I added a query param-style option to resize individual images as well. For example,  will have a width of 400 after rendering as HTML. Also did setup a cache to not convert images again and again. It was fun to again go back file level cache where I SHA’d the source file along with the format and size and wrote it into a file so if the SHA matches we skip. This was all I was able to do today. Tomorrow I need to refine the engine to handle all possible edge cases.