Hacker News Reader

> Setting the size of elements before they load, to prevent the content from jumping all over the place.

This is especially jarring on a phone. Multiple times a day, I see this, and it pisses me off each and every time. Nothing like reading an article to all of a sudden have some image load somewhere (likely not even visible on screen) suddenly cause what you're reading to disappear off screen. And I'm not on a slow connection, either. I'm typically on uncongested wifi connected to fiber when at home, 5G otherwise.

JavaScript in general is so bad, or rather is being used for so many bad practices, that I've disabled it on my main mobile browser. What little good it's used for doesn't out weigh all of the bad out there. I'm tired of malicious ads hijacking the page, either rendering popups or redirecting me somewhere I don't want to go. If a site doesn't render anything useful without javascript (Twitter is a prime example), I typically turn around and go elsewhere.

Layout shift due to responsive images is now easy to prevent, because most up-to-date browsers now correctly set the aspect ratio of a responsive img element if you add the height and width attributes. Before a year or so ago, you had to use hacks like padding percentages to correctly set the aspect ratio.

https://www.smashingmagazine.com/2020/03/setting-height-widt...

You can automate this in VSCode, very handy.

https://christianheilmann.com/2021/04/14/quick-vs-code-tip-a...

Depends.

There are extensions (Dark Reader, a dark/light mode extension for Firefox, is an example) which trigger multiple redraws of a page on load. On an e-ink device (my principle driver these days), the extension is a near necessity (ironically, to force black-on-white themes on sites, much more readable on e-ink), and page re-paints are all the more jarring and expensive.

Simple pages still load quickly and without disruption. Many complex sites don't. (NPR's website comes particularly to mind.)

> This is especially jarring on a phone. Multiple times a day, I see this, and it pisses me off each and every time. Nothing like reading an article to all of a sudden have some image load somewhere (likely not even visible on screen) suddenly cause what you're reading to disappear off screen.

This is the worst on picture rich recipe blogs. I hate it.

Nothing saves as much as just writing the HTML, CSS, and JS by hand. No build step or anything but an editor. No need to minify anything, keeping it nice and simple.

Responsive images are kind of funny in the sense that my webpages are nearly twice the size on mobile vs my laptop. The screen may be smaller, but the CSS pixel ratio is 1 on my laptop vs 3 on an iPhone.

I think a lot of the suggestions the parent comment suggests are orders of magnitude better savings than writing things by hand...

Perhaps writing things by hand has a questionable nostalgic allure of "keeping one honest" but beyond that I don't think it's super practical.

While true in theory, I believe that keeping things handmade means that the payload couldn't realistically become big enough for the parent's suggested optimizations to actually matter.

An unoptimized payload isn't that big of a deal if it's still smaller than the best optimized one.

Perhaps not all of the advice applies, but when it comes to images and fonts, I don't think any amount of keeping things handmade is going to outstrip the advice regarding static caching and loading fewer fonts.

The best advice for images is to delete them. There's a widespread belief that meaningless pictures at the top of a post are critical. Here's the first link that comes up on Medium: https://equinox-launch.medium.com/trade-hard-win-big-dopewar... The value added of that image at the top is negative. This is, sadly, the rule rather than the exception.

Edit: This is an even better example: https://medium.com/general_knowledge/top-10-crypto-gaming-pr... How anyone can look at that image and say "that'd be perfect for the top of my next post" is beyond me.

At least the Medium gif-every-paragraph plague seems to have ended. Not sure why anyone thought it was necessary.

Heavy images & fonts on an otherwise plain HTML page will still be acceptable as they would be loading in parallel - in most cases the text will come first anyway.

I'd rather have a half-loaded page with images/fonts missing than a JS-based page which won't give me anything until the full JS payload is downloaded & executed.

Writing HTML by hand is pretty dubious advice (slightly impractical but doable, so not necessarily something to rule out on those grounds, but the factor that dominates in deciding whether or not to do it comes down negligible benefit). But writing CSS and JS by hand is both way more practical than people think, and the gains are real.

If you're not a fan of hand rolled HTML, then what do you think of JSX?

If HTML allowed you to trivially import reuseable components like you can with JSX it’d be killer. That’s the one thing that stops me writing my site by hand.

I’m looking at Astro for my site’s re-write as it seems to find a happy medium here.

>If HTML allowed you to trivially import reuseable components like you can with JSX

Sounds like WebComponents.

>I'm looking at Astro...

Never heard of it and just gave it a quick glance. Hadn't heard of the "islands architecture" it implements either, although it is similar to some familiar concepts.

In fact, it reminds me of the way we built sites years ago (pre-AJAX even), when static HTML was just delivered by the server and there was little-to-no JS involved, save for some effects.

