@kommo
Thanks. Quite a bit went in to this one from an optimisation perspective for looks and speed.

The above the fold section is an ALB color section with background image. I have set a minimum height depending on the image requirements for each screen size (Either 350px or 600px). I then applied a custom class and custom ID to each to set the height depending on the screen size. This removes issued with CLS in Google Web Vitals because the sizes are explicitly stated early.
If you view source in Google Chrome you can see the code added as critical CSS into the header. I used wp_head to add code directly into the header from functions.php.

Most of the mods come from a performance perspective:
The logo and srcset images are pre-loaded so the logo is available as early as possible.
Self hosting fonts and Adding font preload manually from functions.php just like the other critical CSS. This prevents Font Swap (Flicker) from occuring as the fonts are available right away.

To improve LCP and FCP scores you can either pre-load the background color section image in the same way as the fonts so it is available right away or add critical css in the way that I have – serving a different image size per screen size.

I use critical CSS on Burden Basket because of the minimum height applied to the ALB colour section.

To ensure the images look right on all screen sizes I have used media queries to load a different banner image per screen size on every page.

I have enfold setup to have mobile break points at 989px instead of 767px. I do this in the Enfold control panel and every column element on every page .

As the page scales down (if you resize the browser window) I have used media queries to change the menu font size and padding so that it works on screens all the way down to 989px. You can adjust the mobile breakpoint if required to lets say 1024px (for ipads) with some custom CSS. If you search the forum you’ll find this one.

Although most sites read Left to Right from a mobile design perspective – Put the first image on the left – This will mean users see picture content first in the same way people are familliar with on social media. Its good UX design to do it this way but looks a little unusual on desktops. You could always set two images and hide the first one on desktops if you prefer them the other way around on different platforms.

I hope this helps.

Unoffocial response:
Have you tried using something like WP-Optimize to clean the database?

Please use with caution. It will delete all post revisions and posts from the bin and spam folders.
I use this with every website I design. Helps lean up the database and keep things running smoothly.

250 posts is quite a lot. I have a couple of Ecommerce sites that have breached a 200mb database but these have a few thousand products.

Hi Ismael,

I have just raised an issue regarding the New G4 track codes when i saw this post. In 4.8.3 release the new G4 track codes break the Cookie Consent Modal (this has happened before with a previous Enfold release).

When a new G4 tag is added to Enfold in the tracking code box, Cookie control does not work and the script gets loaded anyway.

I can still see data in the Analytics console though but there is definitely a bug with the latesg G-XXXXX tags.
My post is here if it helps:

I tried the same sites with an old UA-XXXX code and it works OK. So I can see a problem with new G4 G-XXXXXX codes.

Been a bit quiet on the social posts lately! Lots of work for existing customers but we have a couple of new launches this month:

Holding page designed for a company selling CBD oils and topical creams (all legal in the UK as a food supplement if you were wondering). The company is based in the UK and provides some of the highest quality Pure CBD oil on the market.

The holding page was set up specifically as a funnel for the companies main website (which I have not been able to persuade over to Enfold yet!). The layout has menus turned off.

https://www.hemppureoils.co.uk

Page speed is important for a landing page. The Hemp Pure Oils site scores 98/100 on mobiles on a good test run. However this varies depending on how well the server responds etc. LCP sits at 2.3 seconds on a good run but rises to 3.6 seconds on a bad run.

Some critical CSS is loaded in WP Head to improve the FCP and aid the LCP but more is required for a bigger impact.

The site uses free optimisation tools and does not use a CDN at this point in time showing just how good Enfold is as a platform for websites compared to others like DIVI and Elementor which all require more work to get a 90+ score in page speed insights.

I hope this proves useful for anyone else looking to build a fast and easy to edit landing page.

Thanks @ismael

Looks like your solution works but has affected the layout slightly.

@sldeutsch site appears that the layerslider is served at the same height on all screen sizes excluding one.

I just encountered a similar problem on a client site with an ALB background element that becomes 1400 pixels tall on mobiles.
The layout shift was 2.48 then down to 0.99 with a min-height on the element within Enfold and then down to 0.01 with an explicitly stated height as per your solution.

Setting min-height alone only works if the shift on mobiles is minimal so I added the following height:; css.

