13 ms·

Making Websites Small

268 points by boredumb 5y ago

rado 5y ago
Yes, please. My components library for lightweight sites: https://niui.dev/ https://niui.dev/
- bazeblackwood 5y ago
  Whoa, this looks great!
___q 5y ago
Working with designers, I'm provided final images at spec and can only optimize them losslessly; compressing an image changes its appearance. The CLI commands in this article use lossy compression. The point stands, alternative image formats should be used whenever possible, but I need a lossless compression pipeline to generate WEBP, AVIF, etc.
- Wowfunhappy 5y ago
  As someone who also works with designers, I understand at a deep level how you end up in this situation—but I also don't think it should be this way. Image compression should be primarily an engineering issue, and designers should be giving you lossless or effectively lossless[1] images to compress as you see fit. The one thing I'd designers to be responsible for is image resolution, since this is intrinsically tied to website layout and affects white source photos can be used where. [1] For example, a 100% quality jpeg is perfectly fine to work with.
  - ___q 5y ago
    > Image compression should be primarily an engineering issue It affects how they look, so it's a design issue. I'd compress them all to 1% if it primarily an engineering issue.
lelandfe 5y ago
Oddly, iOS Safari’s reader mode chops off the entire first paragraph in this article.
jeffreyrogers 5y ago
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 5y ago
  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/ https://www.wired.com/2014/02/offline-google-maps/
- nicbou 5y ago
  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 5y ago
    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 5y ago
      Thanks! I was mostly talking about All About Berlin. My personal website gets a lot less love these days.
Joker_vD 5y ago
> 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.
nicbou 5y ago
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.
- musicale 5y ago
  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
- hermitdev 5y ago
  > 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.
sackofmugs 5y ago
They mention the 1MB club at the end of that page, but even more strict is the 250 kb club: https://250kb.club/ https://250kb.club/
- bryans 5y ago
  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 5y ago
    What's LH?
    - Lammy 5y ago
      https://developers.google.com/web/tools/lighthouse/ https://developers.google.com/web/tools/lighthouse/
    - deleted 5y ago
      [deleted]
  - qmmmur 5y ago
    How do you front load the whole svelte app?
    - bryans 5y ago
      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.
sergiomattei 5y ago
So glad to see a fellow boricua posting on here.
marto1 5y ago
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 5y ago
  Opera Mini used to do this
- nicbou 5y ago
  A bit like Reader Mode in some browsers?
  - marto1 5y ago
    it's a bit of a stretch to say it preserves functionality :-) I meant it more in the lossless compression sort of way.
- technobabbler 5y ago
  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
smbv 5y ago
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 5y ago
  How big was your site before optimization? also, I would like to see it.
  - smbv 5y ago
    It's in my bio It was roughly 900kb gzipped on most text only pages. Some pages are on archive.org.
mattlondon 5y ago
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 5y ago
  Poor Google, however will they survive
  - sp332 5y ago
    By suing the pants off anyone who violates the T&C.
marcus0x62 5y ago
A related rant/con talk: https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm
- mro_name 5y ago
  sadly ages very well.
javiramos 5y ago
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 5y ago
  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.
javert 5y ago
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.
ksec 5y ago
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 5y ago
  > 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.
slackfan 5y ago
-conform to html4.1 spec -stop using JS -compress images Done.
the__alchemist 5y ago
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.
Semiapies 5y ago
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.
rchaud 5y ago
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 5y ago
  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 5y ago
  >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
- forgotmypw17 5y ago
XCSme 5y ago
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 me doubt that whoever wrote those lines cares about UX and not only about having a minimal webpage.
- montroser 5y ago
  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.
  - XCSme 5y ago
    For some reason this website is a lot worse than Wikipedia for me. I think it has to do with the font size and spacing. On Wikipedia the font size is smaller, so even though the line is long, the sentences are pretty short and you can read almost an entire sentence without moving your eyes/head. On this site it feels like a journey to read a sentence.
  - sp332 5y ago
    The mobile version of the site fixes this.
- aasasd 5y ago
  Exactly. Apparently these people don't stop to think why the majority of books are made in portrait format, and magazines, newspapers and some books split texts in columns.
