[HN Gopher] Making Websites Small
___________________________________________________________________
Making Websites Small
Author : boredumb
Score : 173 points
Date : 2021-12-01 16:05 UTC (6 hours ago)
(HTM) web link (santurcesoftware.com)
(TXT) w3m dump (santurcesoftware.com)
| javert wrote:
| Love the name of the company! Speaking as someone who lives in
| Santurce. ;) So glad to see this kind of high tech economic
| activity on the island.
| Semiapies wrote:
| One area where I'll disagree is minification. If you're gzipping
| (which you should be), try running your build without the
| minification step and compare the resulting over-the-wire file
| sizes. In my tests, the difference has been negligible. Which
| makes sense--you're just doing a limited text-based compression
| step before you throw the files at a real compressor, so it tends
| to be wasted effort.
|
| You're certainly never going to enjoy anything like the big
| shrink of using gzip, optimizing images, or not importing a big
| library you don't need.
| zoobab wrote:
| Gemini to the rescue.
| lelandfe wrote:
| Oddly, iOS Safari's reader mode chops off the entire first
| paragraph in this article.
| rchaud wrote:
| As admirable as the intention is, this is a losing battle. The
| biggest websites in the world have enormously bloated sites,
| because they can, and they won't be penalized for it.
|
| Your mom-and-pop website's rank is entirely at the discretion of
| Google's Core Web Vitals measurements (and other SEO KPIs), but
| Amazon with its dumpster fire search pages with shifting layouts
| as content is dynamically loaded in....will be just fine.
|
| The biggest websites in the world (Amazon, Google, Facebook,
| Twitter) try to push you to use their app whenever possible
| anyway. The web seems to be an incovenience for them, they
| certainly don't want you blocking any of the myriad scripts they
| have running under the hood to tally analytics, A/B testing, user
| sessions recording and whatever else.
|
| If you have a personal website, as I do, chances are it's
| relatively lean, because we're the only ones designing it and
| keeping it updated. Chances are also that very few people visit
| it, because it's outranked by the thousand other bloated websites
| that will rank higher for whatever query it was that you typed.
|
| So what's the point?
| ratww wrote:
| Sure, but complaining and proving it is possible to have
| smaller/faster websites is important because it can inspire and
| lead to better tools, libraries, services, standards,
| techniques and even new fads (!) in the future.
|
| I understand that lots of software engineers complain about new
| tooling, and would rather have nothing changing, but the
| reality is that things will change. So we might as well fight
| for them to change to the better, by proving it is possible and
| showing/teaching others.
|
| I also understand that people don't think FAANGs will ever
| fall, but just as Google disrupted every search before and
| Amazon disrupted brick and mortar stores, there can be
| something with a differentiator that will disrupt them in the
| future, and that differentiator might be going back to the web.
| Of course, there's the possibility of Google killing this new
| disruptive corner of the web as soon as its born, but oh
| well...
| Taurenking wrote:
| >So what's the point?
|
| Integrity. As hard/cringey as it sounds it's because of
| integrity that the internet is still relatively free and
| software like firefox exists
| Joker_vD wrote:
| > find yourself greeted with a 75vh image carousel, social media
| links and banners, a subscribe card, a "Chat Now!" banner with a
| GPT bot typing, xyz.com wants to know you location, or a prompt
| for cookies
|
| Don't also forget an "Allow xyz.com to send notifications?" pop
| up and an overlay ad banner with a 10 seconds timeout.
| marcus0x62 wrote:
| A related rant/con talk:
| https://idlewords.com/talks/website_obesity.htm
| smbv wrote:
| I optimized my website the other week. Some things that I did
| that were relatively easy included: removing Font Awesome (I
| replaced the relevant icons with SVGs since I was only using a
| few of them), removing jQuery (replaced with vanilla JS), lots of
| CSS (removed a lot of cruft from unused rules, etc from my SASS
| rules), and got rid of as many full size images as possible
| (replaced with webp thumbnail links). I got the size of my
| website down to less than 100 kb gzipped for the pages with
| images and less than 50kb for those without.
| GreenWatermelon wrote:
| How big was your site before optimization? also, I would like
| to see it.
| nicbou wrote:
| There are a few more things that help:
|
| - Reducing DNS calls and server round trips. Loading fewer
| resources from fewer domains makes a huge difference. Using
| server push also helps, although it might get deprecated.
|
| - Responsive images. Load small images on small displays. Don't
| load 2x images on lower density displays.
|
| - Using the right load event for JavaScript. load fires long
| after DOMContentLoaded on some pages, especially on slow
| connections.
|
| - Setting the size of elements before they load, to prevent the
| content from jumping all over the place.
|
| - Loading fewer fonts, and serving them yourself. Google Fonts is
| significantly slower.
|
| - Gzipping everything you send. It makes a significant difference
| on slow connections.
|
| - Static caching. This will shave whole seconds off your page
| load time. Cache both on the server and in the browser, but
| mostly on the server.
|
| - Consider perceived performance too. It doesn't matter how fast
| you force a coercive cookie notice on your readers.
|
| - Performance extends to the content of the page. Don't make
| users chase answers. Give clear, concise information and use
| typography to guide your users to it.
| aimor wrote:
| "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.
| ratww wrote:
| 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.
| mikeiz404 wrote:
| 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.
| tshaddox wrote:
| 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...
| mceachen wrote:
| 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.
| bigyikes wrote:
| 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.
| Semiapies wrote:
| A number of those are in TFA.
| jcun4128 wrote:
| 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
| hermitdev wrote:
| > 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.
| tshaddox wrote:
| 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...
| sirshmooey wrote:
| You can automate this in VSCode, very handy.
|
| https://christianheilmann.com/2021/04/14/quick-vs-code-
| tip-a...
| berkut wrote:
| 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?
| benhoyt wrote:
| 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).
| pdenton wrote:
| 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.
| spoils19 wrote:
| Agreed. Most sites don't even need JS, and for those that do,
| they'd be far better off with a desktop application.
| agumonkey wrote:
| 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.
| vore wrote:
| 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.
| Nextgrid wrote:
| 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.
| vore wrote:
| 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.
| bachmeier wrote:
| 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.
| Nextgrid wrote:
| 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.
| cunthorpe wrote:
| 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.
| theandrewbailey wrote:
| After gzip, minified vs. hand written code size is
| negligible. You are gzipping your HTML, CSS, and JS, right?
| hobofan wrote:
| gzip? What year is it? 2014? You better brotli your
| stuff!
| 1123581321 wrote:
| A large 3x phone in portrait orientation is still only 1-1.5K
| physical pixels wide.
| lampe3 wrote:
| 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.
| [deleted]
| ravenstine wrote:
| > 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.
| nicbou wrote:
| 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.
| lazyjeff wrote:
| 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.
| shakna wrote:
| 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.
| ratww wrote:
| _> 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.
| slackfan wrote:
| -conform to html4.1 spec
|
| -stop using JS
|
| -compress images
|
| Done.
| ksec wrote:
| I have been thinking about images on the web. And I still unsure,
| undecided on what sort of file size should we really be aiming
| at.
|
| >1500x1750 and weighing in at 3MB! The webp version of the same
| size is ~79KB.
|
| 79KB is a very low 0.24 BPP ( bit per pixel ). for 1 BPP it would
| be 328KB.
|
| AVIF is optimised for BPP below 1, while JPEP XL is optimised for
| BPP above 1. On a MacBook Pro, the first fold of the browser has
| 3456 x ~2200, an image filling up that screen with BPP 1 would
| equate to 950KB.
|
| In a perfect would you would want JPEG XL to further optimise BPP
| below 1.0 and do progressive loading on all image.
|
| We have also bumped out monitor resolution by at least 4x to
| Retina Standards.
|
| Despite our broadband getting so much faster, file size reduction
| is still the most effective way to get a decent browser
| experience. At the same time we want higher quality images and
| beautiful layout ( CSS ) etc.
|
| Balancing all of these is hard. I keep thinking if some of these
| are over optimising, when we can expect consumer internet speed
| to increase in the next 10 years.
| idoubtit wrote:
| > At the same time we want higher quality images
|
| YMMV but 99% the images I see on the web, I don't care about
| their quality. A large part of them are annoying, and most of
| the others could be low-resolution and low-quality, I would not
| even notice it, except for the faster page load. Once in a
| while, a photo is artistic or interesting enough to gain from a
| high quality, but most web sites I visit have far too many
| heavy images.
| mattlondon wrote:
| I believe it is against the t&C's for google maps to take a
| screenshot instead of an embedded map (or at.least it was when I
| looked a few years back).
|
| Please take care to read the t&Cs.
| technobabbler wrote:
| Poor Google, however will they survive
| sergiomattei wrote:
| So glad to see a fellow boricua posting on here.
| rado wrote:
| Yes, please. My components library for lightweight sites:
| https://niui.dev/
| bazeblackwood wrote:
| Whoa, this looks great!
| jeffreyrogers wrote:
| I used to run out of high-speed data on my cell phone plan
| towards the end of each billing period. Many websites/apps don't
| work at all at such low data speeds. Google Maps is basically
| unusable at low data speeds. Of course this trade off between
| performance for users vs ease of development has been with
| software for decades... see Andy and Bill's Law.
| piinbinary wrote:
| Do you know about the "OK maps" trick in Google Maps to
| download the map ahead of time?
|
| https://www.wired.com/2014/02/offline-google-maps/
| nicbou wrote:
| I design for those, because the experience is similar to that
| of someone in the Berlin U-Bahn. If you're just displaying text
| on a page, it shouldn't require a 4G connection.
| kevingrahl wrote:
| Your personal website is beautiful!
|
| The recipes section inspired me and now I need to add
| something similar to mine. And props for not tracking.
| nicbou wrote:
| Thanks! I was mostly talking about All About Berlin. My
| personal website gets a lot less love these days.
| marto1 wrote:
| On that note has anyone tried to "compress the Web" ? I know the
| Internet Archive is archiving it, but is there a browser or a
| tool in general that makes websites smaller while preserving
| functionality ?
| dekerta wrote:
| Opera Mini used to do this
| nicbou wrote:
| A bit like Reader Mode in some browsers?
| technobabbler wrote:
| Gzip does that, chrome mobile will proxy and recompress things
| in data saver mode, cloudflare will minify pages and scripts
| and recompress images and lazy load things for you if you let
| it.
|
| You can also just run an ad blocker and most of the weight goes
| away
| sackofmugs wrote:
| They mention the 1MB club at the end of that page, but even more
| strict is the 250 kb club: https://250kb.club/
| system2 wrote:
| Well, they all look like garbage txt to me.
| ecliptik wrote:
| There's also https://512kb.club/, which ironically is on
| https://250kb.club/.
| mdoms wrote:
| I would be utterly embarrassed to produce a 1mb payload on
| anything but an image- or video-heavy website (where the images
| and videos are the actual content, not superfluous crap).
| There's absolutely no reason for websites that are primarily
| text and hyperinks to ever approach anything like 1mb. Even
| 250kb is excessive for many cases.
|
| My latest website[0] is 7.5kb, and I built it after getting fed
| up with the official MotoGP no-spoilers list which sends 2mb to
| surface the same information in a much less user friendly way.
| This is how the bulk of the internet should look.
|
| [0] https://gplist.netlify.app/
| eatonphil wrote:
| > There's absolutely no reason for websites that are
| primarily text and hyperinks to ever approach anything like
| 1mb. Even 250kb is excessive for many cases.
|
| Yep. My personal site (70+ posts) is 26kb. 17kb is the syntax
| highlighting library.
|
| Another project site of mine is 2mb but that's because it has
| a lot of screenshots. I should probably shrink those
| screenshots though...
| bryans wrote:
| 250kb over <25 requests should really be an established
| standard at this point. It's not difficult to achieve and makes
| a massive difference in energy usage and server requirements
| for high traffic sites. There are plenty of <25kb frontend
| frameworks, and some of them are arguably better than their
| >100kb competitors.
|
| I recently made a site that frontloads an entire Svelte app,
| every page and route, entirety of site data (120kb gzipped),
| all of the CSS and a font full of icons, a dozen images,
| service worker and manifest. Clocks in at exactly 250kb, scores
| 100 on LH, fully loads in 250ms uncached, and all navigation
| and searching is instantaneous.
|
| That's not a brag, it just goes to show that anyone can make
| sites which are bandwidth and energy friendly, but for some
| reason very people actually do that anymore.
| djbusby wrote:
| What's LH?
| Lammy wrote:
| https://developers.google.com/web/tools/lighthouse/
| [deleted]
| qmmmur wrote:
| How do you front load the whole svelte app?
| bryans wrote:
| Disabling SSR and prerender within SvelteKit turns the
| output into an SPA, and the manualChunks option in vite-
| plugin-singlefile ensures the output is one file that
| includes every page of the site.
| XCSme wrote:
| I would want to consider the points in the article, but I can not
| focus to read the text on my 27inch/4k screen as the line width
| is too big. This also makes be doubt than whoever wrote those
| lines cares about UX and not only about having a minimal webpage.
| montroser wrote:
| Yes indeed! All it would take is a single line of CSS somewhere
| applying to the copy text: max-width: 50em
|
| Wikipedia has this quirk as well though, where if you have a
| large monitor, you can end up with ridiculously long lines that
| are impossible to read.
| the__alchemist wrote:
| It seems obvious that website designers, and tools/orgs that
| provide websites to others don't have "small download size" or
| "fast" as project requirements.
| javiramos wrote:
| Great to see Puerto Rican tech content on Hacker News! I grew up
| in PR and have always dreamed that PR could become a Singapore or
| similar with regards to its tech ecosystem. Saludos boricua from
| Boston!
| javert wrote:
| FYI, you probably know already, but there are lots of
| crypto/blockchain people living in PR now.
|
| And, PR could definitely become a Singapore if the government
| would embrace that possibility (they're already part way there
| with the low taxes for expats), but I think they are too
| populist and just don't have that kind of vision for the future
| of the island.
___________________________________________________________________
(page generated 2021-12-01 23:00 UTC)