Currently doing the simple parallax effect of background-attachment: fixed and background-size: cover only to realize that iOS does not want to play nice at all with background-attachment: fixed At this point given the repaint costs as well, I want mobile/tablet to not have background-attachment: fixed at all.
Which would be better, remove background-attachment: fixed from mobile or add it back in for desktop. Further more, which would be easier from a media query stand point. Repeating the same css over and over for different devices sounds like a bad time.
Also, trying to avoid JS as much as possible to maintain as much compatibility as I can with office computers who may have it disabled.
Related
I'm optimizing the speed of a WordPress website (on mobile only for the moment), with success except for CLS. The CLS became extremely high after optimizing CSS delivery (with WP-Rocket), but I don't see any layout shifts, even when I use Dev Tools (performance test). (on mobile)
Here’s the example : https://trustmyscience.com/israel-a-pratiquement-eradique-la-covid-19/
Results here, with CSS delivery optimization
So it seems to be an invisible layout shift, that Lighthouse perceive as a real layout shift. Lighthouse shows me the problem comes from <div class="entry-content body-color clearfix link-color-wrap progresson">. So, it seems to be related to some "wrapping" of the all article content, that maybe shifts into the background (without being visible), because of some CSS rules maybe ?
Here, the element with the highest layout shift
The element with the highest layout shift (detail)
When I deactivate CSS delivery optimization, CLS go back to almost 0 (but LCP is too high).
Results WITHOUT CSS delivery optimization
I need this CSS delivery optimisation because of LCP importance, but I also now need to solve this issue because of CLS introduction in Core Web Vitals, and need to find what Lighthouse is detecting as a LS. Also, maybe, Lighthouse needs a correction for that ? As it isn't a visible layout shift...
Do you have any idea on how to solve this ? Or do you think I need to reach LS developers to show them this ?
Thank you in advance for your help.
Regards,
The CLS is visible, it's the font.
Don't you notice that when you visit the page, the text gets resized? That's a common cause of CLS.
How to solve?
Serve your fonts locally. Do not use any plug-in like OMGF. Do it manually.
Download the fonts. Choose 2 fonts, one for body, another for headings. You won't need bold, italic, or bold+italic fonts. These will be applied by user's browser.
Convert to woff2 (only woff2 is enough, didn't face any issues)
Upload it to your server
Add font face CSS to declare the fonts
Apply the fonts using CSS elements
Disable Google fonts if you're using any WP theme or builder
Preload the fonts
This will solve the CLS problem, will also reduce the Total Blocking Time.
You might gain a bit in performance by self-hosting the fonts instead of making a call to the Google Fonts API, but fonts are not the main issue here. Javascript is.
There is a lot of Javascript on this website, so the main thread is busy downloading it, parsing it and executing it.
I ran both Lighthouse (with Clear Storage and Simulated throttling enabled) and WebPageTest with a Moto 4G profile.
As you can see from Chrome DevTools and WebPageTest, roughly 56% of the processing time spent on the main thread is due to scripting. Do you really need all of that Javascript?
Here is what I noticed in the Chrome DevTools Performance panel:
There seems to be 5 front-end.js scripts (and 1 min-front.js). Are they duplicates?
Do you need animations with gsap and ScrollTrigger?
Aren't lazyload.min.js and areimagesloaded.js doing the same thing? (I might be wrong)
Are you importing the entire lodash library? If so, try importing just the functions you are actually using.
Do you really need a polyfill for Intersection Observer? I think that all modern browsers support it natively nowadays.
CLS is basically the sum of all unexpected layout shifts that occur on a page. As you can see from the dashed orange line in the chart below, the 4 .woff2 font files contribute to the CLS: the first layout shift occurs as soon as the fonts are fetched.
But as I said, I would focus on removing all unnecessary Javascript. In particular, I would examine third-party JS like the one coming from choices.consentframework.com, which takes 1730ms to load and represents 25% of the content size (see below).
After JavaScript, focus on the images.
The Performance panel in Chrome DevTools shows a lot of requests for images. Are you fetching only the images that are in the viewport, or all the images that are on the page?
Most of these images are WebP and seem already optimized, but there are a few GIFs, which are really bad for performance. It seems that these GIFs are served by https://www.viously.com/ (I guess it's an Ad Server, it's the first time I see it).
Last but not least, double-check that all of your <img> and <video> have size and width attributes set. Images and videos are replaced elements with intrinsic dimensions, and forgetting to set sizes for images in your HTML is a common cause of layout shifts.
See also this article by Addy Osmani for a few more tips on how to optimize CLS.
First of all; Hi all! I'm just new in the community. I've been using stack overflow without an account for years since I've always been able to find my answers. This one I can't and it keeps bugging me!
I'm using text-shadow on a h2 element in the header of one my sites. It displays correctly on my desktop (current Chrome, Edge and Firefox versions). On my mobile (iPhone, current Chrome and Safari versions) it results in what you see in the via stack overflow linked image below.
In this image you'll see 'blocks' with some sort of gradient shade instead of text-shadow
Does anyone have any idea what happens here / seen it before and knows a solution?
Site: http://schuttershoeve.nl
CSS:
.content h2 {
text-shadow: 0 0 20px #000000;
}
P.S. you can't reproduce the error now; I've used media queries to remove the shadow from mobile sites as a workaround for now
Your solution is Polyfills.
I.e, use CSS text-shadow where supported, and use a css background-image, where unsupported.
See http://modernizr.com/ for detection of support of text-shadow among others.
Tutorial on how to use Modernizr: http://www.hongkiat.com/blog/modernizr/
TLDR:
Modernizr will add a CSS class .no-textshadow to your HTML element, if it detects that the browser does not support text-shadows.
Then it's a matter of providing a fallback in your CSS along the lines of .no-textshadow .text-stroke{}
SOLUTION: Ok, it had to do with a box-shadow in combination with the text-shadow. The gradients you see are the box-shadows. I decided to use a non-gradient box-shadow solution on all screen widths to make my text more readable. Thx for the input!
I know this has been asked before but I'm still not convinced there's not a workaround. The reason I'm not convinced is because I managed to keep those gifs animated on a website of mine by accident. I posted this in the chat here and with help from #CarrieKendall came up with this fiddle.
This is obviously not a proper solution so I wanted to post it here for you geniuses to pick apart and try to help me figure out how I can fix this problem (in a way that preferably is not too resource heavy)?
UPDATE:
Ok, so I tinkered a bit more with the jsfiddle and came up with this:
HTML
<img class="link" src="http://i.imgur.com/jsm0x2c.gif">
<img class="link" src="http://i.imgur.com/jsm0x2c.gif">
<img class="link" src="http://i.imgur.com/jsm0x2c.gif">
CSS
#-webkit-keyframes WIGGLE {
0% { -webkit-transform: translate(0px, 0px); }
100% { -webkit-transform: translate(0px, 0px); }
}
keyframes WIGGLE {
0% { -webkit-transform: translate(0px, 0px); }
100% { -webkit-transform: translate(0px, 0px); }
}
.link{
-webkit-animation: WIGGLE 1ms;
animation: WIGGLE 1ms;
}
It's strange, but it works. An animation that does absolutely nothing. Oh and I tried replacing translate with something like scale but that didn't do the trick. This is the "purest" form of this weird bug/solution.
That said though, I'm not quite satisfied yet. I'd love it if someone more knowledgeable than me could have a look at this and try to figure what is REALLY going on that makes this workaround... work. Hopefully there's something in here that can be used, albeit in a more elegant way.
Also, I have no idea how resource intensive something like the above workaround would be, so if someone could help me measure that that'd be awesome.
The same restrictions don't occur on a desktop browser. This is specific to the implementation of scrolling that Apple has on their mobile device. It's a hold-over from their older mobile devices to make sure scrolling stays smooth, as earlier iPhones made judicious use of accelerated rendering throughout their OS.
Triggering hardware acceleration changes the render path of the page. In a non-accelerated page, the browser renders directly to the onscreen texture. When scrolling, all other execution is stopped, because the smooth scroll renderer takes control of rendering. This is not limited to just GIFs. If javascript would have changed the page content, it would also not show until the page finished scrolling.
In an accelerated page, the accelerated objects are actually sent to the compositor. The compositor puts all the layers of objects in the right place, and then creates a composite texture to put on the screen. Scrolling is actually part of the compositor's job, and since the compositor is in charge of rendering from end-to-end, animations will continue.
Unfortunately, due to the design of Apple's system compositor, there is really no 'right' way. In fact, as Apple has been making updates to iOS, there have been changes to what is hardware accelerated, and what isn't. For example, in iOS6, preserve3d no longer triggered acceleration. Supposedly,
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
should still work. In your case, I believe it works because you are using keyframes.
In terms of performance/resource impact, your page won't use any more resources than any other accelerated page.
Have you tried -webkit-transform-style: preserve-3d;, -webkit-transform: translate3d(0,0,0); or other CSS selectors that might trigger hardware acceleration in your animations 0% and 100% or in the .link class etc... on the iOS device?
Read more from another answer to a similar problem:
- https://stackoverflow.com/a/10170170/1380685
.link{
-webkit-animation: WIGGLE 1ms;
animation: WIGGLE 1ms;
-webkit-transform-style: preserve-3d;
-webkit-transform: translate3d(0,0,0);
}
The solution came with giving "position:relative;
z-index:1000;display:block" css properties to the whole container that
holds the scroll element and there is no need to give translate3d to
child elements.
Reference URL's
http://en.kuma-de.com/blog/2011-12-26/494
http://indiegamr.com/ios6-html-hardware-acceleration-changes-and-how-to-fix-them/
http://cantina.co/thought_leadership/ios-5-native-scrolling-grins-and-gothcas/
It looks to be a problem others are having though:
http://en.kuma-de.com/blog/2011-12-26/494
-webkit-animation stops when scrolling on mobile safari
If you can get away with it you can use an old-school technique below to have animation persist with less resource intensive operations
You could always use the Base64 encoded asset technique within your initial loaded CSS file.
I recently posted to another question recently asking something kind of related. This way the animation is continuous and preloaded and cached for easy and fast recall via css. Also you can use SVG, PNF, JPG and many other image formats for scaling and re-sizing.
Please read the information posted on the link below to red more about this.
https://stackoverflow.com/a/25224086/1380685
https://developer.apple.com/library/safari/documentation/internetweb/conceptual/safarivisualeffectsprogguide/Using2Dand3DTransforms/Using2Dand3DTransforms.html
I am looking for a way to use css and viewport properties to force one div of formatted text content to take up exactly the screen width, regardless of the user specified zoom. Something like the reflow functionality some pdf readers have. I'd prefer not to use javascript.
Is that even possible? I am targeting the BlackBerry browser specifically.
Can't tell about Blackberry browser specifically, but here's a bit of general considerations:
Don't give your page fixed width, except maybe 100%; check on an actual device.
Don't measure things in pixels (except raster images), use pt, em and % where possible.
Be careful with floats and absolute-positioned things.
In CSS Sprites you will often find padding between each image. I believe the idea is so that if the page is resized then one image won't bleed into another.
I think this depends on the different types of browser zoom (best explained by Jeff).
However, I haven't been able to see this behaviour in my tests. Is this only a problem with older browsers? (I havent been able to test with IE6 at the current time so I'm counting that as 'old').
Should I still worry about leaving space? Its kind of a pain.
For instance :
A CSS Sprite I found for AOL has
padding between each image : VIEW
but The Daily Show decided not to
bother : VIEW
It shouldn't need to be padded, but when zoomed, especially in IE8 (betas more than the RC), there is image bleeding if there is no padding.
Best example is to go to Google.com -> Search, and zoom... you'll start to see "underlines" at the bottom right of the image as the zooming rounds up/down.
In theory, a 1px padding on all sides of a sprite should be fine.
Here's the sprite from Google (images)...
But when zoomed, the +,-,x icons bleed into the main Google logo.
Basically the answer is yes. Two years to the day after I asked this question will see the release of IE9. IE9 has this problem just as much - if not more than any other browser...
It's pretty infuriating because it's such a simple thing to fix.
With iPads increasing in marketshare - its's pretty essential to at least have a half decent experience with zooming un-uniform amounts.
I am going to have to put a single pixel border around every image to match the background color of the adjacent element (potentially different on each side). Fortunately I auto-generate all my csssprites based on an .xml file - so I can do this programatically without too much hastle. It's still a huge pain though...
Simon - My experience is that this is certainly still a problem.
In response to your second question, why not use transparent padding? (Perhaps you are still supporting ie6 and this is non-trivial, in which case, I'm really sorry).
Speaking of the older browsers (those using text zoom), you don't always need padding.
The main difference between your two examples is that the Daily Show sprite already includes the menu item's text in the image itself.
When using text zoom, the AOL menu items could stretch out vertically due to the larger font size, and the menu text might even wrap to two lines. To accommodate for such eventualities, those icons need a little padding to ensure they don't bleed. Typically, you'd just try to make sure it doesn't bleed on any of IE6's five text sizes.
Since The Daily Show's menu doesn't contain any (visible) HTML text its size won't be affected by text zoom (though you might need a line-height: 0; or so to be sure), so it doesn't need any padding.
As scunliffe already showed, browsers using page zoom may need sprites to have a little padding due to rounding errors.