New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to avoid inline images on favicons (pagespeed_no_transform for <link>) #1022

Closed
GoogleCodeExporter opened this Issue Apr 6, 2015 · 4 comments

Comments

Projects
None yet
4 participants
@GoogleCodeExporter
Copy link

GoogleCodeExporter commented Apr 6, 2015

Using pagespeed version: 1.8.31.5-4307

We have a number of <link> tags on our site that look like this:
<link rel="apple-touch-icon" sizes="57x57" href=".." />
<link rel="apple-touch-icon" sizes="114x114" href=".." />
...
<link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32"/>
<meta name="msapplication-TileColor" content=".."/>
etc.

These are for favicons on a variety of browsers and platforms. Because they're 
small, pagespeed automatically inlines all of them, even though most browsers 
will only ever use (and download) one of them. Thus the processing time is 
wasted, and the HTML is actually inflated unnecessarily.

It would be fantastic if the "rel" attribute could be natively 'understood' by 
pagespeed and recognised favicon <link>s treated differently from other images, 
or, failing that, to allow the use of "pagespeed_no_transform" on <link> tags. 
I've tried adding it, but I guess it only works on <img> tags at the moment.

Original issue reported on code.google.com by ttim...@gmail.com on 19 Nov 2014 at 8:27

@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Oct 24, 2015

The idea is we would strip out "apple-*" unless we were serving to apple devices?

Are we sure no one else uses these links?

@jeffkaufman

This comment has been minimized.

Copy link
Contributor

jeffkaufman commented Oct 24, 2015

Sorry, I misread this. It's not that we should only send apple-* ones to apple devices, it's that typically only one is used, and so we shouldn't inline them.

Additionally, these aren't on the critical path, so inlining them is really not that useful.

@ArwedSchmidt

This comment has been minimized.

Copy link

ArwedSchmidt commented Nov 29, 2015

Same problem here, I think what he means is to auto-avoid the following output:

<head>
<link rel=apple-touch-icon sizes=57x57 href="data:image/png;base64,iVBORw0KG.....(4kb of base64)...">
<link rel=apple-touch-icon sizes=60x60 href="data:image/png;base64,iVBORw0KG.....(6kb of base64)...">
<link rel=apple-touch-icon sizes=72x72 href="data:image/png;base64,iVBORw0KG.....(7kb of base64)..">
<link rel=icon type="image/png" href="data:image/png;base64,iVBORw0KG.....(you get the point)...">
</head>

Since the browser will select and load only one favorite out of potentially 15 options, pagespeed is actually hurting performance/wasting bandwidth by inlining the other 14 unused ressources. The point is: don't inline anything and let the browser load that one resource on his own

Currently the only option to avoid this behaviour is to disable inlining for everything, am I correct?

@jmarantz

This comment has been minimized.

Copy link
Contributor

jmarantz commented Nov 29, 2015

Depending on your URL naming scheme, you can work around this problem with
ModPagespeedDisallow url_wildcard_matching_favicons
For this to work it'd be easiest to name your favicons with a common prefix or something to make them easily selected with wildcards.

This is not as good as having MPS just do the right thing by default, but might be a good short term workaround.

@jeffkaufman jeffkaufman self-assigned this Jun 22, 2016

crowell added a commit that referenced this issue Jul 13, 2016

image-inline: don't inline shortcut images
Because shortcut images don't block page rendering and generally aren't that important the tradeoffs are different for them, and we shouldn't inline them.

Fixes #1022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment