Well, https://jmail.world/jacebook-logo.png is 670KB by itself and loaded on initial load, so I think they might have blown your suggested traffic budget and still have some optimization to do.

▲

AceJohnny2 43 minutes ago | parent | next [-]

How is that image 670 KB!? Definitely some optimization low-hanging fruit there.

Edit: dang, even pngcrush can't get it below 580 KB. Disappointing performance on PNG's part.

▲

the_fall 22 minutes ago | parent [-]

Because inexplicably, there's random pixel-level noise baked into the blue area. You can't see it unless you crank up contrast, but it makes the bitmap hard to compress losslessly. If you remove it using threshold blur, it doesn't change the appearance at all, but the size is down to 100 kB. Scale it down to a more reasonable size and you're down to 50 kB.

Modern web development never ceases to amaze me.

	▲	SahAssar 11 minutes ago \| parent \| next [-]
		None of this is due to "modern web development". It's just about a dev not checking reasonable asset size before deploying/compiling, that has happened in web, game-dev, desktop apps, server containers, etc. etc. This should be an SVG (a few kb after proper compression) or if properly made as a PNG it'd probably be in 20-ish kb.
	▲	car 14 minutes ago \| parent \| prev [-]
		Make it an SVG and it's down to 1kb.

▲

heipei 4 hours ago | parent | prev [-]

Fair enough, I just loaded some pages and some of them are even bigger than 2MB. But then again those static resources would be cached client-side. So unless you have 450 million unique visitors who only ever go to one URL on your site, you are looking at significantly less per pageview. I reloaded the frontpage with caching enabled and it was ~ 30kB of data transfer.