I was just digging into our Google Search results earlier today and we too saw a significant traffic drop from search results to our discourse instance (discourse.julialang.org) after May 4th (about 30%). I didn’t notice until now, because discourse accounts for only about half our page views and the rest of our site saw a traffic increase from this update, so the overall effect was only slightly net-negative, but it becomes very clear when separating out discourse vs non-discourse on the same domain. It’s slowly creeping back up, but at about the same rate of growth as the rest of the site. Is there anything that could be done about the LCP issue? That seems like a good candidate for what’s being penalized by Google (and I do also see the tens of thousands of LCP complaints in our search console). Google’s metrics are reporting about 3s mobile LCP for many of our discourse pages, which seems quite high. That seems to be a universal discourse issue. E.g. if I run a report on this thread itself, I get 3.3 s for the LCP. Unfortunately, I’m not a web developer, so I don’t have any concrete suggestions, but hopefully somebody who knows more about this could suggest something. It would be really nice to get those 30% of traffic back 
.
Here’s our search impressions graph with weekly smoothing, split out between discourse and the rest of the domain (which I assume would have the same domain-wide trust rating). The May update is quite noticeable. Ironically, we had an unrelated traffic surge the same week for the rest of the site, but I would say the overall behavior is a noticeable drop in discourse impressions and mostly stable (ignoring the unrelated traffic surge) impressions for the rest of the site.
That’s exactly what I was complaining about for months but the admins aren’t taking it seriously @Keno
We did start experimenting with Vuejs too to serve some of our content through Nuxt to improve the discourse pre-rendering performance, and we can see this, the update has been published less than a month ago and for the last 2-3 days our impressions have doubled back to exactly what they were before May update.
Not sure if this a coincidence or not but maybe has something to do with LCP, I will keep monitoring for for couple more weeks before drawing any conclusions.
Having read this blog post, this is… suuuuper generic advice. It can basically be summarized as “have quality content”. I’m not even sure what we could specifically change in Discourse based on this blog post? 
Not sure if it’s only about content quality it seriously could be related to the high LCP time which I suppose can be fixed on ember, But I am not sure really still experimenting with other solutions to see…
I think you’re focusing a little bit too much on one metric here. You’re focusing more on it than Google does.
They published about LCP on May 28 and they said “We will provide a 6 month notice before implementing these changes.” . That notice has not even been provided today.
well as I said I don’t have proof, nor I’m I focusing on it I am still experimenting with other things and seeing a spike of impressions back to what it was starting from yesterday will keep an eye on it to see how it goes for the next few weeks
Yeah, no idea if LCP is at fault at all, but it’s the one thing that jumps out in the search console, which for us flags ~20k errors for pages with large LCP. Regardless of any SEO impact, improving LCP time seems like a worthwhile goal. Of course there is a question of how much Google’s metrics actually reflect reality, but if they do, then 5s initial load time is quite a bit and surely there’s a way to do better. Particularly for the signed-out, just coming from Google use case, it seems like serving pre-rendered pages from the CDN could be quite useful.
It’s calling out the LCP, but I think the problem would be FCP… note the identical times
The first load on Discourse is slower than subsequent loads because you’re loading the app and not just that first page, so I think it’s a (much) easier said than done situation to cut the initial load time to hit Google’s “good” level (< 1s for FCP) on mobile.
I think you people concentrate too much on the “technical” hard factors. What Google won’t tell you is that they actually also measure the “perceived” performance of websites.
Discourse has maybe potential to improve the “perceived performance,” and it should.
There are many ways to do this e.g. skeleton prerendering before the full app has been loaded.
Basically, anything that shows up before the app is fully loaded helps to improve the perceived performance. Even just rendering the header (without contents, just the correct color) and the background with the loading spinner of the page before the full app is available would help on the initial page view. Anything that builds up in stages so that the user knows… something is happening even on a slow device.
For example, for Meta something like this could/should be rendered instantly (could be done with a simple critical CSS) before the full app is available to the browser:
There are hundreds of articles to improve the perceived performance of single web apps. Maybe something to look into for the @team?
A “loading” page can be done in a theme component, if you wish, maybe give it a shot and report back if it makes any difference to your site?
I don’t think the desired result is possible with a simple theme component. For this, I need to have a critical inline CSS block in the header, that is placed before any other scripts and CSS meta tags. Also, the <body> is only rendered once the full app is loaded. I don’t see how a theme component can be used to archive the desired results e.g. have a critical CSS block in the header, and at least some <div> rendered in the body before the app is fully loaded.
There is this, which does add a loader slightly earlier…
Do you have a source on the perceived performance impacting search ranking or do you mean FCP/LCP? FCP/LCP do get specific and have technical requirements despite being perception based concepts. Also note that FCP isn’t part of Google’s “core web vitals” (but LCP is).
Some more details from https://web.dev/lcp/:
As currently specified in the Largest Contentful Paint API, the types of elements considered for Largest Contentful Paint are:
<img>elements<image>elements inside an<svg>element<video>elements (the poster image is used)- An element with a background image loaded via the
url()function (as opposed to a CSS gradient)- Block-level elements containing text nodes or other inline-level text elements children.
If a page removes an element from the DOM, that element will no longer be considered. Similarly, if an element’s associated image resource changes (e.g. changing
img.srcvia JavaScript), then that element will stop being considered until the new image loads.
These requirements make it a little difficult, maybe a loading element with a large image/text could work if instead of removing it from the DOM you hide it some other way? The spinner above uses z-index to hide itself, so maybe that could work… but the spinner itself isn’t enough because it isn’t an image or text (it’s CSS).
Agree that some sort of loader would be good for users on slow connections, but there are specific hoops to jump through for Google (and we don’t know if it would solve the issue covered by OP).
Would require a bottom-up rewrite of Discourse, so I wouldn’t hold your breath for this.
I looked at this component, but I don’t think it does make a big difference as it loads way too late i.e. when most of the app is booted already. Google does not disclose what exactly they take into account and whatnot. Besides content, subjective UX is surely something they measure, even if indirect e.g. bounce back to their search engine. Long (perceived) loading = higher bounce rate on the first hit. Besides, even if this is not 200% SEO relevant according to what Google officially states, it’s still relevant from a UX and traffic perspective. Because a user will bounce if the perceived performance on first page load is not good enough.
I fully understand this. And I have to admit I don’t fully understand the render process of the app, yet.
Really if you want to win on this metric, go to a static pre-generated site, like the whole Google Amp thing.
Because you will always lose to sites that have static pages.
Talking to me? Noooo, I’m super happy with Discourse 
And good UX is not all about the first page load, maybe you lose some on first load, but once the app is loaded users certainly stick around longer and return more often, compared to boring static pages. And I’m sure Google somehow takes this into account as well.
Besides, since we switched to Discourse, none of the users complained about speed. And our search traffic is going up compared to our super optimized Drupal page with lightspeed first page hit time via full HTML caching via Fastly and critical CSS.
@codinghorror So guys I did few testing with two domains I have,
Both were affected by the May 4th update:
1st case study: Focusing entirely on content quality (as many above were suggesting)
On the first one I focused on improving content, keywords, removing any bad links, interlinking, adding new good content with lots of potential…etc…etc
As you can see above, all the effort went wasted, even though the new articles were indexed well, the thin content was removed and older articles were improved you can barely see any improvement at all, it’s just like google is indexing the website good enough to receive a little traffic but not that much traffic!
2nd case study: Moving to Vue+Nuxt (improving the structure a little bit + LCP and rendering speed)
And on the second website I only moved some of the pages into our own custom Vue+Nuxt app that serves same content with slight to no structure changes through the API, there were no other efforts to improve (even tho in this case actually moving community to community. something .com and serving the content on the main website would hurt more than benefit which it did for a slight period of time).
I am not sure what you can conclude from the above, I will keep testing and see though certainly that sudden spike is interesting, and by the way I did check before/after May and after that recent spike and I did notice in all those cases that many articles lost the impressions and suddenly almost those exact articles gained back the same amount of impressions, so it’s not one/two articles/pages that were affected but something that makes google penalise the whole website and then left the penalty on the whole website regardless of the efforts put into content quality.
I hope the above makes sense feel free to let me know if got any questions,
cheers!
If I’m not mistaken, Discourse tries to serve up a static version of its pages to crawlers, correct? Would it be possible to serve up this static version to all non-logged-in users? These LCP penalties suggest Google is seeing the non-static version of our forum.
We’ve been digging in to this off and on for months now, including hiring external consultants, and it all keeps coming back to our forum being heavily penalized by Google for LCP violations after the May 4th update.