And, that's the funny thing: in spite of all the myriad paths and paradigms, we seem to be coming full circle. It's funny in 2021 to see a "new" project advocating for a "new" approach that is essentially "SSR static HTML with minimal client JS FTW!"

> Sounds like WebComponents.

Interesting. I’ll check it out.

Update: checked it out. Shame that `Getting Started` > `Web Components` = 404.

https://www.webcomponents.org/introduction works for me.

WebComponents have been discussed for a while. They were just a dream not too long ago, and I'm not sure what their usability is right now. So, word of warning that I'm not advocating for or against their use at this point. Just mentioning that the description you gave previously reminded me of WebComponents.

i don't. Write by hand and apply the above! But there won't be seconds to shave no more in the first place.

Wrong. Of course if you use a minifier you save bytes, it’s by definition. A decent built tool can still start from static files but also optimize them as much as possible. If there’s little CSS it might even just inline it.

After gzip, minified vs. hand written code size is negligible. You are gzipping your HTML, CSS, and JS, right?

gzip? What year is it? 2014? You better brotli your stuff!

A properly minified JS might be smaller after compression, even if the difference is not huge, but it may also be faster to parse.

reminds me I used to check websites under elinks just to see how structure/content would feel without css. You can identify fat quick this way.

A large 3x phone in portrait orientation is still only 1-1.5K physical pixels wide.

If your project is that small that you can manage and implement on your own without teams having to work together and if you don't care about older browser. In that case you maybe have a point.

If you work on bigger projects you will run into many problems really soon. Like some Safari strangeness when it comes to CSS. Someone using some old browser which you as a developer would never use but your user base still uses it and it makes 12 % of the revenue.

Agreed. Most sites don't even need JS, and for those that do, they'd be far better off with a desktop application.

Then you have to get people to install said application

I would hate giving any random piece of software full access to my computer instead of using a sandboxed version in a browser. The perf tradeoff is worth it for stuff like games and photo/video editors, but every random webapp? No way.

You don't need a web browser to sandbox a program.

This really only works for relatively small sites that don't change much and aren't developed by multiple people. After that you'll at least want some static site generation (which by itself doesn't slow down the experience), bundling of multiple JS sources together (allows you to handwrite JS over multiple files without taking the perf hit of serving multiple files), and likely a CSS preprocessor (e.g. SCSS).

I write my CSS by hand. I just don't like setting up preprocessors unless I have colleagues working on the same code.

No, it does not help. CSS is trivially small, especially after it's compressed. Same for HTML and JS. JS will balloon in size if you start using Webpack, but your own code will stay fairly small.

A single image will outweigh your text files, so the effort isn't really worth it.

> writing the HTML, CSS, and JS by hand.

plus careful image scale, quality and progressive display. Often images appear to be print quality. You need to know about the difference of web and print, however.

> Loading fewer fonts, and serving them yourself.

How about no serving of fonts? I don't think I've ever looked at a webpage and thought it would be improved by a particular font family. What exactly can't be accomplished with standard web fonts? Icons? Haha, don't even go there.

Absolutely, especially with the recent "invention" of the native font stack as a solution that does not require loading external files while showing a nice modern font.

Imagine if the trade-off was more explicit to the visitors: would you want something that made your web browsing slower, your text flashes in like a cheap powerpoint slide, and sent your data to Google, in exchange for being able to read in a different font? External web fonts are purely for the ego of the web developer, not for the reader.

I actually disabled loading of webfonts. The only two websites I've encountered where I actually notice it, and remember that I did that, is Google Translate and a particular government website I use about once a year.

Everything, everywhere else, seems to work just fine with using the browser defaults.

> The only two websites I've encountered where I actually notice it, and remember that I did that, is Google Translate and a particular government website I use about once a year.

That's probably because of the Google Material Icons font, I believe? It shows or used to show text instead of icons when it couldn't load.

> That's probably because of the Google Material Icons font, I believe? It shows or used to show text instead of icons when it couldn't load.

All icon fonts _should_ do this. It's just that the Google Translate site is designed in such a way that the fallback text doesn't render correctly, overflowing and overlapping over everything else, which makes it noticeable. It seems to very much be a 'pixel perfect' design, rather than responsive.

Everywhere else, the fallback fits naturally, or renders to a standardised UTF-8 symbol, so that it isn't noticeable to me for day-to-day usage.

In my case it guarantees a certain level of readability that is consistent across platforms. I spent quite a bit of time fine tuning the font weights to help readability. That costs about 60 kb, so it's hardly a huge sacrifice.

Another option is that you keep 90% of your text in the default font (e.g, -apple-system or the equivalent stack elsewhere), and then load only the specific weights for whatever title(s) or so on you need.

Hell, I've outright just crammed a few characters into a base64 encoded font in inline CSS, which - while I'm sure makes many here grimace - loads faster than anything else I've tested.

