removing width and height from embedded images??

[WebDesires]

ModPageSpeed is removing the width="" and height="" from images it is embedding into pages, I found some documentation that explained that the width and height attributes are not needed on embedded images, BUT lighthouse reports these are severe issues and flags up that they SHOULD have width and height.

Is there any way to stop MPS from doing this, and to leave those attributes on the image tags?

https://webpagetest.org/lighthouse.php?test=200810_T4_a4ac6e3cb8a53ba4f47116d39d1278fb&run=1

[Longinos]

Original images don´t have w/h attributes, so you can use

insert_image_dimensions

but inlined images are in data uri format and this format encodes in base64 the attributes w/h, so don´t have it.

To get it you need to disable the inline_image filter.

ModPagespeedDisableFilters inline_images

ModPagespeedEnableFilters  insert_image_dimensions

You may ask in the  https://github.com/GoogleChrome/Lighthouse/issues why data uri need w/h attributes when these are base64 encoded.

[WebDesires]

firstly I already had the width and height added to these images, secondly I already have insert_image_dimensions active.

My discussion is about inline_images, I obviously not looking to disable that. the goal of this post was:

1. To establish that modpagespeed is incorrectly removing width and height from embedded images, or lighthouse is incorrect to report an issue with that. Someone has to give.

2. If there were any options to stop modpagespeed doing this, as although they say "there not needed" I would rather they are there than not there simply to stop the headache of lighthouse reporting.

[Longinos]

As you can see in the image, no w/h is in place when ?PageSpeed=off, so is the original html

And yes, pagespeed removes w/h from inlined images as they are data:uris.

I think here is the code that deletes the image dimensions, but I don´t know why are deleted.

In the docs, only have encountered this.

https://www.modpagespeed.com/doc/filter-image-optimize

in the example 3 of the In-place optimization vs. tag rewriting paragraph.

[WebDesires]

sorry you are right, poor example page, anyway added all them but obviously as suspected same outcome.

I found this comment from a while ago explaining why they remove it, but honestly they either should have an option to toggle this behaviour or remove it entirely. in my eyes it serves no purpose doing this, and causes us more hassle with various other tools.

https://github.com/apache/incubator-pagespeed-mod/issues/55#c2

On Monday, 10 August 2020 20:11:29 UTC+1, WebDesires wrote:

[Longinos]

Maybe is a enhancement to do, but I think is not the momrnt for do it as far as the module is in a rebuild state to change a lot of things.

In PSI the w/h is needed to avoid a page reflow to draw the image with appropiate sizes, I don´t know if a data:uri need this reflow or not.

[WebDesires]

the problem really boils down to testing tools which will degrade scores if they are missing, im pretty sure MPS is actually right, but for the need to keep a client happy I'd rather they were there and no alerts were being created and scores degraded because they were not.

[David Scherfgen]

I know this is a very old thread and ModPagespeed isn't being developed any more, but I managed to fix this "bug" right in ModPagespeed's binary. For those interested, here's my write-up describing the process: https://www.david-scherfgen.de/fix-for-modpagespeed-keep-width-and-height-attributes-of-inlined-image-elements/

No compiling necessary, just byte surgery ;-)

Best regards

David Scherfgen

[Otto van der Schaaf]

Interesting! I managed to compile mod_pagespeed.so a year or so ago through https://github.com/We-Amp/mod_pagespeed. That contains a lot of work targeting to bring in a bunch of dependency updates, plus it also uses a new build system (bazel) + modernized build toolchain.

I have a little bit of time now as I exited my last job this week, I might just attempt to see if I can absorb this change to see if it passes tests, and maybe get a fresh module binary built based on that. 

(We also host/maintain modpagespeed.com, it would be nice to be able to publish an update .. but I haven't worked on updating the packaging yet for the module yet)

Otto

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/afdb983b-b6e0-4d39-92f6-623640e1b1e4n%40googlegroups.com.

[David Scherfgen]

It would be great to see some progress. As a year-long ModPagespeed user, I have some ideas about what could be improved. And today I actually managed to build the older release 1.13.35.1 with the old build procedure. As far as I can see, there hasn't been much functionality added since then. Now I can start to try fixing some bugs right in the source ... Maybe you'll hear from me via some Pull Requests.

[WebDesires]

The last I heard several years ago was that this was going through a "refactoring process" not that the project is dead, in fact its only been the last 2-3 years that ModPageSpeed is now part of easyapache 4 and easily installable so I assume this project is not dead just yet. I hope it isnt because its really quite good just needs more features and flexibility.

I would love to jump into the development myself at some point if I can find the time and join the development process...