- garaetjjte 5y ago
  Well you could just.. resize your browser window to preferred width.
  - XCSme 5y ago
    I could also buy a smaller monitor.
zoobab 5y ago
Gemini to the rescue.
jrochkind1 5y ago
> Resizing our image to 1000x1152 shrinks our PNG down to 1.5MB, and finally running cwebp to convert it to a webp we're down to 49KB. That seems like a lot. What's going on here? Surely the compression level is changing drastically, right?
- chrismorgan 5y ago
  PNG is lossless, the 49KB WebP will be lossy (WebP can be either). Few images beyond the size of icons warrant losslessness, which comes at an extreme size penalty.
  - jrochkind1 5y ago
    Oh I didn't realize/forgot that PNG was losssless, thanks! I'm curious how this file size would compare to a JPG at, say, level 85.
toss1 5y ago
We need a LOT more of this! Many sites are becoming practically unusable as more and more crap is loaded for not-good-enough reasons. When websites from social media to banks often take tens of seconds to load, it is obvious that the designers and coders could not care less about the UX. Even the definition of a "small" site has grown three orders of magnitude. There used to be a 5KB website competition [0], which grew to a 10K contest. Now, the link is to a One Megabyte Club [1] list of small websites. I don't know how to reverse the trend, but managers and coders need to realize that just because some is good, does not mean that more is better. [0] https://www.the5k.org/ https://www.the5k.org/ [1] https://1mb.club/ https://1mb.club/ Edit: line breaks. Also note that GMail HTML mode is much better than the 'standard mode'.
akrymski 5y ago
Probably the coolest trick I've seen is inlining everything into a single HTML file: JS, CSS, images, icons and fonts. One single large request seems to work much better than loads of small ones.
- brundolf 5y ago
  You don't want to do that in most cases because those separate files can be loaded in parallel, where the single HTML file can't
  - chrismorgan 5y ago
    That’s… misleading, at best. Depends on how many resources you have, whether you’re using different domains, and whether you’re using HTTP/1 or something newer. Generally speaking, what you’re saying is only true if you have a lot of decently large resources, loaded from different domains or over HTTP/1. If everything was coming from the same origin already, then: • If you’re using HTTP/2 or HTTP/3 your statement is almost entirely false: whether you load in parallel or in serial, it’ll be downloading it at the same speed, except that by not inlining you’ve added at least one round trip for the client to know that it needs to request these other URLs; and now you mostly can’t control priority, whereas with everything inlined you know it’ll load everything in source order, which you can normally tweak to be pretty optimal. • If you’re using HTTP/1, the use of multiple connections (typically up to 6) only kicks in if you’ve got plenty of stuff to download, but involves at least a couple of round trips to establish the connection, so even if using a single connection reduces the available bandwidth, it’s still normally worth it for many, probably most, sensibly-done sites.
- josephg 5y ago
  This approach prevents any of those resources from being cached and reused on other pages. Visitors will end up re-downloading all that content if they click on any links on your page. Mind you, most web developers assume users spend a lot more time on their site than they actually do. Most visitors to your website will not click on any internal links on your page.
