Google Core update and the very bad impact on meteor apps (FCP/LCP/CLS) - Desperate call for help

help
#1

Hi everyone,

Let’s be honest, that’s an emergency call! I’m facing an issue that is killing all the work I have put in my app in the last years. Since the new Core update of google 2 or 3 weeks ago the impact of Core Web Vitals on your Google ranking is very strong, especially three main values:

  • First Contentful Paint (FCP)
  • Largest Contentful Paint (LCP)

I manage to have a score of 82 on mobile on my website according to Google Speed Insight audit but because of poor values in FCP (5.5sec), LCP (5.4sec) my website has lost more than 50% of google searches clicks in the last 3 weeks… (from 2000 visitors a day early December to 700 yesterday and going down). I have competitor using Wordpress based solution, they score 7 (yes, seven little points) on speed insight but because of proper FCP they didn’t get affected whatsoever…

I am using a Meteor/Apollo/React stack with no SSR as I never found a way to implement it. I wish I could and have tried multiple time but there is no official support for SSR, no proper documentation nor example that works and is kind of updated with the latest packages.

I have implemented prerender.io since the beginning and so far was doing a great job to have good SEO but it seems it’s not enough anymore…

I am open to any idea, any tweak to solve this problem I am faced with in order to save my little business from losing everything… Thanks a lot.

Edit:
The site is https://www.whisky-hamster.com
if you need to run an audit or speed insight to find some insightful ideas…

I already removed the Mailchimp popup, removed fully the semantic-ui-css by keeping only classes/styling I need for myself, removed some images on the first page, improved the loading component to be prefilled at the proper size to avoid shifting, etc, etc… I get great scores but just the LCP and FCP can’t seem to get much better than this…

1 Like
#2

Some ideas I have:

  • Find a simple way to render some content from server side, without having a full implementation of SSR with Apollo. If someone knows how I could simply render premade HTML/Style without too much hard word to at least get some static content rendered, I guess that could help a lot already

  • implementing full SSR with apollo (not the latest client)/react but honestly I never succeeded, if someone thinks they can do it for me, I’m ready to pay to have it implemented… contact me in MP.

  • recreating the app with next.js: I’m a Meteor lover and user for years, I’d be very sad to have to go this path but the fact SSR has never been a clear part of the roadmap in meteor is getting more and more painful…

#3

This is a topic that I have had no connection with at all. But would this section be of any help to you?

Scroll down a bit to Serving a Static Landing Page.

#4

Thanks for your reply. What I need is to send static content but then it to be replaced by the frontend part when the site is loaded and I don’t thin webapp can manage this. It’s probably server-render but didn’t find clear example of how to manage :s

#5

You could try to append some html to the body of each response like this

import { Meteor } from 'meteor/meteor';
import { WebApp } from 'meteor/webapp';
import { onPageLoad } from 'meteor/server-render';


WebApp.addHtmlAttributeHook(() => ({ lang: 'es' }));
const LoadingScreen = Assets.getText('screens/loading.html');

onPageLoad((sink) => {
  sink.appendToBody(LoadingScreen);
});

The loading screen could be anything you want, so what i do is that on Meteor.startup I remove that loading screen node.

Hope this helps.

1 Like
#6

This comment gave me the best hint so far to solve the SSR issue without actually doing SSR.

I didn’t implement this in my own app yet, but I will soon; unless I misunderstand him, the idea is to have prerendering (locally or via prerender.io) in place, and to use the page snapshots in conjunction with the SSR API onPageLoad(). In other words, this is SSR without an actual server side rendering. This should solve your FCP and LCP problem at the same time. Let me know what you think.

#7

Prerender is already in place as mentioned in my post, but Google for the last month isn’t considering only its lab result from speed insight (which are very good thanks to prerender) but also real results from users: It means if someone visit your site, if they ticked the ‘I agree to send data to help Google blabla…’ they’ll send the real value of how long time it took for them to load the page. And these values are not help by prerender, could only be helped by real SSE. Thanks a lot though for the idea.

#8

That seems like a great lead, will try to implement this, thanks a lot!

Edit, managed to implement a very simple loading screen with a text and an image. I hope this will affect positively the FCP, thanks a lot for the idea.

1 Like
#9

That might help your FCP but your LCP and CLS will suffer because the content you are initially showing is not the final content that will be displayed to the user

The ideal scenario here is that your HTML version is pre-rendered just like in SSR, and then the app will hydrate over the same content without changes when the app is loaded. Therefore, your FCP and LCP will almost be the same and in such scenario, CLS is almost zero

#10

The idea here is to use the prerendered snapshots also to be returned in the SSR context. Thus real requests by users as measured by Google via Chrome will reflect the same result as if achieved via regular SSR.

1 Like
#11

@ivo I am using a Meteor/Apollo/React stack with no SSR as I never found a way to implement it. I wish I could and have tried multiple time but there is no official support for SSR, no proper documentation nor example that works and is kind of updated with the latest packages.

This is absolutely true
And I followed it from the beginning of entering the meteor. But to no avail.
And always refers to side packages like Fast Render and Prerender. And if there is a problem with these packages, the meteor rendering server will no longer work.

