[Resolved] Header & top bar background semi transparent on scroll using sticky command

Hi,

I created a class for the buttons inside the top bar to fix the text size and font family.

Wondering, in mobile view will the top bar disappear?

Please advise

Hi,

Thanks for getting back.

I applied all including the code in example 8 referred to in the article.

I created a class for the top bar buttons to fix Allex Brush and large font size being transferred to the buttons.

I couldn’t figure out how to get rid of the huge margin that was there.

I tested the layout all screwed up as is and I got a Cumulative Layout Shift in the 0.125 range.

It seems that all these solutions of putting hooks in the header make that the initial layout is displayed and then shifted to the other layout. Maybe it also has to do with the resizing of the buttons and change of font inside them.

I went away from page builders to get rid of uncontrollable layout shifts. I will live with what I have now as it seems unplausible to achieve the results that I am seeking without CLS going out of control.

I do have something that is driving me nuts. The top bar is 42.59px down from the header. Go figure I had no idea that pixels could be split like that! If I put that value to make the site header stick it works well on android devices and pc with all browsers. On Apple or webkit devices I guess I get a gap between the top bar & site header. I tried 42px, 42.59px and 43px no combination works. How do I make that top bar a round number to fix the issue on all devices and operating systems?

Please advise.

Hi,

I have been working on this header layout way too long.

I came to these conclusions to avoid cumulative layout shifts:

The name says it layout shift. Essentially you can’t do a “native” header layout then hook in stuff or change the layout without introducing layout shifts.

Something as commonplace as adding or removing some padding or margin in “Additional CSS” introduces layout shifts.

In order to fix the issue of having the gap between the top bar & site header being solved on all devices without introducing layout shifts I had to add in Customizer > Layout > Top Bar padding on top and bottom until I got to 43.59 pixels. Important not in “Additional CSS” I then applied the code that you supplied with a minimum height of 44 pixels. As a result a cumulative layout shift of 0.05. Retina or high density screens use a multiplier of 4. The minimum height had to be a clean divider of 4.

The more I work on this header it becomes clear that there is no way to do better than what I have now without introducing layout shifts.

Aside being really easy to use page builders suck. They introduce a gigantic amount of unused CSS & JS essentially bloat. It hinders performance considerably. Using plugins like AssetCleanup or Perfmatters Script Manager to remove per page, post or site wide CSS & JS until the site breaks will help & still it will be overly bloated. All the page builders or site builders that I tried so far being Elementor or Oxygen introduce substantial layout shifts.

GeneratePress with GenerateBlocks kicks ass in all aspects. Building a header without introducing Cumulative Layout Shifts is just a series a compromises. It’s very restrictive in the choice of layouts but that’s the way it is.

In May or June when Google introduces into their ranking algorithm the page experience factors MAYBE at that time developers of themes, plugins & page builders will code in consequence. Introducing large layout shifts using hooks or changing the layout in the viewport was never an issue until Google decided it was 😉

I already had the site-logo & featured-image CSS classes & the name of files of the flags excluded from lazy loading. Essentially any image in the viewport.

Thank you for the code for the minimum height.

Hi,

I agree on Oxygen it is less bloated & themeless. It does have a lot of bells and whistles that advanced developers could find interesting.

Using their header builder I was unable to bring the CLS lower than .300 no matter what I did. I also faced a lot of page layout issues that their support team were not able to fix. The support response is two to three days… They also don’t support WPML it’s really buggy.

I was unable to make WP-Rocket work with Oxygen even after reaching out to their really good support. They tried really hard. Intermittent display issues.

The bottom line is that GeneratePress combined with Gutenberg GenerateBlocks is leaps ahead stability & performance wise. Very well coded and lean. There is no comparison. An average of 250ms in Pingdom speed tests!!! Without a content delivery network and edge caching!!! These are not empty content pages that performance freaks gloat on. Its rich content with a lot of images. Can’t wait to see the results with everything on.

Since I have been using GeneratePress with Gutenberg & GenerateBlocks I did not face a single bug. Only issues I have been facing is to display the header like I want it without cumulative layout shifts out of control. As a bonus you guys offer above & beyond support.

Prior to making a purchase decision on any plugin or theme I pass their website through Lighthouse, GT-Metrix & Pingdom. The results speak for themselves. I could optimize generatepress.com with my eyes closed and easily double the performance. Tip: install WP-Rocket and turn everything on in the “File Optimization” tab. Also add perfmatters prelad, prefetch and remove css per page with the script manager like what is stripe doing on your home page.

There is no such thing as a gourmet free lunch. You always get what you pay for. I don’t believe at all in free plugins & themes or anything free. It think it’s a disease of a vast majority of the WordPress community. They expect free plugins. They wouldn’t work for free & expect others to do so.

Straying off.

After looking at all the header layouts “example 8” would be the one that I am looking for. If the layout stays the same as I have it now in mobile. The idea is to have a bigger site logo in desktop to populate the existing free space on the left that now looks odd. Do you think it is possible to acheive those results by keeping the cumulative layout shift under .100?

Hi,

All the optimizations you mentioned are already done. I am purposely developing with Varnish on the server, WP-Rocket & perfmatters for all optimizations. I am clearing caches everywhere constantly 😉 It gives me in real time the cumulative layout shift as I do modifications. I had way too many issues in the past with cumulative layout shift & it’s easier to find the culprit & troubleshoot.

The trick is that all layout shifts must be done before the breakpoint of 500 ms when lighthouse starts measuring them. I find the breakpoint of 500 ms too short. Who can argue with Google… It’s easy to achieve on desktop when the whole page loads in an average of 250 ms. Not as easy in mobile when it loads in around 1.2 seconds.

Using hooks, PHP & then CSS above the existing theme PHP & CSS to my experience are not a great idea to do in the viewport at page load to keep cumulative layout shift in line. On a header, it now seems bad practice with the new page experience metrics introduced in Google’s ranking algorithm starting in May. Who cares lower down the viewport CSS, PHP & hook to death. Before that was the mindset in the header. Bah it shifts, who cares.

I will try the layout again right away take it to the end and see.

Have a look at the top bar that’s squeezed to the right and the large left margin that I previously mentioned.

I moved the content from the top bar widget to the header widget and applied the code in example 8 it’s starting to move in the right direction.

The site logo is not reduced to 192px.

The menu widget is now displayed in tablet & in mobile 🙂 It’s underneath the menu & logo instead of on top where I would like it to be.

The spacing of the second button in the menu widget “SMS” is way out.