Google Search Console - Poor Core Vitals

[phillipsrw]

Hi,

I'm using Square Online for our website, and in the process of improving SEO etc. We have noticed that for our Core Web Vitals that the Desktop has zero good urls and zero bad urls, is this to be expected or would you expect to see a few good and bad urls?

For the Mobile experience we see 132 poor urls and zero good urls, CLS, LCP, INP and FID being cited as issues.

We have removed things like video and moving banners on the website to try and improve these core vitals on the mobile with zero success. 

Any ideas or suggestions as to what we should be typically seeing, what steps we should be taking to improve these and whether we should be concerned and need to improve these for a better user experience?

[Stacelyn24 · Accepted solution]

Thanks for reaching out about your Square Online website. Since you've already removed moving banners and videos, great move! You can further enhance mobile-friendliness by optimizing images for faster loading times. Try compressing images or using formats like JPEG or WebP, which typically load faster on mobile devices. Also, consider simplifying the layout and reducing any excessive text or elements. These steps should help improve Core Web Vitals and provide a better user experience on mobile devices.

Let me know if you need more tips!

[phillipsrw]

Hi @Stacelyn24., we'll give this a go also. Just concerned that every mobile url is showing a poor, and zero needs improvement and zero are good which seems to suggest something more fundamental seems to be a problems with the mobile core web vitals. Desktop we are zero, good, zero needs improvement and zero poor. Again not sure if this is what to expect. My brain is expecting lots of good, some needing improvement and as few as possible needing work to raise from poor. Is my brain reading this correctly?

[phillipsrw]

@Stacelyn24 starting with our homepage, we have taken a look at the images, these are currently in JPEG format. We converted them to WebP (photos and backgrounds) but the Square Online system doesn't appear to support WebP, it's says Square does not support this file format. Also our pictures in our library, although uploaded as JPEG are automatically converted to WebP by the Square system, so these are all good. In regard to file sizes they are all as low as they can go with out looking awful.

Anything else we can change?

[phillipsrw]

Hi @Stacelyn24, we have tried everything we can within the editable parts of the Square system (we users get access to) to improve the mobile core vitals, but they are still coming in as poor, so 132 pages are dragging the mobile experience down. Over the Christmas period we had a few customers complain about the page load speed, and timing out during the order process. The pages are product catalogue pages and it would seem to imply there may be something in the coding not editable by the user that is dragging the performance down. As mobile browsing is more widely used than desktop browsing these days, I need to find an answer to improving this. Any thoughts?

Many thanks

[RobynR]

Hi @phillipsrw- sorry to see trouble has brought you to the Seller Community! 

Some of this does sound off, but it's difficult to pinpoint what may be happening without looking at your account with you.

The fastest way to resolve complicated Square Online questions is by reaching out to our team directly. The best way to reach out is by phone, because our team can look at your account with you and help you make adjustments in real-time.

If you haven't already, please reach out directly by logging into your Square account and heading here. 

[Stacelyn24]

Don't fret because you're actually dealing with some with several common performance issues affecting your website, particularly on mobile devices (that trust me...if you're working and building your website primary we all have been there). Let's break down each of these issues and potential solutions based off the attached photo:

1. INP (Input Delay) Issues:

   • INP, or Input Delay, refers to the delay between when a user interacts with a page (e.g., clicks a button) and when the browser responds to that interaction.
   • This delay can be caused by various factors such as heavy JavaScript execution or long-running tasks.
   • Solutions:
     • Optimize Javascript: Minify and compress JavaScript files, remove unused scripts, and defer non-critical scripts to improve loading times.
     • Use Web Workers: Offload heavy JavaScript tasks to web workers to prevent them from blocking the main thread.
     • Reduce third-party scripts: Limit the number of third-party scripts or defer their loading to prevent them from delaying user interactions.

2. CLS (Cumulative Layout Shift) Issues:

   • CLS measures visual stability by quantifying how much content shifts around during page load.
   • Common causes include images and ads without dimensions, dynamically injected content, or late-loading fonts.
   • Solutions:
     • Set dimensions for media: Specify width and height attributes for images, videos, and iframes to reserve space and prevent layout shifts.
     • Preload critical resources: Use resource hints like preload to ensure important resources load early and minimize layout shifts.
     • Avoid inserting content dynamically above existing content, as this can cause layout shifts.

3. LCP (Largest Contentful Paint) Issues:

   • LCP measures the time it takes for the largest content element on the page to become visible.
   • Slow LCP can be caused by large images, render-blocking resources, or slow server response times.
   • Solutions:
     • Optimize images: Compress and resize images to reduce their file size without compromising quality.
     • Minimize render-blocking resources: Identify and prioritize critical resources, and defer non-critical ones to improve loading times.
     • Improve server response times: Optimize server performance by caching resources, reducing server-side processing time, and leveraging CDNs.

4. FID (First Input Delay) Issues:

   • FID measures the time between when a user interacts with a page and when the browser is able to respond to that interaction.
   • High FID can be caused by long-running JavaScript tasks or UI thread blocking.
   • Solutions:
     • Minimize JavaScript execution time: Optimize JavaScript code to reduce execution time and prioritize critical tasks.
     • Use browser scheduling APIs: Break up long tasks into smaller chunks and utilize browser scheduling APIs like requestIdleCallback to prevent UI thread blocking.
     • Optimize event handlers: Ensure event handlers are efficient and do not block the main thread unnecessarily.

I tired to break down each one of the issues that it showed in the photo you attached.  I know that a lot of this can sound like a foreign language so I agree with @RobynR that you will get more help contacting Square Support to they can pull you account because they can see so much more and should be able to help you out...in the end it's usually something so small!  You got this 🙂

[phillipsrw]

Hi @Stacelyn24 thank you for the additional information and input. The issue I have is that the elements they suggest changing are aspects we can not access when using the Sqaure Online as it is a very fixed and standardised tempalate editing system i.e. all the suggestions appear to require getting in to the code aspects of page loading which rightly so we can not do, is this something that is a fundemental issues ie a common bit of code that sits in the Square Online page code causing this slow repsonse? I know we have a had a few customers complaiin about slow load times and pages timing out when they have used. This could be down to their hardware but may also be a webpage loadtime issue from the code on the page. Not sure how to take this forward as I doubt customer service will have the depth of knowledge to take on this issue? I will give them a go though and see if they can help.

Mnay thanks 🙂

[phillipsrw]

Hi @Stacelyn24 

Thanks for breaking down the issues, informative to see what is contributing.

The issue I have is there is very little flexibility within the Square's hard-programming to address these issues. We have done what we can in terms of images and video, the bits we can access. Having done this what else can we do to improve the vitals within the access points we have within Square? I was enquiring if the issues are resulting from the programming we can not access. Not suggesting for one moment we would want to access more than needed, but if its intrinsic to the Square programming we will not be able to improve the core vitals no matter what we users do and this will have to come from Square. Is this correct?

Many thanks