* https://tools.pingdom.com/

* https://developers.google.com/speed/pagespeed/insights/

* https://developer.microsoft.com/en-us/microsoft-edge/tools/s...

* https://observatory.mozilla.org/

* https://securityheaders.io/

* https://search.google.com/test/mobile-friendly

I'm sure there are a lot of others...

Also unless you have a fast website, people will drop off your site and google won't rank you. No point of having great images with good EXIF data if people never see the image.

For photography websites, it does make sense to keep it but in general no point wasting those extra bytes which add upto GBs in wasted bandwidth.

Sometimes, that can even mean making a website slower. I've had that request before because end users were surprised that the site loaded so fast. We made stuff slow on purpose so that the user thinks we are crunching data hardcore and giving their request some real thought before presenting the results.

Sure, if the customer asks for ultimate speed and explicitly does not care about image metadata availability, then removing that metadata is fine. But otherwise, removing those few bytes probably won't change how fast your website loads by a significant amount. You're better off working on caching, reducing TTFB, automatically adapting image size to screen size, spriting icons with http1, server push with http2, gzipping, reducing the size of Javascript/CSS and working on perceived speed. This will probably be orders of magnitude more useful to users than removing image metadata. And it won't remove that useful information from images.

Agree, that its not the first thing you should focus on. But saying you should not do it is what I was protesting.

When you run your site through speed analysis tools like the site posted or WebPageTest(my favourite), you do get a set of tasks based on priority and removing exif data is generally low and I am not advocating against that.

We added a fancy "computing... thinking... validating..." interstitial, and suddenly everyone loved it.

It was literally just an animated gif with a meta refresh redirect.

The overwhelming majority of the time, to "make a website that suits the customer's needs" == make it faster

One can imagine a variety of small things that are only useful to a minority of visitors, and go unnoticed by the rest. "alt" attributes on images are one example, that are often used by the blind, but are mostly unused by anyone else. Do you think provisions for the blind should be removed, due to wasting (tiny amounts of) data?

The alt tags are VERY important for SEO purposes.

Which is the case for listing pages of e-commerce sites, video sites, social networks etc.

As a frontend engineer, I find every way to achieve my goals as every ms matters :).

On a page with 100s of images removing the EXIF data from all the images would very likely have less of an impact than removing 1 image. Optimising is good, but you need to concentrate on optimising the right things. Start with the biggest impact and work downwards; chances are you'll never get to the point where stripping EXIF data makes a measurable difference.

Besides, if you're worried about every ms then you wouldn't implement a website that loads hundreds of images on to a single page in the first place.

Outside of photographers, who is going to do this? What percent of the web are photographers (real photographers... not "here's what I ate for dinner" photographers)?

Even if you somehow got 1% of the total web population, wouldn't that still fall into uncommon?

Compound this with the vast majority of web images are not works of art where you have photographers trying to dissect how the image was shot and I would bet uncommon quickly goes to once in a blue moon.

If you run a photography site then obviously the metadata is important to you and they would consciously keep it.

Tells me:

    Browser caching not enabled for all resources.

    Cache-Control:max-age=3600

Days, weeks, or months are more appropriate 99% of the time for 99% of content

If I'm given the choice, I usually avoid web fonts. Most platform's built-in fonts are usually pretty good and fast. It's fine for a website to look different on various browsers and operating systems.

Where as you if you cache the linked CSS file you only take the hit once but as you navigate around the site each time it'll be loaded from the cache.

It’s a pointless micro-optimization.

When your site has a large audience, every microsecond counts. Especially when you don't have someone bankrolling for your traffic. Speed plays an important part for SEO and UX.

There are so many other, bigger, better, wins to focus on first.

Considering anything Google does as useful for the average developer - even at a reasonably large company - is like thinking pizza delivery guys should emulate UPS: it’s a misunderstanding of context.

That's a damn lot of CSS

FWIW here's a pretty good analysis that shows even with h2, bundling and inlining still has benefits: https://sgom.es/posts/2017-06-30-ecmascript-module-loading-c...

It gives absolutely zero details about why it thinks it's not enabled, and does not say which are the affected "third party resources"... As a matter of fact I only have 1 third party resource (https://fonts.googleapis.com/) and it properly sets Expires and Cache-Control...

Although it is frightening that we need these in the first place, to be honest.

I frequently come across websites with several thousand lines of extraneous CSS/JS code laying around because they've imported multiple libraries (WordPress templates are usually a surefire way to see this). Websites use multiple MB images all over the place.

It's fucking insane. The web leaves everything to be desired from a development target, yet we keep trying to build a palace on a foundation of feces simply because the lipstick is so alluring.

Just as Eternal September ruined discussion on the web, basing the internet on the most poorly designed stack we could come up with has greatly hampered the speed at which we're able to advance humanity using it.

The same thing already happened with operating system development, where we used to have many differing options (with new ones coming out all the time), which for the most part sort of all worked together, but each had a different take on certain technical decisions, which we then gleaned valuable information from. Plan9 was the last well-known experimental OS to be released which actually made waves to operating system development (OpenBSD deserves a lot of credit here as well, as they're constantly thinking outside the box, but mainly in a security-related fashion). RedoxOS is the next OS project I'm peering into from a distance to learn from their decisions.

But I digress, that's why it's scary. The fact that everyone is wasting their lives trying to dress up a pig who only cares about frolicking around in the mud.

Unfortunately, that won't change because popularity dictates attention, and working on little experimental things that could truly revolutionize the world is far too risky for the vast majority to undertake.

Large companies are the only ones able to toy around with experimentation full-time, but the problem you come across is that they're usually going to make whatever they figured out proprietary, so they can make some money off it.

Never going to start a reply on a mobile device ever again, I hope my rambling was coherent enough =b

If we were using a better platform, dead code elimination and tree shaking would have handled those types of issues for us before clients see it.

Like, fuck me, we solved this problem what, 50 years ago? Yet we still haven't solved it? WHY IS THIS STILL AN ISSUE! </rant>

Anyways, it's a problem, yes. A few programming languages wouldn't even allow you to compile equivalent code.

If you're using those font styles later on, but still using the same stylesheet, that's obviously alright, the performance-testing tool would need to be updated in order to spider through all the pages to verify where each one is being used.

Does this offer anything more than WebPageTest.org, Google Pagespeed, or auditing in Chrome?

These tools complain that Google font's css is only cached for 2 hours. Which is something none of us can control. Even Google's own page speed tool complains about this. I get perfect scores in everything but Google fonts so it sticks out like an eye score.

It looks like the individual tiles vary in about 2-4 lines for the below-title description text, so I fiddled around for a bit, and it looks like this is just about right:

  .card {
      height: 25em;
  }

(just noticed the results page cards are a lot bigger, so probably scope that rule down to only the cards on the landing page)

This complains about alt="".

But maybe someone with real experience (not some hobbyist when it comes to front end work) should chime in.

> A purely decorative image that doesn't add any information In general, if an image is decorative but isn't especially page-specific, for example an image that forms part of a site-wide design scheme, the image should be specified in the site's CSS, not in the markup of the document. However, a decorative image that isn't discussed by the surrounding text but still has some relevance can be included in a page using the img element. Such images are decorative, but still form part of the content. In these cases, the alt attribute must be present but its value must be the empty string.

I have always understood that (and earlier spec incarnations) to mean that <img alt=''> is correct for these cases.

It probably blocked you but it's been over 5 minutes... https://www.screencast.com/t/CFkwelblQ