This is a specific case where the elements stack. The LCP score is still a bit high but very hard to optimise because the design calls for such a large first element which stacks on mobiles.

But you get the idea:
-serve different background image for smaller/taller screens
-set fixed height for those elements for different screen sizes

/* Media Rules for ALB Colour Element Hero Images */

/* mobiles  */
@media screen and (max-width:767px) {
#main-banner-1 {background-image: url(/wp-content/uploads/cbdbgd-wood-5-767-1500-1.jpg)!important;}
}

/* mobiles  */
@media screen and (max-width:767px) {
#main-banner-1 {
min-height:1400px !important;
height:1400px !important;
}
.tj-main-banner-style {
min-height:1400px !important;
height:1400px !important;
}
#main-banner-1 .container {
min-height:1300px !important;
height:1330px !important;
}
}

/* Desktops  */
@media screen and (min-width:768px) {
#main-banner-1 {
min-height:689px !important;
height:689px !important;
}
.tj-main-banner-style {
min-height:689px !important;
height:689px !important;
}
#main-banner-1 .container {
min-height:689px !important;
height:689px !important;
}
}

• This reply was modified 3 years, 7 months ago by thinkjarvis. Reason: Correction

@ismael

Sorry I have just realised I missed the closing brackets in my code snippet I have edited my response. Sorry if I have made the job harder for you!

@Ismael is right with his solution.
Start from the top of the page and work downwards. CLS shift tends to only apply on above the fold because the rest of the page loads out of view.

If you can remove the shift from the first element on all devices then the rest may no longer be an issue. As they are all ALB colour sections, if you know that it will dynamically resize, set no minimum height. If it has a background image set then you may still experience some shift. You will need to create a version of the code below for that element.

The Layerslider needs an explicitly stated height to prevent shift. ALB background elements and Sliders also have this issue. You essentially need a few rules to match the design:

Below is suitable for the layerslider. HOWEVER you may need to apply it to the colour section and the background image as well to prevent the shift. I tend to set a custom ID so that the rule only applies to this element. See how you get on with the below:

/* Desktops 1080p */
@media screen and (min-width:1441px) {
.home #layer_slider_1 .ls-wp-container, .home #layer_slider_1 .ls-wp-container .ls-inner {
    height: 271px !important;
}
}

/* Macbooks, 720p and ipad pros  */
@media screen and (min-width:1025px) and (max-width:1440px) {
.home #layer_slider_1 .ls-wp-container, .home #layer_slider_1 .ls-wp-container .ls-inner {
    height: 272px !important;
}
}

/* Ipads landscape */
@media screen and (min-width:769px) and (max-width:1024px) {
.home #layer_slider_1 .ls-wp-container, .home #layer_slider_1 .ls-wp-container .ls-inner {
    height: 271px !important;
}
}

/* Ipads portrait */
@media screen and (min-width:451px) and (max-width:768px) {
.home #layer_slider_1 .ls-wp-container, .home #layer_slider_1 .ls-wp-container .ls-inner {
    height: 271px !important;
}
}

/* mobiles portrait */
@media screen and (min-width:361px) and (max-width:450px) {
.home #layer_slider_1 .ls-wp-container, .home #layer_slider_1 .ls-wp-container .ls-inner {
    height: 321px !important;
}
}

/* Moto G4 portrait */
@media screen and (max-width:360px) {
.home #layer_slider_1 .ls-wp-container, .home #layer_slider_1 .ls-wp-container .ls-inner {
    height: 271px !important;
}
}

• This reply was modified 3 years, 7 months ago by thinkjarvis.

What kind of server are you using apache? or NGINX?

Most NGINX servers prevent the built in script merge loading. I have experienced this with WPEngine hosted sites. They seem to ignore the script merge when it is enabled (even after the cache is cleared with the CDN disabled).

Third party plugins like WP-Rocket will still work. However the server will likely be http2.0 meaning that script merging is not so crucial.

Try using Google Chromes built in Lighthouse testing set to mobile with throttling turned on. It gives better ‘lab’ conditions and because it is browser based it can work on test servers.
You can then cross reference it against GT Metrix, Page Speed Insights and WebPageTest.org