Pagespeed module updates this image to resize it but in the process it messes up the scale. Is there a way to keep the scale and resize it? (Similar to cropping the image)
The CSS on the image is:
height: 100%;
width: 768px;
object-fit: cover;
To report the rendered dimensions back to the server, this filter
injects JavaScript code to your pages which beacon the sizes back.
Any image that you have that uses object-fit: cover; is going to be extremely confusing to Pagespeed. After all, the visible part of the image changes depending on the size of the screen, so it isn't even really possible for Pagespeed's beacon to accurately measure and correctly guess how to crop and resize it.
Does disabling the filters solve your problem?
https://www.modpagespeed.com/doc/reference-image-optimize#resize_rendered_image_dimensions
ModPagespeedDisableFilters insert_image_dimensions
ModPagespeedDisableFilters resize_rendered_image_dimensions
Edit: You may also want to try replacing your < img/> with background-imaged CSS. It should work functionally identical, but I suspect Pagespeed will have a better time correctly interpreting it.
Related
I have a page run by Hubspot Blog and an image implementation with srcset, looking like this:
<img loading="lazy" src="
https://emobility-magazin.com/hs-fs/hubfs/Element%2023#300x.png?width=480&name=Element%2023#300x.png"
alt="Element 23#300x" width="480" style="width: 480px;" srcset="
https://emobility-magazin.com/hs-fs/hubfs/Element%2023#300x.png?width=240&name=Element%2023#300x.png 240w,
https://emobility-magazin.com/hs-fs/hubfs/Element%2023#300x.png?width=480&name=Element%2023#300x.png 480w,
https://emobility-magazin.com/hs-fs/hubfs/Element%2023#300x.png?width=720&name=Element%2023#300x.png 720w,
https://emobility-magazin.com/hs-fs/hubfs/Element%2023#300x.png?width=960&name=Element%2023#300x.png 960w,
https://emobility-magazin.com/hs-fs/hubfs/Element%2023#300x.png?width=1200&name=Element%2023#300x.png 1200w,
https://emobility-magazin.com/hs-fs/hubfs/Element%2023#300x.png?width=1440&name=Element%2023#300x.png 1440w"
sizes="(max-width: 480px) 100vw, 480px">
The issue: Google PageSpeed Insights test delivers as an opportunity properly size images, with a diagnozed problem with the image I mentioned above. It looks like the srcset doesn't work for PageSpeed Insights test and the image isn't resized properly.
Getting the test data directly through Page Speed Insights API the issue is diagnozed too, on the same way.
But, running the Chrome-own Lighthouse test outta Developer Tools (incognito mode), the issue isn't there - the image seems to be properly resized by srcset.
My question: is there something, what prevents correct resizing while testing by PageSpeed Insights test? Are there any issues in my srcset implementation? Or is this a kind of bug of PageSpeed Insights?
So there's a couple of things going on here:
All your images are the same 6510x10194 images. So the audit is correct to highlight the image as improperly sized. Is the width param supposed to result in different size images being returned?
I'm not sure why it's not failing the audit on desktop. I can repeat what you see but to me it should be failing there too. So PSI looks more correct here.
Your sizes attribute looks incomplete to me. Maybe that's what's throwing off the browser for point 2?
When I run it through https://ausi.github.io/respimagelint/ it gives the following output:
W descriptor doesn’t match the image size
Descriptor 240w doesn’t match the image size of 6510x10194 from …/Element%2023#300x.png?width=240….
Descriptor 480w doesn’t match the image size of 6510x10194 from …/Element%2023#300x.png?width=480….
Descriptor 720w doesn’t match the image size of 6510x10194 from …/Element%2023#300x.png?width=720….
Descriptor 960w doesn’t match the image size of 6510x10194 from …/Element%2023#300x.png?width=960….
Descriptor 1200w doesn’t match the image size of 6510x10194 from …/Element%2023#300x.png?width=1200….
Descriptor 1440w doesn’t match the image size of 6510x10194 from …/Element%2023#300x.png?width=1440….
A fitting image source should be available for all screen sizes
At a viewport of 1280×720 the image was displayed 480 pixels wide, but the closest provided image has a width of 6510 which is 93% (66 megapixels) off. The affected viewports are 300×169–3000×4000.
Try using the following image sizes in <img srcset="…"> instead:
260×407, 480×752, 760×1190, 960×1503
Loading a large image and display it much smaller should be avoided to save bandwidth. Loading a small image and display it much larger should be avoided to prevent pixelated artifacts.
The sizes attribute has to match the width of the image
The size of the image doesn’t match the sizes attribute (max-width: 480px) 100vw, 480px. At a viewport of 1000x563 the image was 424 pixels wide instead of the specified 480 (-12% difference). The affected viewports are 300x169-480x640, 780x439-940x1253, 1000x563-1020x1360.
Try using sizes="(min-width: 1220px) 480px, (min-width: 1000px) calc(28vw + 144px), (min-width: 780px) calc(50vw - 36px), (min-width: 560px) 480px, calc(91.67vw - 15px)" instead.
The sizes attribute is a hint for browsers which should tell them how large the image will be displayed. If it doesn’t match the real size, browsers cannot select the correct image source.
I'm attempting to move from font icons (icomoon.io) to SVG sprites. Is it possible to use SVG sprites without needing < svg > markup for each icon instance?
What I really liked about the font icons was that I didn't have to clutter my HTML with any additional elements to get the icon to display. I usually just targeted a simple class on whatever element I wanted the icon to display and then used pseudo selectors to display the icon, e.g.:
<h1 class="news">News</h1>
h1.user:before {
font-family: 'icons';
content: '\news';
}
That made a lot of sense to me, and all of my icons were easily managed almost completely in CSS. I rarely had to touch my HTML as long as my markup contained appropriate classes.
I've since switched my build system to Grunt and thought I'd give SVG sprites a try. Almost every1 article2 I3 can4 find5 on the subject says you need to add an additional SVG element to your markup wherever you want each instance to display, e.g.:
<h1>
<svg class="icon">
<use xlink:href="#icon-news">
</svg>
News
</h1>
That seems like a step backwards to me, at least in the management of markup. To me, an icon is usually presentation that should be separate from document structure. Are we doing it this way simply because of the state of SVG support in browsers?
Ideally, I'd love to be able to do something like this:
<h1 class="news">News</h1>
h1.news:before {
display: inline-block;
width: px;
height: px;
background: url(icons.svg#news) no-repeat;
}
This post seems to be closer to what I'm looking for, but I'm not sure of browser support and how to do it automatically in a build system like Grunt.
SVGs can be loaded as files exactly the same way as other images using <img> tags or CSS background, and can be used as sprites exactly the same way too. The only difference is that you have to specify the size you want it (because it's scalable, so the browser doesn't automatically know how big it is like it does with PNGs).
Depending on how you want to use the image, loading them this way may or may not be suitable as some SVG features aren't available, but it can be done.
When the slide transitions, the background image displaces below the carousel before going back to the correct position. This happens on every slide every transition (when clicking or waiting). Here is a GIF showing what happens. http://gyazo.com/350334669db0e76f6d2b6e80fce0aed3
I have looked through some similar questions (all resolved). Only one seems it's the same issue, but the solution isn't applicable in my situation.
Here is the code. It is done mostly in jade with some html here and there. https://github.com/CastawayLabs/MCFreelancer/blob/master/views/index.jade
Your div was position:relative. Bootstrap uses position:absolute to perform the transition.
div.item(style='background: url(http://p1.pichost.me/640/25/1477731.jpg) no-repeat; background-size:cover; width: 900; height:400; position: relative;')
See patched commit
I'm making a page that will just display an SVG image, and here are the requirements:
the vector should take up the entire window
the vector should maintain its aspect ratio (defined in the SVG file itself)
the vector should crop/clip in order to prevent skewing
The CSS...
body {
background: url(/path/to/image.svg);
background-size: cover;
}
...works almost perfectly except that when the browser window becomes too narrow it tiles instead of cropping/clipping.
Here are some screen shots (please ignore the artifacts left by dabblet):
Here the window is close to the aspect ratio of the original image
Here the window is "shorter" than the aspect ratio, and the image is cropping (as desired).
Here the window is "narrower" than the aspect ratio, but instead of cropping, the image is tiling (undesired).
Here are some thoughts that I had...
Could I change the SVG image in some way to prevent this from happening?
Could I markup/style the page to achieve the desired results?
I would prefer to keep in the realm of HTML/CSS, but if Javascript is needed, then so-be-it.
Here's the dabblet that I was working with... http://dabblet.com/gist/6033198
After some trial-and-error, this is what I found.
Adding (to the original CSS):
html {
height: 100%
}
delivered exactly what I was looking for in the original spec.
Additionally, if I wanted the image to be center when it was cropped, I could use:
html {
background: url(path/to/image.jpg) no-repeat center center fixed;
background-size: cover;
}
Lastly, if I wanted it to be centered, always maintain the aspect ratio, but NOT be cropped (i.e., some whitespace is OK) then I could do:
body {
background: url(/path/to/image.svg) no-repeat center center fixed;
background-size: contain;
}
For me I had all other properties set except background-attachment:fixed. I had experienced the same issue on a site of mine for ages, one of the most elusive and infuriating bugs I've ever come across, but adding this to the html element seems to have finally solved it for me.
This css is working.Thanks
"background-size: contain;"
.cover{background:url(images/cover.jpg) no-repeat top center; display:inline-block; width:100%; height:400px; background-size: contain;}
<div class="cover"> </div>
OK I'm using SuperSleight to fix the background transparencies on the png images in ie6. It all works as it should except it is scaling my background image to 100% height.
I have the following set to 100% because I want my footer to stay at the bottom. It seems like this is affecting SuperSleight and is causing my background image to scale. For most people simply changing the background image format would work but Ive worked a fair amount trying to remove gradient rings and using a png came out with the best result. Does anyone know a fix for this?
body, html {
height: 100%;
min-height:100%;
}
body{
background-image:url(../images/content_bg6.png);
background-color:#3e2f24;
background-repeat:repeat-x;
}
I worked around the problem by creating a div wrapper for all the content within the body tag initialized supersleight to that specific wrapper and its children avoiding the body tag.
$(document).ready(function(){
$('#pageWrapper').supersleight();
});
The above is a work around.