core web vitals issues with Google

[volteq]

we have recently upgraded to Cubecart 6, and have been going through improvements. we recently discovered that our whole mobile website has been flagged for performance issues. the desktop version seem to be fine with google, but the mobile pages all have the same issues. below are some sample product pages:

https://volteq.com/2kva-variac-transformer-2000va-0-250v-220v-input.html

https://volteq.com/volteq-regulated-variable-dc-power-supply-hy5005d-50v-5a.html

can anyone please suggest ways to improve the performance?

thanks in advance

[bsmither]

I see the Foundation skin. Foundation uses CSS to alter its layout based on the width of the viewport the browser gives to CSS. So essentially, the site will respond with everything to show the page whether it be 'desktop' width (large) or 'mobile' width (small).

If, by 'performance', you mean the time elapsed at which the site delivers the page (and its resources) to the browser, its all good for me.

If that is not what you mean, please mention what we should be looking for.

 

[volteq]

sorry I did not make it clear. Google complained about the LCP is longer than 2.8 second for mobile, but good for desktop. I am not sure what exactly is causing this discrepancy and how to solve the performance issue.

[bsmither]

According to:

https://developers.google.com/speed/docs/insights/v5/about

Google constructs a mobile environment by simulating the performance characteristics of a Motorola G4 (maybe using the data plan and not using Wi-Fi?). The desktop environment is a simulated tower box on ethernet.

So, from your observations, are you using the same device to make your comparisons? I used Firefox's "Responsive Design Mode" which does not simulate a "mobile network".

Please know that CrUX, PSI, FCP, FID, LCP, etc are above my pay-grade.

[volteq]

it's really frustrating working with google on almost everything, whatever they do, they make it so complicated:(

we have seen the core vitals going up and up like bi-polar disorder in the past, with us doing nothing on our website.

does cubecart allow image compression for product pages?

[bsmither]

Image compression?

CubeCart takes a source image, typically PNG or JPG, 750x750 pixels for example, then creates sized variants specific to the intended layout area and page. The source is uploaded to /images/source/, and CubeCart's variants are saved in /images/cache/.

The specific variants are coded in the skin's config.xml file. Take a look a Foundation's config.xml file in a programmer's text editor.

Here, you will find image nodes with the reference attribute indicating where the image is used. The product page uses 'medium' and 'gallery'. The maximum attribute specifies the length of the longest side, maintaining proportionality, but never longer than the original. (That is, if the source is 450x450 pixels, variants could be smaller, but will never be larger than that.) And, of course, the browser can scale the image to fit the layout's placement if the HTML coding allows it.

Note also the quality attribute. For many image formats, there is the 'compression ratio', expressed as a 'quality' -- 100 being very lightly compressed, if at all, and 10 looking like crap.

I have visited web pages that initially show a super-blurry image (high compression), then eventually, under javascript control, fetches a high-quality (large filesize) image to replace the blurry one.

Currently, CubeCart does not do this.

[volteq]

does cubecart allow text compression for product pages?

[bsmither]

Not directly, however, please examine the .htaccess file in CubeCart's main folder.

If there exists the following lines:

##### START CubeCart .htaccess #####

### GZIP Compression ###
<ifmodule mod_deflate.c>
	AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript
</ifmodule>

then these directives will compress text-type content of all content - not just the product page..

See: https://en.wikipedia.org/wiki/Mod_deflate

(Your hosting provider may have already configured the web server to automatically do this.)

[volteq]

Thanks! I was able to get the server side (hosting compan) to do compression, and that took care of this issue. I will check your code to see if it can add more compression.

Another thing I did was to compress the images using webp format, which also helps.

now the biggest issues I am encountering is related to render-blocking resources, and google fonts turns out to be a big one, specifically this one:

https://fonts.googleapis.com/css?family=Open+Sans:400,700

Not sure if we are using this, if not, how can we get rid of this?

 

Thanks again in advance

[bsmither]

Just remove the line. (But be aware that an upgrade will replace the edited file. CubeCart upgrades are 'whole-cloth'.)

 

[volteq]

thanks for your comment. where can I find this line that uses google fonts?

I have been searching for hours for this code ...

 

[bsmither]

In Foundation's /templates/ folder, open the file element.css.php for editing in a programmer's text editor.

Delete the first line:

<link href="//fonts.googleapis.com/css?family=Open+Sans:400,700" rel="stylesheet" type='text/css'>

 

[volteq]

that does it. You are a life saver. Thank you so much!

with your help, I was able to get one of our page down to good performance, see this:

https://volteq.com/volteq-regulated-variable-dc-power-supply-hy5003d-50v-3a.html

however, even though Lighthouse reports 1.4s FCP and 1.8 LCP. the pagespeed test for core vitals still shows 2.7s and 2.8s. Very confusing, as the  "Diagnose performance issues" section shows numbers that agrees with Lighthouse.  

is page speed for core vitals showing old data?

[volteq]

I think most of the core vitals problems are addressed, except a yellow flag on Cumulative Layout Shift.

we typically have 3-4 pictures on the product page, and that somehow casued issues on the desktop with Foundation skin. A suggestion was given that we should define the size of the image instead of 80% that we used. mobile device seems OK.

My question is: if we do specify a size for the image, what size should we specify? would that cause problem for the mobile device?

Here is a link to product page, in case you need it: https://volteq.com/regulated-adjustable-linear-dc-power-supply-hy1503d-15v-3a.html

Edited May 27 by volteq

[bsmither]

Again, knowing the ins and outs of these metrics is above my pay grade.

Foundation is CSS controlled to perform as a 'responsive' skin from the mobile-first philosophy. That is to say, what Foundation is optimized for a mobile viewport, then adjustments, via CSS, are made to accommodate wider viewports.

 

[harrisorganic]

Hi Volteq, I like your quote, "we have seen the core vitals going up and up like bi-polar disorder in the past, with us doing nothing on our website." 

I have worked through a few of the issues you have discussed, but not cubecart. I have an old foundation-skinned website that was not built around LCP etc. with the results up and down for no reason.

Coreweb vitals shows no errors or issues on Cubecart for me running CC6.4.9. However, I run only one image at a time, with none under the text as you have. I am not sure if CC was designed to run images under the text, Bsmithers may want to comment.

I am quite impressed how the images under the text respond to the page size. I would try reducing the images by 50% and see if that reduces the CLS and LCP.

Bottom line, is the page index and crawled by Google and the search results are improving.

[volteq]

images are not the problem, but you need to compress them real hard! I used webp format now and typical size of the images are 20K or less, with the biggest ones 50-60K. We used to have pictures of 500K or even above 1M.

with CLS, I found most of them are coming from the main picture on product page. vertically the image causes the webpage to shift. we solved the problem by setting vertical size of the main picture.

currently among the core vitals measures, we mostly face accessibility and SEO issues, with accessibility consistently below 90, and SEO hovering around 90. please share your insight on how to take care of these issue related to foundation skin? 

[harrisorganic]

You are referring to this page. Pagespeed insights.

https://pagespeed.web.dev/analysis/https-www-harrisorganicwine-com-au-shop/z6wzgnyqig?hl=en&form_factor=mobile

I am happy with them all above 80.  Plenty of other things to do.