brundolf 5y ago
I think it's a big misconception that rendering code is responsible for most of this bloat. The great majority in my experience comes from tracking scripts and adware that get layered on top. This can be just as true on a React-based site as it is on a classic server-rendered Wordpress site, and is often out of the hands of the actual engineers. I suspect Google Tag Manager has done more harm to the web experience than any other single factor.
chiel 5y ago
https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/
wila 5y ago
> it's easy to forget that there is a large number of users that are browsing the same websites as I am, however they are using an underpowered mobile device over a 3G network What is even more interesting is that in some parts of the world 3G is about to be phased out. Everybody on 4G and 5G? I'm afraid not, the people who now are limited to 3G will be limited to 2G unless they invest into something new and shiny.
warmerone 5y ago
History API could improve on user experience. But I'm having issue with certain browser on iOS with swipe gestures that take you to the back and forward page. Firefox, Opera GX, etc will simple lose its scroll position whenever I swiped, while it doesn't happen on Safari and Google Chrome. This seem related to the infinite scroll page vs fixed page height. Most of the site I have explore didn't appear to solve that annoyed issue as it happened to YouTube content on mobile too.
JCWasmx86 5y ago
I'm really annoyed of websites that are just showing text+images and then load dozens of JS-scripts. Sure, for some functionality you may need JS, but in like 90% of the cases JS is overused.
hoten 5y ago
If you want a fast overview of a page's JS and coverage: We developed a quick way to view a treemap of all your pages JS (including inside bundles) from a Lighthouse report. Do it through the DevTools or from PageSpeed Insights - no need to reach for a CLI tool. Of course, you need to have source maps accessible to see inside bundles. Here's an example: https://googlechrome.github.io/lighthouse/treemap/?debug https://googlechrome.github.io/lighthouse/treemap/?debug
marcus_holmes 5y ago
This is down to no-one caring about speed for brochure websites. The client just wants their website up as cheaply as possible as quickly as possible. The quickest, cheapest way of building a brochure site is usually Wordpress using a off-the-shelf template. And no-one in that entire chain cares about the loading speed of the site. Also, I'm not sure who the article is aimed at? Local lawyers are not going to read this and be able to fix their site. The owner of the web design agency that they bought the site from isn't going to read it because they moved from tech to biz. The web dev who is implementing the site already knows this, but has to knock out sites as quickly and cheaply as possible, and so this isn't something that matters.
wildpeaks 5y ago
It's not Webpack, minifiers or build tools that make things bigger: if you feed them small inputs, you get small bundles. Build pipelines don't merely concatenate a few scripts, they're meant to automate the boring parts we used to have to do by hand (like copying assets with cache-busting filenames and update matching references, set the correct image sizes, generate SRI hashes, generate sourcemaps, generate sitemaps, check the quality of pages, etc). This way you can focus on writing the application and keeping it maintainable without having to waste time remembering to use javascript hacks (like `!1` instead of `false`) to save a few bytes like we used to. It's when people indiscriminately feed them big frameworks that things bloat, same way you won't be lightweight with a junk food diet.

268 points by boredumb 5y ago

rado 5y ago

Yes, please. My components library for lightweight sites: https://niui.dev/ https://niui.dev/

bazeblackwood 5y ago
Whoa, this looks great!

___q 5y ago

Working with designers, I'm provided final images at spec and can only optimize them losslessly; compressing an image changes its appearance. The CLI commands in this article use lossy compression. The point stands, alternative image formats should be used whenever possible, but I need a lossless compression pipeline to generate WEBP, AVIF, etc.

Wowfunhappy 5y ago
As someone who also works with designers, I understand at a deep level how you end up in this situation—but I also don't think it should be this way. Image compression should be primarily an engineering issue, and designers should be giving you lossless or effectively lossless[1] images to compress as you see fit. The one thing I'd designers to be responsible for is image resolution, since this is intrinsically tied to website layout and affects white source photos can be used where. [1] For example, a 100% quality jpeg is perfectly fine to work with.
- ___q 5y ago
  > Image compression should be primarily an engineering issue It affects how they look, so it's a design issue. I'd compress them all to 1% if it primarily an engineering issue.

lelandfe 5y ago

Oddly, iOS Safari’s reader mode chops off the entire first paragraph in this article.

jeffreyrogers 5y ago

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 5y ago
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/ https://www.wired.com/2014/02/offline-google-maps/
nicbou 5y ago
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 5y ago
  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 5y ago
    Thanks! I was mostly talking about All About Berlin. My personal website gets a lot less love these days.

Joker_vD 5y ago

> 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.

nicbou 5y ago

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.

musicale 5y ago
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
hermitdev 5y ago
> 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.

sackofmugs 5y ago

They mention the 1MB club at the end of that page, but even more strict is the 250 kb club: https://250kb.club/ https://250kb.club/

bryans 5y ago
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 5y ago
  What's LH?
  - Lammy 5y ago
    https://developers.google.com/web/tools/lighthouse/ https://developers.google.com/web/tools/lighthouse/
  - deleted 5y ago
    [deleted]
