Jump to content

core web vitals issues with Google


volteq

Recommended Posts

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • volteq changed the title to core web vitals issues with Google

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.

  • Like 1
Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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'>

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by volteq
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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? 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...