Getting rid of image metadata is _not_ optimization, that is simple information loss. I hate it when speed tests tell m the progressive jpgs are not optimized because they have EXIF; EXIF is part of the image.
Its not uncommon to download images from a website in general, however more specifically I know my mother - an avid photographer - uses a plugin to inspect metadata to find how and where a photo was taken.
That is not the typical use case. As web engineers one of our goals is to make websites faster. Speed is a very important UX.
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.
I disagree that as web engineers, our goal is to make websites faster. Our goal is to make a website that suits the customer's needs.
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.
Wow! I primarily work on consumer facing web products where speed does play a big part but glad to know where you are coming from. I have not had such request or perspective. :) Thanks for sharing your experience.
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.
Recall that EXIF data is textual, and therefore no larger than kilobytes in contrast to the megabytes that JPEGs otherwise take up. While this may eventually add up to gigabytes of bandwidth, it will only be after downloading terabytes of JPEGs.
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 same applies whether it’s the server or user bandwidth, the volume used by EXIF data is going to be tiny compared to the relatively incompressible image data you’re shifting.
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.
100s of images are 99% lazy-loaded, so not a concern.
Get rid of the JS bloat instead, which doesn't effect the download speed at all, yet cripples the receiving box with the client-side rendering.
That is actually very uncommon for the typical user.
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.
And then gives an example of a file that is delivered with this cache header:
Cache-Control:max-age=3600
Also it seems to put DNS resolv time into the "Server response time". So if you get "Slow server response time" that might be something that is happening between this service, it's DNS provider and your Nameserver. Then when you try it again, suddenly it's "Fast server response time" because DNS caching took place.
IMO, inlining styles is rarely worth it. Just include a single CSS file in the head and call it a day. There's value in simplicity.
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.
When your CSS file gets large. Which is the case in most sites today thanks to frameworks like Bootstrap. Your page will wait for the CSS file to download, process and repaint. Inlining some of the CSS i.e. critical path CSS can give you lighting fast renders.
Also, inlining CSS prevents its caching, so the first page load may be faster but subsequent ones will suffer from that if the amount of code is fairly large.
Google Chrome Developers/Google Developers Youtube channel has great content on Frontend optimisations by Paul Irish and others. They teach you what to measure and how. You might want to check that if you are interested in Frontend Engineering.
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.
I’m quite familiar with Paul’s work. He’s not really saying anything new in those talks either. It’s good technical info but again - a pointless micro-optimization in most cases.
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.
Not true. Even in h2, the browser will first parse the HTML to discover the `<link rel=stylesheet>` and it'll then go issue that request. In h2 it'll reuse the TCP connection (which is a win), but you've still got to round trip to start receiving the stylesheet response body.
It incorrectly reports that browser caching is "Not enabled for third party resources" on my site: http://blog.zorinaq.com
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...
We're not profiling ns/ms differences due to the weird ways that the Intel CPU decides to cache certain instructions due to idiosyncrasies, they're tools that literally spit out "stop using so many large assets so you can cut the load time to under 10 seconds" and "learn how to minify every type of file".
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
YellowLab complains about the number of webfonts in my CSS file, which us just stupid - fonts aren’t loaded if they’re not used, so why are they a problem? Because of the three lines of CSS needed to include them?
What? No, it’s definitely not a problem. If I include all the different weights of a font family in my CSS, but on some pages don’t use the bold weight, for example, how is that a problem? The browser only downloads the fonts that are actually used for exactly this reason.
What I mean is that the CSS should be minified to remove _any_ extraneous rules, and should be done automatically, just as it's done with most compiled binaries.
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.
I specify only the characters I use in custom fonts. I budget no more than 30kb to fonts when making a website.
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.
Hey UI point - you might want to set a consistent height for those grid elements in the list -- would do a lot to make the elements more consistently laid out.
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;
}
Of course, if you're going to set the height of the card you should probably go in and set the heights (in em or percentage) of the children elements, etc.
(just noticed the results page cards are a lot bigger, so probably scope that rule down to only the cards on the landing page)
I noticed the site is reporting JS and CSS sizes AFTER gzip, not before. That seems unnecessary. Browsers will download the compressed version, so it's the compressed version that determines the page speed.
> 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.
* 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...