- qmmmur 5y ago
  How do you front load the whole svelte app?
  - bryans 5y ago
    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.

sergiomattei 5y ago

So glad to see a fellow boricua posting on here.

marto1 5y ago

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 5y ago
Opera Mini used to do this
nicbou 5y ago
A bit like Reader Mode in some browsers?
- marto1 5y ago
  it's a bit of a stretch to say it preserves functionality :-) I meant it more in the lossless compression sort of way.
technobabbler 5y ago
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

smbv 5y ago

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 5y ago
How big was your site before optimization? also, I would like to see it.
- smbv 5y ago
  It's in my bio It was roughly 900kb gzipped on most text only pages. Some pages are on archive.org.

mattlondon 5y ago

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 5y ago
Poor Google, however will they survive
- sp332 5y ago
  By suing the pants off anyone who violates the T&C.

marcus0x62 5y ago

A related rant/con talk: https://idlewords.com/talks/website_obesity.htm https://idlewords.com/talks/website_obesity.htm

mro_name 5y ago
sadly ages very well.

javiramos 5y ago

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 5y ago
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.

javert 5y ago

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.

ksec 5y ago

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 5y ago
> 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.

slackfan 5y ago

-conform to html4.1 spec -stop using JS -compress images Done.

the__alchemist 5y ago

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.

Semiapies 5y ago

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.

rchaud 5y ago

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 5y ago
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 5y ago
>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
forgotmypw17 5y ago

XCSme 5y ago

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 me doubt that whoever wrote those lines cares about UX and not only about having a minimal webpage.

montroser 5y ago
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.
- XCSme 5y ago
  For some reason this website is a lot worse than Wikipedia for me. I think it has to do with the font size and spacing. On Wikipedia the font size is smaller, so even though the line is long, the sentences are pretty short and you can read almost an entire sentence without moving your eyes/head. On this site it feels like a journey to read a sentence.
- sp332 5y ago
  The mobile version of the site fixes this.
aasasd 5y ago
Exactly. Apparently these people don't stop to think why the majority of books are made in portrait format, and magazines, newspapers and some books split texts in columns.
garaetjjte 5y ago
Well you could just.. resize your browser window to preferred width.
- XCSme 5y ago
  I could also buy a smaller monitor.

zoobab 5y ago

Gemini to the rescue.

jrochkind1 5y ago

> Resizing our image to 1000x1152 shrinks our PNG down to 1.5MB, and finally running cwebp to convert it to a webp we're down to 49KB. That seems like a lot. What's going on here? Surely the compression level is changing drastically, right?

chrismorgan 5y ago
PNG is lossless, the 49KB WebP will be lossy (WebP can be either). Few images beyond the size of icons warrant losslessness, which comes at an extreme size penalty.
- jrochkind1 5y ago
  Oh I didn't realize/forgot that PNG was losssless, thanks! I'm curious how this file size would compare to a JPG at, say, level 85.

toss1 5y ago

We need a LOT more of this! Many sites are becoming practically unusable as more and more crap is loaded for not-good-enough reasons. When websites from social media to banks often take tens of seconds to load, it is obvious that the designers and coders could not care less about the UX. Even the definition of a "small" site has grown three orders of magnitude. There used to be a 5KB website competition [0], which grew to a 10K contest. Now, the link is to a One Megabyte Club [1] list of small websites. I don't know how to reverse the trend, but managers and coders need to realize that just because some is good, does not mean that more is better. [0] https://www.the5k.org/ https://www.the5k.org/ [1] https://1mb.club/ https://1mb.club/ Edit: line breaks. Also note that GMail HTML mode is much better than the 'standard mode'.

akrymski 5y ago

Probably the coolest trick I've seen is inlining everything into a single HTML file: JS, CSS, images, icons and fonts. One single large request seems to work much better than loads of small ones.