@filipenevola
Do you want me to speak clearly?

meteor has not provided any suitable rendering solutions for the server so far.
Yes, the meteor rendering server itself did not think of subscribing to the server, and the fast rendering package is very bad and the solution is not secure, and it is not even supported anymore, and the author is not responsible for the issues.

And unfortunately, what I have seen so far is that the meteor community has not been particularly sensitive to it.
Why don’t you ask the meteor officials for this? Why
If we all want this issue together, maybe it can be solved in version 2

#12

As I mentioned elsewhere

@captainn It is my wish that there is no problem in the meteor rendering server and that we can benefit from it.
And as you said, the only obstacle left is the previously reported fast rendering package problem.
@abecks But the problem is that the manufacturer of Fast Render does not have the necessary cooperation and apparently has abandoned the package support.
@filipenevola On the other hand, there is no serious will on the part of meteor officials to solve the ssr problem in meteor.

And always when we ask them this question, they refer us to side packages.
And the result is that now the whole ssr meteor is useless because fast rendering does not work properly

#13

As we can see, this update has caused the development of software such as Laravel and Express and caused the collapse of meteor software.

#14

Hi @saeeed,

I see you also posted the issue on Prerender.io github.
I can guarantee there is no issue with your Prerender. So, how that works is to preview your entire HTML based on your JS and CSS meteor bundle while it removes these bundles to only keep the optimized HTML without assets (fonts, images).

You actual problem I believe is your unoptimized images which add 1.5MB of useless weight to your first load.

You load a 1200x1200px image but rendered it in 180 x 180 px. You may photoshop this image at the exact size you display it (or 2x if you think it is not clear on a retina display) and compress to 60%.

Also it would be best if you served these images from a fast CDN with Edge caching and not from your Meteor public folder. Also in your HTML head do a prefetch to your CND: <link rel="dns-prefetch" href="//your_cdn_root_url">

Screen Shot 2020-12-22 at 09.04.42

Screen Shot 2020-12-22 at 09.05.17
Screen Shot 2020-12-22 at 09.05.171011×152 42.4 KB

2 Likes
#15

Hi @paulishca

Actually I’m this particular site owner and did not post the problem elsewhere but thanks for your input.

The images are loaded on a CDN not in the public folder, it’s just my own CDN.

image
image2360×86 30.6 KB

Not sure the cache is optimized though. Will have to take a look at it.

You have a point with the too big images and will try to have a smaller copy for these views indeed however they are lazy loaded on view and rarely needed for first print especially on mobile.

The main things is now that prerendering is nice but as google use real users data, loading the real site and not the prerenders, it’s not always enough.

@peterfkruger I like your idea to send pretender screenshots as SSR, but how can this be implemented ?? That would probably be the best workaround

@rjdavid Couldn’t agree more with your answer, the ideal scenario is SSR… however so painful, complicated to implement with Apollo/Meteor/React, tried, multiple times, never succeeded and can’t believe there is no official support for this… I understand your concern with the loading screen, will consider removing it then… until better solution is found.

#16

I run my own Prerender server and if I take it down and run a speed test, I get errors from Google Page Insight. Also when I check my network traffic on the Prerender server while running the speed test, I can see google hitting my Prerender twice. I believe if set correct, Google will always use your Prerender but this might not be the case for you.

This is what Google has cached for your website:

I believe in Google’s opinion your website is missing the actual body.

#17

@paulishca

That’s probably because of the waiting screen I tried to implement, I removed it this morning and did a recache now from prerender… though prerender was not being affected by the waiting screen so I’m two minded of why this shows.

What I meant is not that speed insight is not using the prerender page, that’s the case for the lab data, but they also now use real user data, the field data:

image
image1602×656 76 KB

and these are statistics taken from real user who agreed to send data to Google. I don’t think prerendering helps these.

#18

@paulishca

Actually I checked and some pages are cached like what you are showing even though they were cached on December 13, this could totally explains why My results drop but the main question is: what could cause this ? I did not change anything in prerender, I did not change anything big in my site recently and my SEO results were increasing very nicely and now I indeed see most of my pages have more or less empty pages showing off as cached.

also in google search I just did a check:

image
image2796×1612 327 KB

Not sure what’s happening now

EDIT: I checked and it seems prerender.io is the culprit. Most of my pages are wrongly prerender as the one you are showing. For new pages some are good some are bad, so somehow prerendeR.io doesn’t manage to prerender all of them as it should. I didn’t change anything on my side so I’ll contact them. I hope I’ll get back my ranking when this is solved but doubt it, at least not that quick… Very pissed off at them right now…

#19

Do you make use of this practice to make sure Prerender waits for your page to fully render before taking the snapshot. https://docs.prerender.io/article/11-best-practices

It looks that Prerender has the right content curl -A Googlebot https://www.whisky-hamster.com/, at least now. Not sure whether this was the case at the time Google passed by with the last indexing.

2 Likes
#20

Seems very random, some are properly prerendered, some not… and then google crawls this big mess.

I didn’t have the prerenderReady, just added it now, hopefully this will make the process less erroneous. Though before December everything worked perfectly without it and did not changed anything… extremely frustrating. So much work lost and with Google we never know if it will come back.