This is ridiculous. Old schoolers like me were taught to minimise the size of whatever you serve on a site, as much as possible, when learning web design and web programming. If you didn't use any JPEG and GIF optimisers, or HTML and Javascript you were berated (this was before Flash). You were taught about browser caching and its importance. Most WYSIWYG applications e.g. Macromedia (now Adobe) Dreamweaver had a feature where you set an internet connection speed and it would tell you how much time each web page you created would take to load on such a connection. It would even tell you what element in a page would take the longest to load.

Today's "10 MB minimum" videos on the background web pages (half of it made up of ads) is just so irritating, and disappointing.

One of my friend works at Microsoft / LinkedIn, and when he asked me (7+ year ago) how the LinkedIn Mobile app could be improved, I advised him to reduce its size and make it as responsive as possible over the slowest mobile connection in India. And the indian team did do that and my friend later told me that the US office noted their work and commendedthem for it. (There are 100 million Indians on LinkedIn - https://www.forbesindia.com/article/take-one-big-story-of-th... ).

Sir, you owe me a new keyboard... you made me snort-coff my coffee onto it.

Easy fix: add a gajilion tracking scripts

I like to complain about bloated websites as much as the next guy, but isn’t one of the curses of the modern web precisely that the main response often doesn’t contain more than some linked scripts and is thus very small? How many of these emails do they send?

I can imagine this job website implemented this criterion to guard against some kind of abuse but I cannot imagine what that abuse might look like or how this prevents it.

This made my day. Thank you!

I’m assuming that they implemented this for some well-intentioned reason like attempting to automatically prevent someone from halfassing it with inadequate information or content, but it was the wrong way to do it, and hopefully this calls them out on it.

A propose a toast to all of those that make life better by keeping things short and/or minimized. They are giving us our life and our bandwidth back.

A client once told me his website loads too fast and the branded spinner didn't show long enough. I "fixed" it by making the website load slower.

This is TopTal. I had the same issue. I am gonna just close the account, they basically nuked all my portfolio (all react apps that have less than 1kb initial payload, indeed too small to be proper).

the whole django site is more than 500KB, the other one more than 300KB.

how is that to small? just because not enough is included in the first http response?

any SPA that doesn't include server side rendering couldn't possibly be any larger as all it does is link to a script that builds the page. and SPA is the modern way to build sites, isn't it? or are you disqualified if your site doesn't support SSR, and the main content is images?

here is an idea for the above two sites: inline all the images and SVGs that will reduce the number of hits and make the page load faster. django should be able to do that. (the encoding of the images will make them a bit larger, but i hope compression can recover most of that).

The irony is thick.

Surprised how such a small website has problems with browser compatibility.

In Safari 15.6.1 (2022), half of the CSS is not loading properly: background color, menu, link colors, and fonts etc.

@layer defaults {

  a:not(.toc-backref) {
   {
      --textDecorationColor: var(--linkDecorationColor);
      text-decoration-color: var(--textDecorationColor);
      text-underline-offset: auto;
      text-decoration-thickness: 0.15rem;
    }

I would be curious about this comment at the OP site from yesterday as a proposed or contributing cause for such a mysterious limit, it does carry a ring of adversity via absurdity. I do remember the early days of gzip encoding, many apps suffered from confusion over transport vs. delivered content-length.

"[cratermoon] I did a bit of testing using curl and found that with -H 'Accept-Encoding: gzip, deflate, br, zstd' the resulting content-length: 6216 matches the gzipped response. However, without that header the result is not compressed and the response is content-length: 22411. The same difference applies to your other site.

"I wonder if whoever emailed you has crossed up their query and whatever tool they are using is mistakenly complaining because it's expecting 22411 bytes and only getting 6216."