# Google May 4th Core Update impact on Discourse forums

**URL:** https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369
**Category:** Community Building
**Created:** [August 19, 2020, 12:35pm UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369 "2020-08-19T12:35:50Z")
**Posts on this page:** 1
**Showing post:** 59

<div class="post-metadata">

### Author: ![awesomerobot](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/awesomerobot/32/142900_2.png) [@awesomerobot](https://meta.discourse.org/u/awesomerobot)
#### Post date: [October 1, 2020, 9:43pm UTC](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369/59 "2020-10-01T21:43:52Z")

</div>

There is this, which does add a loader _slightly_ earlier…

> [@Found a workable CSS hack to show spinner/loader on slow initial load](https://meta.discourse.org/t/found-a-workable-css-hack-to-show-spinner-loader-on-slow-initial-load/84199):
>
> I’ve read a few posts about people wanting a spinner or loading image for the initial discourse load as it may be quite slower than subsequent loads. I realize this is a CSS hack and not a fancy or beautiful fix, but it is working well enough for my discourse needs. Update with theme component If you want to use the discourse spinner on the initial load in addition to between page loads, follow the following steps. Step 1: Add the following code to your CSS: #main {background: white;} Th…

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/:](https://web.dev/lcp/:)

> As currently specified in the [Largest Contentful Paint API](https://wicg.github.io/largest-contentful-paint/), 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()`](https://developer.mozilla.org/en-US/docs/Web/CSS/url()) function (as opposed to a [CSS gradient](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Images/Using_CSS_gradients))
> - [Block-level](https://developer.mozilla.org/en-US/docs/Web/HTML/Block-level_elements) 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.src` via 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).

---

_[View the full topic](https://meta.discourse.org/t/google-may-4th-core-update-impact-on-discourse-forums/161369)._