Performance is not a technical problem. It’s an architecture one.
This site is a Hugo build deployed to S3 behind CloudFront. No servers, no containers, no runtime sitting there waiting for a request. Just files on a CDN. I use the S3 website endpoint rather than the REST API, which means Hugo’s pretty URLs work out of the box. /about/ resolves to /about/index.html without a Lambda@Edge function or redirect rules. One less thing to break. One less thing to add latency. One less thing to pay for. Deploys are a build, a few aws s3 sync calls, and a couple of CloudFront invalidations. The whole thing takes a few seconds to run.
The CSS and JavaScript follow the same logic. Minimal and custom, everything written for this site and nothing else. No frameworks, no utility classes, no external libraries. The one exception is PhotoSwipe, which handles the lightbox on gallery pages and is only loaded there. There’s also a cookie consent script on every page. If you accept, it loads Google Analytics. If you decline, it doesn’t.
The same care goes to images and caching. All images are processed before upload, resized to the appropriate size and most of the time converted to WebP. I configured CloudFront to use origin headers, which is why I sync content as a series of aws s3 sync calls instead of just one. Each kind of content gets the right headers to control how long it stays cached in the CDN and in the browser.
Today I ran it through PageSpeed Insights. The homepage and a single gallery page (image-heavy, worst case) both score 100 on mobile performance. But the score isn’t the point. It’s a characteristic of a stack where everything is crafted to its purpose.