I decided to go check my website’s PageSpeed and I do have a 100/100/100/100 with pretty lots of content on the homepage including 6 separate thumbnails.
My site is on a straight path, no tricks — Github Pages Served to the Internet by Cloudflare.
11–20 of 83 posts
I decided to go check my website’s PageSpeed and I do have a 100/100/100/100 with pretty lots of content on the homepage including 6 separate thumbnails.
My site is on a straight path, no tricks — Github Pages Served to the Internet by Cloudflare.
Speed: 74ms 241ms … LOL … These 30 ms and 4 ms numbers were typical Apache to Netscape from MAE East and MAE West in 1998. Twenty five years and orders of magnitude more computing later? Same numbers.
But now it's that fast from almost everywhere on the planet, with nearly zero effort from the developer. We've been limited by light speed here, not compute.
End result, written in go, did around 80-200us to generate post page and 150-200us (on cheap linode VPS... probably far faster on my dev machine) for index page with a bunch of posts.
Core was basically
* pre-compile the templates
* load blogpost into RAM, pre-compile and cache the markdown part
cache could be easily kicked off to redis or similar but it's just text, there is no need
Fun stuff I hit around:
* runtime template loading takes a lot just for the type-casting; the template framework I used was basically thin veneer over Go code that got compiled to Go code when ran
* it was fast enough that multiple Write() vs one was noticeable on flame graph
* smart caching will get you everywhere if you get cache invalidation right, making the "slow" parts not matter; unless you're running years of content and gigabytes of text you probably don't want to cache it anywhere else than in RAM or at the very least have over-memory cache be second tier.
The project itself was rewrite of same thing that I tried in Perl(using Mojolicious) and even there it achieved single digit ms.
And it feels so... weird, using webpage that just reacts with speed that the well-written native app has. Whole design process was going against the ye olde "don't optimize prematurely" and it was complete success, looking at performance in each iteration of component paid off really quickly. We got robbed of so much time from badly running websites.
Speed: 74ms 241ms … LOL … These 30 ms and 4 ms numbers were typical Apache to Netscape from MAE East and MAE West in 1998. Twenty five years and orders of magnitude more computing later? Same numbers.
But now it's that fast from almost everywhere on the planet, with nearly zero effort from the developer. We've been limited by light speed here, not compute.
Getting it closer can save you 50-150ms, but if whole load takes 1s+ that's minuscule
It appears to have static content. Why does it need any JS at all?
prerender: [
{
where: { href_matches: '/*' },
eagerness: 'moderate'
}
]
That doesn't work on Safari, FF, and Brave, but you could do something like this:https://github.com/ericfortis/mockaton/blob/main/www/src/_as...
Brotli is so 2024. Use zstd. (73.62%, I know. Slightly worse compression ratio, I know that too.)
Earlier quoted context omitted.
But now it's that fast from almost everywhere on the planet, with nearly zero effort from the developer. We've been limited by light speed here, not compute.
nah, most sites are fat enough that both bandwidth and compute is the limit. Getting it closer can save you 50-150ms, but if whole load takes 1s+ that's minuscule
> First visit: ~30ms. Real JavaScript executes at the edge. It appears to have static content. Why does it need any JS at all?