As snappy as I could imagine, and I hope that this will make a perceived difference for visitors.
While average internet speed might increase, I still saw plenty of people browsing websites primarily on their phone, with bad cellular connections indoor or via a shared WiFi spot, and it was painful to watch. Hence, my rewrite (still ongoing).
Do fellow HNers also feel the „need for speed“ nowadays?
Does the minification of the css make a big difference? I just took a look at it using an unminifier, and it was a nice change to see CSS that I feel I actually understand straight away, rather than thousands of lines of impenetrable sub-sub-subclasses.
Maybe it's me, but I originally learned that the concern of CSS is to make a document look pretty. Not magic CSS classes or inline styles (or both, this bugs me on tailwind), so the recent "shift" towards "classless css" is very appealing.
Sidenote: Yes, the screenshots could be way smaller, but originally I had them full-width instead of the current thumbnail, and still thinking about how to present this as lean as possible. Thanks for the feedback, though!
Will have a look, thanks!
But there's always room for experimentation.
How about preserving a copy of your portfolio page now (and the PNG files it's now using) and giving it an address like /portfolioOLD?
Then using an image editor, ruthlessly resize/resample-at-lower-bit-depth one of your PNG's so their actual rectangular pixel dimensions are about the same size that they appear on a full-size monitor now.
Then ruthlessly compress it until it looks just a little less high-quality than it does now. Just a little bit, you want to be able to tell the difference but you don't want other people to notice. These are just thumbnails anyway.
Use these editor settings on the rest of the PNGs, renaming them accordingly as you go.
Deploy the new portfolio page linking to the resized renamed thumbnails instead.
Just guessing, but I expect it can bring the load time down to about 10 percent of the old portfolio.
And it would be really easy for anyone to A/B test and get representative numbers.
This is how we used to party like it's 1999.
On the other hand, I really enjoy working with tailwind. Having html and css "together" works really well with my mental model, and I can iterate very fast with it.
Though setting up tailwind is a bit of a pain, and I still use sakura + good old css everywhere I possibly can.
It can shave 100 - 200 ms off the perceived load time, and since your site is already near or below that threshold it might end up feeling like you showed the page before anyone even asked for it.
The interesting thing for me is, while I personally certainly feel the "need for speed" and appreciate pages like yours (nothing blocked, only ~300kb), most people do not. Long loading times, invasive trackers, jumping pages (lazily loading scripts and images), loading fonts from spyware-CDNs - are only things "nerds" like us care about.
The nicest comment on my design I heard was "Well, looks like a developer came up with that" :)
I did the same for my website , and I hope this becomes more of a standard for "boring old" personal pages and blogs.
The cold loading stats:
Load Time 2.20 s
Domain Lookup 2 ms
Connect 1.13 s
Wait for Response 68 ms
DOM Processing 743 ms
Parse 493 ms
DOMContentLoaded Event 11 ms
Wait for Sub Resources 239 ms
Load Event 1 ms
DOM Processing 743 ms
Parse 493 ms
... I mean, it is just some quite light HTML and minimal CSS, right? what could possibly make your browser so slow at handling this?
It started downloading html, once it got the first byte it started processing it, but then it had to wait for the rest of the bytes (not to mention the css file to download).
The parent comment is clearly using some really slow wifi, so I think it's likely that's what happened.
Cold load stats:
Load Time 409 ms
Domain Lookup 37 ms
Connect 135 ms
Wait for Response 40 ms
DOM Processing 165 ms
Parse 123 ms
DOMContentLoaded Event 8 ms
Wait for Sub Resources 34 ms
Also, no share button. No top/recommended articles. No view counter.
Once you start adding medias it will be quite a bit slower. Once you start implementing basic features expected by users (comments and related articles for a blog) it's gonna be yet again slower.
I remember when my first article went viral out of the blue, I think have to thank the (useless) share buttons for that. Then it did 1TB of network traffic over the next days, largely due to a pair of GIF. That's how bad pictures can be.
All of which I can live without.
Still the best way of sharing content on the web is via a url, which is handily provided, so most of these aren't even needed. As for recommended and view counts, these don't inherently add a lot of value to users. If anything, it's a nice change to have a page that doesn't try and infer my desires for once.
A simple "last 5 articles" in the corner do add value. Users frequently read more than one article.
(As an aside - nobody nobody has ever derived value out of a page counter except the owner of the site - who could just look it up in the logs. This isn't really an argument against anything you mentioned but I found it amusing it was one of the things you brought up)
1. Mostly nobody - sure there were some folks, but then again I'd wager a significant portion of those folks were just loud voices echoing from the marketing department.
Myspace era wants their featureset back.
More seriously I think for personal sites a JAMstack site is perfectly sufficient
The other things you name are present on my other website (which I linked above). The site is still blazing fast.
Very basic but does the job I'd say. :)
Just wanted to let you know there's a typo @ https://anonyfox.com/tools/savings-calculator/
```Aside from raw luck this ist still the best```
Love the style though. Very crisp, very snappy.
I stopped using graphical browsers many years ago. I use a text-only browser and a variety of non-browser, open source software as user-agents. Some programs I had to write myself because AFAIK they did not exist.
The only speed variations I can detect with human senses are associated with the server's response, not the browser/user-agent or the contents of the page. Most websites use the same server software and more or less the same "default" configurations so noticeable speed variations are rare in my UX.
Have you found it easy to customize, or you went with the flow without getting too fancy?
AFAIK you can set custom variables in the frontmatter of the markdown files, your layout/template html can use them (or use an IF check, or ...).