If you’re a developer, you need a personal website. While billionaire-owned, algorithm-based social media platforms arbitrarily decide what people should and should not see on their timelines, there’s no better time for you to carve out your own cozy corner on the web and own your content.
Why you need a personal website
Your personal website is your personal showcase: a one-stop-shop to show off your work, skills, personality, and ✨aesthetic✨. You could use your personal website as a place to collect what you’ve learned and what you’ve built over the years, whether that’s through traditional blogging or creating interactive demo pages. Or you could use it to build community through shared interests, to land that exciting new job, as a place to improve your refactoring skills, as an archive for your weekly newsletter, to test-drive Test Driven Development, or to build a proof-of-concept of something that really excites you.
Your personal website is also a great place to use as a playground for new and experimental features on the web, to try out new UI component frameworks or CSS methodologies, or to stretch the boundaries of what’s possible in a browser.
Personal websites are low-risk, high reward
Think of your personal website as a super low-risk test environment where you can build anything you ever dreamed of without having to worry about deadlines, stakeholder management, or client feedback.
And because a personal website is usually low-risk (i.e. there’s no P0 panic if you find a bug or it goes down) it’s also a great tool to help you learn about web performance. Through using a variety of tools such as Google Lighthouse, built-in browser dev tools, or an Application Performance Monitoring tool like Sentry, you can use your personal website to identify common performance issues and experiment with different fixes to see what gets the best results. What’s more, you can transfer all that learning to the things you build in your day job. And if you are using your personal website as an online resume, you’ll make a better first impression if it loads quickly and feels fast to use: win-win. (As a hiring manager in the past, I definitely inspected the DOM and the network tab of candidate websites.)
If you don’t yet have a personal website, go make one! It could be as simple as a single page of HTML deployed to a CDN. And then come back to check out these five easy tips for speeding up your personal website performance that you can apply to any website, project, or product.
1. Serve static HTML as much as possible
It’s too easy to render pages on the server in 2024. Most modern JavaScript-based frameworks come with pre-built adaptors to be able to deploy and server-side-render (SSR) your websites on demand using your preferred hosting platform. We also have edge-rendering and edge functions that allow us to intercept HTTP requests at the edge (the closest server location to the request) to add even more dynamic content to our pages based on geolocation, cookies, and more. But all of this comes at a cost — most notably to performance and your Time to First Byte (TTFB): the time it takes for the browser to receive the first byte of content from the server. (And let’s not forget the ongoing, and sometimes unexpected, monetary costs of running SSR.)
A brief history of the web
The web moves in cycles. In the 1990s the web was mainly static, delivering plain HTML documents that were stored on servers somewhere in the world; this was the Read Things era. As the web became a place where you could now do things (such as sign up and log in and CRUD), SSR — building pages on the server before sending them back to the browser — was necessary. In the early 2010s when JavaScript was more widely adopted, client-side-rendering (CSR) — sending a blank or skeleton HTML document and then building the page content in the browser — became the norm. The issue was that people still needed to read things on the internet as well as do things. And with the rise in SSR and CSR, reading things started to feel slow. In the mid-2010s, the modern web offered up a modern alternative: static site generators.
Static site generators make fast sites
Static site generators (or early “front end frameworks”) provided developers with a way to build a folder full of HTML files, each populated with the required page data at the time of build. Developers could now create tens of thousands of static HTML pages, stick them on a Content Delivery Network (CDN), and not have to worry about maintaining servers, scaling for traffic, or security policies. This was the beginning of Jamstack.
Fast-forward ten years, and “Jamstack” may be considered dead as a concept, but the principles of serving cached static content from a CDN for secure and performant websites still hold true. Serving static HTML files is much more performant than generating web pages on demand on a server for every request. This is because the server doesn’t need to do anything apart from retrieve your HTML document from the cache and send it back. No business logic, no database queries, no delays. Of course, there are times when you may need some level of dynamic page content. But on a personal website, you probably don’t need SSR.
You probably don’t need SSR
What has been interesting to observe is how the rise in popularity of “full stack front end frameworks” such as Next.js has started to promote using SSR methods and even edge-rendering over serving static content. What I also observed in the mid 2010s is that Next.js was originally marketed as yet another static site generator, encouraging developers to use dynamic page generation sparingly. But now, many blog or personal website templates built on frameworks like Next.js often come with SSR as the default page behavior. But content-based websites — which most personal websites are — don’t need SSR. Personal websites usually involve reading things, not doing things.
If you’re currently using SSR on your personal website, ask yourself if you really need to. By pre-building and serving pages statically I guarantee you’ll see performance gains. Take for example a case study on my personal website which should convince you. Over the years I experimented so hard with Edge Functions to add some dynamic elements to my static personal website that I pushed my p75 TTFB up to almost 4 seconds. I was devastated to learn this. Read how I improved the TTFB by 80% and if you want a spoiler: I just built the pages statically again.
2. Optimize images
Even if it’s just a headshot somewhere on your “about” page or a meme on your homepage, you’re probably using images on your personal website. Images are everywhere on the web. And they need to be optimized. But what do we mean by optimizing images?
Serve images in next-gen formats
If you’ve analyzed your personal website performance using Google Lighthouse, you might have been given the advice to “serve images in next-gen formats”. Next-gen (next generation) image formats are file types that use modern image compression algorithms, resulting in smaller image file sizes. This, in turn, results in better web page performance given the web browser has fewer bytes to download per image. Instead of serving PNG or JPEG image file formats, it is recommended to convert those to webp or avif file formats. Additionally, if you want to serve an animated gif, convert it to a webp file, which will preserve the animation while reducing the file size by almost 90%. Here’s a throwback to when I discovered this in 2021.
How to convert your images to next-gen formats
Depending on your preferences and how many images you need to optimize, you can use offline tools, build-time tools, third-party services, and image manipulation APIs to convert your images to modern formats on your personal website. Also, bear in mind that not all browsers support avif and webp image formats just yet, so it’s important to use the HTML <picture> element to allow the browser to choose the most appropriate image file format to download and display.
Lazar guides you through all the low-effort image optimization tips you need to make sure your personal website stays in good shape, with some bonus advice on how you can monitor your website performance using Sentry in terms of image resources.
3. Use system fonts
It’s too easy to use Google fonts. Choose a font and slap a link to the font file in the head of your pages. Done. The hardest part is deciding which fonts to use. And I get it. Fancy fonts look great. But do you really need custom fonts? Like really, really? You could get a huge performance boost by using system fonts. No downloading, no layout shifts, no flashes of unstyled content.
If you do want to use non-system fonts, it’s recommended to serve font files from the same server as your website, rather than ask the browser to fetch them from a third-party service at runtime such as Google. While you can download font files from the Google Fonts website and serve them yourself instead of linking to them, you’ll still have to convert the provided ttf font files to file formats required for the web (woff and woff2). In the past, I’ve always used Font Squirrel Webfont Generator to do this, but in 2024 this feels hacky. In my experience, Font Squirrel tends to do weird things with variable font files (which you should also use to improve your website performance).
I’m not sure why we haven’t solved the font file format problem yet. And because the best network request is the one that’s never made, why not scrap the custom fonts altogether and just use system fonts? You may fret that your website might look different on MacOS, Linux, and Windows, but maybe that’s the fun of it. And system fonts are no longer limited to just Times New Roman and Arial. Modern Font Stacks shows us just how good system fonts can look in context.
Lazar goes deeper into the web font conversation in Web Fonts and the Dreaded Cumulative Layout Shift.
4. Remove render-blocking resources
In 2022, I refactored my personal website from Next.js to Eleventy. This decision was centered around being able to know exactly what files were being delivered to the browser so that I could keep tabs on performance. With Next.js I noticed my website was making over 30 requests for separate chunked JavaScript files for a static page with no interactivity. It didn’t make sense. That same page created with Eleventy served no JavaScript files, which is correct — because the page didn’t need any JavaScript. All this is to say that as a responsible developer, you should be aware of what you’re sending down the wire to your users — especially if it ends up being a render-blocking resource. I made a YouTube short about this in 2022 to show the difference in what the two frameworks delivered to the browser.
A render-blocking resource is as it’s described: a downloadable resource that blocks the render (or “first paint”) of a web page, delaying the time that a user sees something in the browser. The more render-blocking resources that stack up on top of each other, the longer your page takes to load, and the worse your First Contentful Paint (FCP) web vital score will be. Google stipulates that to provide a good user experience, web pages must have an FCP of 1.8 seconds or less.
There are render-blocking resources we can’t escape, such as CSS (both inline CSS and CSS contained in stylesheets), but your website may have fallen victim to other render-blocking resources loaded via <script> tags in the <head> of your website pages. Take for example when the SyntaxFM team at Sentry discovered a 4kB render-blocking script that added around 500ms to each page load on average.
It may be that some of your dependencies need to be render-blocking, and that’s fine. But by considering the impact of render-blocking resources and being mindful of how and when you load JavaScript every step of the way, you’ll most likely be able to keep your Core Web Vitals scores looking good. Google offers more advice in this article on how to eliminate render-blocking resources.
5. Use less JavaScript
I am once again going to reference this evergreen piece of advice from Cassidy Williams in an article on CSS Tricks: “Your websites start fast until you add too much to make them slow.” When reaching to build that next feature on your personal website, ask yourself, can you do it without JavaScript?
Perhaps you want to build a contact form. You don’t need JavaScript for a form. How about using native HTML form functionality which includes HTML5 field validation? Why not go wild and just include a mailto link?
You probably don’t need JavaScript to achieve many modern UI animations. CSS is super-powerful these days, and I’m always looking for opportunities to use some of the newer features, such as scroll-snap-type.
You can even almost create a CSS-only masonry layout. The technology is still experimental, and in Safari Technical Preview, but let’s hope it’s coming soon.
And if you’re thinking about rendering some UI components using JavaScript on the client — can you build those components using static HTML, instead?
Challenge yourself to add less.