Page Load Times

[graphicz]

I have now added the webslidemenu.css from its file and added it as a layout and added that to the head as critical styles. The layout incorporates the SD php css minification.

I had to add the following to it.

header+span.full-width{
background-color: <actinic:variable name="megaMenuBGColor" />;
-webkit-transition: all 0.1s ease 0s;
-moz-transition: all 0.1s ease 0s;
transition: all 0.1s ease 0s;
}
header+div+span.full-width.isStuck {
border: none;
background-color: <actinic:variable name="PaletteBG" />;
background-image: linear-gradient(141deg, <actinic:variable name="PaletteBG" /> 5%, #22536b 53%, <actinic:variable name="PaletteBG" /> 77%);
}
header+span.full-width .wsdownmenu, header+span.full-width .wsdownmenu-list > li > a, header+span.full-width .wsdownmenu-list > li a.header-sub-link, header+div+span.full-width .wsdownmenu, header+div+span.full-width .wsdownmenu-list > li > a, .page-list li a{
background-color: transparent !important;
color: #fff;
font-weight: 600;
text-transform: capitalize;
text-align: left;
}
header+span.full-width .wsdownmenu-list > li > a:hover{
color: inherit;
}
header+div+span.full-width .wsdownmenu-list > li > a:hover {
color: inherit;
}

I thought that now actinic.css could be asynchronous but page loading did not exercise correctly.

I tried straight loading of actinic.css in the SubBodyCode but issues again!

So back to the Head Code. Just experimenting!

[graphicz]

Using critical css inline and delayoing the rest of the actinic.css has not been successful.
The image resizing is very successful but at a price, whilst making the live site faster it has slowed down the desktop instance causing a latency of several seconds which is unmanageable. Sucj a shame.

Here are the page generation times:
<!--[time:ms]2.142ms[time:ms Head Code]-->
6.791ms
<!--[time:ms]8.933ms[time:ms ux header]-->
3.544ms
<!--[time:ms]12.477ms[time:ms Mega Menu]-->
3724.71ms
<!--[time:ms]3737.157ms[time:ms brochure page body]-->
1117.732ms
<!--[time:ms]4854.889ms[time:ms best sellers]-->
1732.063ms
<!--[time:ms]6586.952ms[time:ms new products]-->
1.641ms
<!--[time:ms]6588.593ms[time:ms UX Footer]-->
1.473
<!--[time:ms]6590.066ms[time:ms sub body code]-->
0.048ms
<!--[time:ms]6590.114ms[time:ms Outer Layout]-->

Try Default Brochure Page Body
<!--[time:ms]679.216ms[time:ms brochure page body default]-->
3737.157 less
679.216 ==
3057.941ms

Try php compression
<!--[time:ms]3706.123ms[time:ms brochure page body]--> with section php compressed
<!--[time:ms]3673.337ms[time:ms brochure page body]--> add slider compressed
3737.157 - 3673.337 == 63ms saved!

Does anyone know how I can get these lumps of php to be quicker? Using an online php minifier barely save a few milliseconds!

NOTE:
Page generation time calculation courtesy of Hugh Gibson:

Put this at the start of the Outer Layout:

<actinic:block php="true" selectable="false" > $starttime = microtime(true);</actinic:block>

Then put this in the layouts to show the time. The [ ] means the comment is preserved by compaction:

<!--[time:ms]<actinic:block php="true" selectable="false" > echo 1000 * (round(microtime(true) - $starttime, 6)) . 'ms';</actinic:block>[time:ms]-->

[Mike Hughes]

Hi Jonathan,

I've been watching your reports with interest.

I got about as far as I could but the biggest problem Google PageSpeed insights seems to complain about is the CLS on mobile which I assume is down to the resizing css stomping all over everything once the page has been loaded.

PS. Desktop performance is always slow with preview enabled. I'm sure you know this but closing the preview windows usually avoids any slowness.

[graphicz]

The resizing is not done with css but with php.

[Mike Hughes]

The resizing is not done with css but with php.

Sorry, I was thinking about the dynamic page resizing rather than the image resizing you're doing. I can never remember if this is CSS or javascript.

I think I might have fixed my CLS (Cumulative Layout Shift) issue. I'll give Google some time and report back.

The problem I've identifid is that the top level contact detail images are all 42 x 42 whereas the CSS is sizing them at 44 x 44 and they had no height and width settings so the render engine was initially calculating them at a fraction of the space available in the layout.

Rather than mess about with the CSS and then have to regenerate the compressed files I've resized the images to 44 x 44 and given them each a width and height =44. On the lab data this gives me a CLS time of 0 and raises my overall mobile score from 63 to 93.

I'll give Google some time to see if it picks it up in the search console and report back.

[graphicz]

Putting height = "" and width="" in the img src is really important for page load even if the software makes the sizes different. In Sellerdeck there are Very Many instance of images without a height = and width= inline attribute but they should all have them thus:

<img src="<actinic:variable name="ProductImageFileName" />" alt="<actinic:variable encoding="strip" name="ProductName" />" title="<actinic:variable encoding="strip" name="ProductName" />" width="200" height="200" />

Adding height and width to all img src missing the expressions will increase page load speed even if the values you put are not the final ones!

[Mike Hughes]

Interesting.

So the one place I can see I'm not setting sizes for the images is on my section pages.

The actual img sizes are a mix of 400 x 500 (my current standard) and 200 x 250 (from older images) and these seem to be given max-widths by the css of 300px and 200px respectively so are being shown at 300x375 and 200x250.

What do you think would be the best width and height to give the images? Maybe 300x375 as that's the most common and the smaller images won't need any rendering changes to fit them in?

[graphicz]

It doesn't realy matter as they will be superceded by the sizes set elsewhare but it means the browser can apportion spave for the images so it loads more quickly.

300x375 sounds fine:

<src="image" width="370" height="300" etc etc etc

[Phil H]

Any update on how to speed things up from SellerDeck?

[Phil H]

How are Google Page Insight figures doing for people now? We recently had to transition from IONOS to SellerDecks Emergency Hosting following a mess of an 18.1 upgrade. We went from 50-80 on IONOS down to @23-30 on SellerDeck. So frustrating. I am working on images and trying to cut down the home page, but what are the other top things to do? I am on 18.1 and 'Swift'.