brundolf 5y ago
You don't want to do that in most cases because those separate files can be loaded in parallel, where the single HTML file can't
- chrismorgan 5y ago
  That’s… misleading, at best. Depends on how many resources you have, whether you’re using different domains, and whether you’re using HTTP/1 or something newer. Generally speaking, what you’re saying is only true if you have a lot of decently large resources, loaded from different domains or over HTTP/1. If everything was coming from the same origin already, then: • If you’re using HTTP/2 or HTTP/3 your statement is almost entirely false: whether you load in parallel or in serial, it’ll be downloading it at the same speed, except that by not inlining you’ve added at least one round trip for the client to know that it needs to request these other URLs; and now you mostly can’t control priority, whereas with everything inlined you know it’ll load everything in source order, which you can normally tweak to be pretty optimal. • If you’re using HTTP/1, the use of multiple connections (typically up to 6) only kicks in if you’ve got plenty of stuff to download, but involves at least a couple of round trips to establish the connection, so even if using a single connection reduces the available bandwidth, it’s still normally worth it for many, probably most, sensibly-done sites.
josephg 5y ago
This approach prevents any of those resources from being cached and reused on other pages. Visitors will end up re-downloading all that content if they click on any links on your page. Mind you, most web developers assume users spend a lot more time on their site than they actually do. Most visitors to your website will not click on any internal links on your page.

brundolf 5y ago

I think it's a big misconception that rendering code is responsible for most of this bloat. The great majority in my experience comes from tracking scripts and adware that get layered on top. This can be just as true on a React-based site as it is on a classic server-rendered Wordpress site, and is often out of the hands of the actual engineers. I suspect Google Tag Manager has done more harm to the web experience than any other single factor.

chiel 5y ago

https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/

wila 5y ago

> it's easy to forget that there is a large number of users that are browsing the same websites as I am, however they are using an underpowered mobile device over a 3G network What is even more interesting is that in some parts of the world 3G is about to be phased out. Everybody on 4G and 5G? I'm afraid not, the people who now are limited to 3G will be limited to 2G unless they invest into something new and shiny.

warmerone 5y ago

History API could improve on user experience. But I'm having issue with certain browser on iOS with swipe gestures that take you to the back and forward page. Firefox, Opera GX, etc will simple lose its scroll position whenever I swiped, while it doesn't happen on Safari and Google Chrome. This seem related to the infinite scroll page vs fixed page height. Most of the site I have explore didn't appear to solve that annoyed issue as it happened to YouTube content on mobile too.

JCWasmx86 5y ago

I'm really annoyed of websites that are just showing text+images and then load dozens of JS-scripts. Sure, for some functionality you may need JS, but in like 90% of the cases JS is overused.

hoten 5y ago

If you want a fast overview of a page's JS and coverage: We developed a quick way to view a treemap of all your pages JS (including inside bundles) from a Lighthouse report. Do it through the DevTools or from PageSpeed Insights - no need to reach for a CLI tool. Of course, you need to have source maps accessible to see inside bundles. Here's an example: https://googlechrome.github.io/lighthouse/treemap/?debug https://googlechrome.github.io/lighthouse/treemap/?debug

marcus_holmes 5y ago

This is down to no-one caring about speed for brochure websites. The client just wants their website up as cheaply as possible as quickly as possible. The quickest, cheapest way of building a brochure site is usually Wordpress using a off-the-shelf template. And no-one in that entire chain cares about the loading speed of the site. Also, I'm not sure who the article is aimed at? Local lawyers are not going to read this and be able to fix their site. The owner of the web design agency that they bought the site from isn't going to read it because they moved from tech to biz. The web dev who is implementing the site already knows this, but has to knock out sites as quickly and cheaply as possible, and so this isn't something that matters.

wildpeaks 5y ago

It's not Webpack, minifiers or build tools that make things bigger: if you feed them small inputs, you get small bundles. Build pipelines don't merely concatenate a few scripts, they're meant to automate the boring parts we used to have to do by hand (like copying assets with cache-busting filenames and update matching references, set the correct image sizes, generate SRI hashes, generate sourcemaps, generate sitemaps, check the quality of pages, etc). This way you can focus on writing the application and keeping it maintainable without having to waste time remembering to use javascript hacks (like `!1` instead of `false`) to save a few bytes like we used to. It's when people indiscriminately feed them big frameworks that things bloat, same way you won't be lightweight with a junk food diet.