HN

Comments (69)

• Menu

  Alifatisk
  The site is indeed instant, those performance tricks does work (inline everything, botli compression, cache, edge network like cdn), BUT the site is also completely empty, it shows nothing except a placeholder.Things can easily change when you start adding functionalities. One site I like to visit to remind myself of how fast usable websites can be, is Dlangs forum. I just navigate around to get the experience.https://forum.dlang.org
• Menu

  PunchyHamster
  One time I decided to check how much faster really you can go while still getting decent usability out of "simple blog platform" type of webapp.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 partcache could be easily kicked off to redis or similar but it's just text, there is no needFun 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.
• Menu

  cuu508
  > First visit: ~30ms. Real JavaScript executes at the edge.It appears to have static content. Why does it need any JS at all?
• yuvadam
  For static content this isn't fast.For a dynamic service, well.. maybe implement something of interest and then we can discuss.
• freetonik
  My blog directory/search engine [1] runs on Cloudflare workers as well. I was able to get pretty good results, too. For example, the listing of 1200+ blogs [2], each with 5 latest posts, loads in ~500ms. A single post with a list of related posts, loads in ~200ms. Yeah, it's still a lot, but it includes all the normal web app logic like auth middlewares, loading user settings, and states; everything is rendered server-side, no rich frontend code (apart from htmx for a couple of buttons to make simple one-off requests like "subscribe to blog" or "add to favorites"). A static page (like /about) usually loads in ~100ms.This is a bit stochastic because of regions and dynamic allocation of resources. So, e.g. if you're the first user from a large georgraphic region to visit the website in the last several hours, your first load will be longer.My other project (a blog platform) contains a lot of optimizations, so posts [3] load pretty much as fast as that example from the thread, i.e. 60-70ms.1. https://minifeed.net/2. https://minifeed.net/blogs3. https://rakhim.exotext.com/but-what-if-i-really-want-a-faste...
• ahepp
  > Immutable caching Cache-Control:max-age=31536000, immutableWhy brag about how it's not static content, if you're just going to tell the browser to cache it until the end of time anyways?
• Menu

  bryanrasmussen
  hmm, it seems the last static site I did is slightly faster https://nissestyrelsen.dk/ but probably just because it's hosted in country near me, if I was somewhere else probably much worse. Not that I care that much to really research it, I figure it's fast enough and just a funny idea.
• Menu

  onion2k
  Getting a site to load quickly isn't that difficult from a technical perspective. You just need to strip out everything that slows it down. If you can deliver a page of HTML and inlined CSS that renders without JS or images then your site will be fast (or at least it'll be perceived as fast, which is fine.) So long as you're using some fairly reputable hosting infrastructure (AWS, Azure, Google, etc), and if you're rendering on the server you're not doing silly things on the hot path, then you don't need to worry about speed.The hard part when it comes to site optimization is persuading various stakeholders who want GTM, Clarity, Dynatrace, DataDog, New Relic, 7 different ad retargeters, Meta, X, and probably AI as well now that a fast loading website is more important than the data they get from whichever of those things they happen to be interested in.For any individual homepage where that stuff isn't an issue because the owner is making all the decisions, it's fair to say that if your site loads slowly it's because you chose to make it slow. For any large business, it's because 'the business' chose to make it slow.
• Menu

  oefrha
  > ~2.5KB Brotli Smaller than most images.Brotli is so 2024. Use zstd. (73.62%, I know. Slightly worse compression ratio, I know that too.)
• 1317
  well yes alright but it would be more impressive if there was actually something interesting there to see
• liveoneggs
  These are not impressive numbers and, obviously, browser cache is fast.Pretty much any small payload/non-javascript site is going to render very quickly (and instantly from cache) making SSL time be the long pole.
• Brajeshwar
  This is interesting and need to look into.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.
• predkambrij
  Speed: 217ms 289msI have 5G network :)Also, heard multiple times that edge network can be worse, because if you're low prio and other part of globe is not busy, you get it routed in worst possible way.
• underdeserver
  First load took 3.8 seconds for me.
• RestartKernel
  Speed:- 3942ms- 4281msGuess it depends on your region. This is from East-Asia.
• meling
  Wish more pages were as fast as this, despite this site’s simplicity… In particular GitHub could really benefit from less bloat and faster rendering.
• dontlaugh
  Over 800ms is not even a little fast. I’m on WiFi to ADSL, lights static websites are way faster than that.
• s_ting765
  The perfect lighthouse score might have changed since this was last updated. Am seeing 97% on accessibility.
• Menu

  efortis
  another trick is adding speculation rules on MPA sites. so when you hover over a link the page gets prerendered. For example, my initial page takes ~80ms, but navigating to other pages take 20ms 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...
• vivzkestrel
  next stop: lets install nextjs and give it a try shall we?
• IshKebab
  What does this page do that needs workers though? Looks like it could be static HTML to me.I think most sites could either be static HTML and use a CDN, or they need a database and pretty much have to be located in one place anyway.It's quite hard to think of use cases where that isn't true.
• JodieBenitez
  It's not fast.
• Menu

  est
  I believe CF Page is faster.
• Menu

  Terretta
  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.
• Menu

  jasoncartwright
  Yeah, it's really quick because there is pretty much nothing on it
• TZubiri
  "TL;DR: This isn't a cached HTML file. Real code runs at the edge in ~30ms. After your first visit:~4ms from browser cache!"Maybe add some dynamic feature for the demo so that we don't need to trust you and be surprised at a nothingburger.
• doublerabbit
  "A super fast static website using Cloudflare workers"Add imagery and see if you get the same results. I expect you could achieve such with Base64 but the caveat would be larger file sizes.
• aleksandrm
  Is this real?