new type of demo page: non tiny load, non pure text

[hpvd]

would be interesting to see another type of demo page for ts-liveview: a typical real world example, a simple looking blog page, consisting of

• page headline
• text using
• a nice webfont (locally served) e.g. https://fonts.google.com/specimen/Open+Sans
• 2 large high quality images (photos)
• with an image caption for each and
• alt text

where

• only one image is loaded and visible directly, while the second one is loaded in background and can be made visible clicking on an element e.g. arrow (cyclic)
• the images are loaded only in the size (quality/resolution) variant needed, depending on
  • used layout size and
  • pixel density

the goals would be

1. to work with a non tiny, non pure text load (font and images)
2. look into/decide if
   • one should/could server-site choose the image variant to be offered/ pushed to client (browser) OR
   • if it should remain a browser choice (pull) like done on all static sites OR
   • some kind of hybrid
3. to in consequence only download as many bytes as needed (as on all pages)
4. demonstrate good caching while navigating back and forth between
   • images (same page) and
   • all pages of demo (for everyone experience-able -> speed)
5. evaluate how it's possible in detail, to achieve same stunning lighthouse rating like for the other, mostly text based types of pages https://github.com/beenotung/ts-liveview/issues/18 in categories
   • performance
   • accessibility
   • seo

[hpvd]

bump, clarified some details in post above (via edit)

[hpvd]

Maybe... one day... if one do not have to wait for the ws connection to be established because one use http/2+ see https://github.com/beenotung/ts-liveview/issues/13 maybe it makes sense, to

1. let the page start to render in the browser using a tiny inline, with css blurred, prebuild preview of the image (base64 coded on base of a down-scaled image variant) and
2. report back the needed image size (based on screen density and rendered layout) then
3. provide the smallest possible needed image variant,
4. load it and
5. swap preview image to real image.

Or going even further, one also take the network speed into account and deliver a somehow reduced quality on slow networks... -> a server side approach would make this possible..

maybe this is overengineering, but maybe it's worth it ;-)

[beenotung]

let me reply in batch:

1. agree it'd be nice to make some typical demo sites with images (blog site, landing page, content funnel , e.t.c.).

Also, I'm working on a progressive enhanced live chatroom with ts-liveview based on the v5-auth-template, will open source it soon

In addition, I will link to a mini board game demo in the readme as well.

It seems I'll need a better way to organize / present the demos.

2. for optimal image loading, we should be able to do it without client-side js using html build-in support on responsive image

It would be interesting if we can go further when handling the initial GET request based on given user agent.

3. for blurry initial image, this topic is discussed on hacker news recently as Evan shared his work on thumbhash. This approach seems controversial but it doesn't hurt to experiment with it as long as it's an opt-in component

[hpvd]

great to read this! Looks like we are thinking in the same direction.

for responsive images, there is a good overview in: https://css-tricks.com/a-guide-to-the-responsive-images-syntax-in-html/

Thumbhash looks interesting. I stumbeled across Blurhash before, which does something similar (with lower quality) -> I came back to the good old base64 variant for preview (based on a low resolution variant of the image) of this type <img src="data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAkAABAALAAAAAAQABAAAAVVICSOZGlCQAosJ6mu7fiyZeKqNKToQGDsM8hBADgUXoGAiqhSvp5QAnQKGIgUhwFUYLCVDFCrKUE1lBavAViFIDlTImbKC5Gm2hB0SlBCBMQiB0UjIQA7" alt="star" width="16" height="16">

because I was wondering about the additional size of the decoder needed to be able to use this advanced solutions (thumbhash/blurhash) on a website. Do you have any information on this?

[hpvd]

Thumbhash really looks far advanced compared to Blurhash (quality/feature set)

regarding size, it looks like encode and decode seems to fit into 10KB ? https://github.com/evanw/thumbhash/blob/main/js/thumbhash.js

[hpvd]

regarding Blurhash:

Update: Since writing this, I’d no longer recommend Blurhash. It requires client-side JavaScript and tags to display the preview. That makes it extremely unfriendly to SSR-based web frameworks like Next and SvelteKit.

this statement and an alternative approach: https://css-tricks.com/inline-image-previews-with-sharp-blurhash-and-lambda-functions/

-> is this something can also be seen using thumbhash within your ts-liveview?

[hpvd]

for making the swap from preview to real image smooth, one can take inspiration from: https://css-tricks.com/the-blur-up-technique-for-loading-background-images/#aa-animating-the-swap

regarding todays compatibility: https://caniuse.com/?search=filter

[beenotung]

I prefer approaches that can works without javascript. The css filter trick you just shared seems interesting 👀