(I'm a big fan of just shipping everything down the pipe as one file, short of images - I do this on my personal site and it makes me happy that it "just works": https://rymc.io/ )

For me it is because fonts are part of the artistic expression of my website.

Also, it helps with formatting code just the way I want it.

"Setting the size of elements before they load"

I host a personal photo gallery online and I've been dreading implementing this for images to get rid of the jump when lazy loading. I'm not even sure there's a good way to do it.

For my personal image gallery, I have a script to include the image dimensions in the file name when I upload.

It’s kind of a hack, but it lets me compute the final image flow based on the file name before any of the images have loaded.

Do your photos scale in your gallery?

This is off the top of my head but if your images are set to a percent based width so they scale (mine are) and you know the aspect ratio of the image then you can set the CSS ‘ aspect-ratio’ property (or there are some other hacks with padding on a wrapper div) to maintain the height.

You’d probably want to integrate this into the build process but I have not done this.

You don't even need the recently-added aspect-ratio property. In most up-to-date browsers you can now just add the height and width attributes to the img tag and the aspect ratio will render correctly even for responsive images:

https://www.smashingmagazine.com/2020/03/setting-height-widt...

The only way to prevent reflow is to give the browser your image dimensions or aspect ratio:

https://developer.mozilla.org/en-US/docs/Web/CSS/aspect-rati...

Using a css flexbox or grid layout means you don't have to recalculate image div widths and heights when the browser viewport width changes, but you still need to give it enough information to back into the correct aspect ratio.

Also, using a srcset helps only load the necessary bytes, but means you'll need to either build the resized image on the fly (which is cpu-expensive) or prebuild them (which takes up some disk space).

In the interests of a performant UI, PhotoStructure extracts and remembers width and height of photos and videos during imports, but if you're only loading a couple images in a gallery, your could fetch this metadata on the fly as well.

For a grid-style gallery you can have a container for each image with a fixed size (the maximum size you want an image to be) and the image itself can use max-width and max-height with the same size of the container. If your aspect ratios are too varied, you might have to fiddle with the ideal size to get an optimal result, but it gets the job done.

If it's another kind of gallery it could work if you accept those constraints. If you don't, then it's better to use width/height anyway.

Depending on your UI, you can also load the images into a hidden div (display:none), catch the load event for each image, and display the div once you've detected that the entire image set has loaded.

I want to say I did something like this for an infinite scroll, grid layout some time ago where I didn't have the image dimensions to help the browser. Details are fuzzy but there seemed to be a gotcha here and there, some of which was around the load event.

Of course, the user's perceived wait time goes up a bit, as you're not displaying each image as it loads. But, that can be mitigated somewhat by fewer images per pagination and/or preloads.

The overall solution worked well for our use case.

There might be something in here for you: https://twitter.com/samccone/status/1279117536479506432?s=20 https://twitter.com/samccone/status/1360730258752741376?s=20

This stuff is hard

On a semi-related note:

Is there any chance in the future that browsers are going to support / implement lazy-loading of images themselves (i.e. based off what's visible in the viewport). Currently you have to (as far as I'm aware anyway, but I'm only just getting re-acquainted with web-dev) use JS to do it (things like LazySizes), which adds complexity, and is even more complicated if you want to combine that with responsive images...

Or am I missing something that's possible already?

You can set the attribute loading="lazy" on an <img> tag and the browser will do it for you. Looks like Edge and Chrome and Firefox support it, but not Safari yet (https://caniuse.com/?search=loading).

Server push has been deprecated by browsers for a while now.

To reduce round-trips, consider using TCP Fast Open and 0-RTT with TLS 1.3. Note that 0-RTT can enable replay attacks, so I'd only consider using it for static content. HTTP/3 and QUIC has improved support for 0-RTT.

Gzip is good for dynamic compression, especially with zlib-ng. For static compression, I'd rather use Brotli.

Also:

- get rid of bloated adtech (e.g. 6MB of adtech garbage from 60 domains for 20KB of text)

- remove all popups, slideovers, mailing list signup garbage, etc.

- get rid of autoloading/autoplaying video

- avoid bloated frameworks

- avoid external fonts

side note: why is it an iPhone with a crazy looking display is only 300 and some pixels wide viewport in the web, that seems odd.

I did check on my Android and it's similar, 1080P display but 412px wide in browser

also that bottom navbar in Safari ahh

It’s points, not pixels. A modern smartphone usually has a scale factor of 2 or 3, giving the same logical screen space with a significantly sharper image.

A point is 1/72 of an inch. A CSS pixel is canonically 1/96 of an inch. https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel

It's not (as sibling comment says) points, it's logical pixels as declared by the device/user agent's pixel density. Device pixels are usually (but not always) some integer multiple of the logical pixels.

A number of those are in TFA.