First Contentful Paint (FCP) taking 3.5s

Since 10th March the First Conentful Paint (FCP) on my site is almost 4 seconds on a mobile, 3s on a desktop. This pushes out the LCP (Largest Contentful Paint), triggering Google to tell me there are errors with the Core Web Vitals.

I have just, in the last 10 mins, disabled Rocket Loader (reading somewhere else this has caused other problems for some users recently).

As a more general point, is there anything on the Cloudflare side which could make the FCP so slow? My site performed quite well up to 10 March and nothing changed on my side. The theme developers suggested it could be an issue with Cloudflare, so checking here first.

What is your domain name?

Mostly helps for my Websites for FCP due to the usage of jQuery and other scripts.

Do you use some cache or have setup the cache at Cloudflare dashboard?

What does the Google Lighthouse or Google Page Speed tool say or recommend to you to do?

Maybe @eva2000 guides can help you with that:

Domain is https://tarsolutions.co.uk

Caching is set up in Cloudflare. Plus I use the “WP Cloudflare Super Page Cache” plugin.

Google Speed Insights doesn’t suggest much to be honest. I removed a newsletter subscription form (although it didn’t cause any problems for the past months) and removed some Google Fonts. Nothing else I can disable really - all that’s remaining is Autoptimize, which I did disable, but that slowed things down.

This plugin is not an official WordPress plugin from Cloudflare.

Moreover, “Page Cache” - seems to me, it re-generates from time to time due to some content changes and update, so maybe when you tested your URL with the PageSpeed Tool and made some changes in between, you could get the “non-cached” version of your URL for your webpage.

Moreover, PageSpeed can have some cached results also from my experience.

I tested at my Web browser at desktop PC and mobile, the speed is awesome - no worry:

1 Like

Thanks for testing. My primary concern is Google bumps me down the ranks because of performance - ultimately what Google thinks is the most important thing. Is there anything, on top of the caching, that can improve the timings?

Like I said, it’s only in the past week the FCP takes a long time (according to Google) and nothing has happened in that time on the website that could make performance worse. The only change was removing the newsletter signup to see if that made a difference - but it hasn’t.

Have you got some proof, yet if this is true?

I am sorry but I have to say I really do not believe so much it that.

I really do not know what we are talking about here, everything is green and good :slight_smile:

Either Google PageSpeed Tool has something outdated or cached due to some other reasons, but Lighthouse itself updated to the latest version says different. See here.

Desktop test:

Mobile test:

The thing you may not notice or wrongly interpreted to yourself this one:

Origin Summary During last 28-day …

Does not pass, but the recet and current testing - is all green :wink:

1 Like

Yes, it’s green - actually gives a score of 100 for some pages - but would still be an error in Google Search Console. See the FCP and LCP are both slow and have red triangles against them?

I’m no expert in what Google are reporting or how they get their numbers. They say it’s a 28 day thing; then also say they don’t have enough real-world data…so which is it? :slight_smile:

Anyway, this is what GSC tells me. Just I have no idea of the cause or how to fix it.

Well, that’s Google :smiley:

Due to GCS, it changes from day to day, at least for my Websites and I do not worry that much for now knowing the domains are behind Cloudflare and all the needed things are setup as much as it can bue - due to some Websites like news portals which have advertisments and external resources, which “cough” the loading speed.

But this one site from below screenshots, has AMP and Ads, cache, Cloudflare Pro, etc.
Loads really fast to the end user and stands really good for search results, it’s just … :smirk: kind of a “poke”, which Google does not like obviously or has to report it to the Webmaster.

Moreover, I do not believe I can do something about it :smiley:

See here:

2 Likes

Well if you improved your page, then you normaly have to wait for another 28days … so the “real-world data” which are an averagte of the last 28 days are adjusting to your improvement.

Thats why if you in Google Console trigger a “I have resolved that problem” function, it tells you to wait 28 days…

But over all you just do still have a very big overhead in your site. Just way to much info and data are getting loaded for achiving a better ranking.

Thats why you can test your site and do get a good result on syntetic benchmarks but not on real-world experiences. People do have different devices, different OS different software, different Networkproviders and different Browsers

But anyhow this is not a CloudFlare Problem. As CloudFlare did properly cache and deliver your site at its best. Its the site, the template, the Theme (GeneratePress I think) and WordPress that does not let you optimize your site any further.

In total, there is still a lot of room for improvements like:

  1. remove infos/scripts/files/things you do not need (mostly not easy possible with WordPress Theme)
  2. combine as many files into one single file as possible (just one CSS, one JS)
  3. use the most modern and scalable format for graphics (Logo etc should be SVG, if possible)
  4. use SVG always inline and not in CSS as Background or anything else which will increase the critical path
  5. use responsive images (overloaded Picture tags)
  6. add WEBP and use JPG/PNG as fallback for older devices
  7. do not use external ressources if not really needed (Google Fonts etc)
  8. host all CSS on your own domain and also its ressources (Fonts “woff2”)
  9. preload fonts which are critical
  10. also preload critical CSS and images if really needed
  11. use HTTP2/Push is possible to push (CSS files only!) to the client in one request if not already loaded and make them apply inline
  12. defer JavaScript and trigger the load of it by “PageLoad” event or at user interactions

Most important:

  1. do not give to much about what Google thinks about your page if you really already have done EVERYTHING thats possible… there are pages which are optimized to its fullest but as they have galleries with a lot of images with etc and speciall functions which are required they will never get 100/100 in GPSI.

So first make sure you know what you want to achive and what is reallistic and then go and optimize it.
But you will very fast reallise WordPress is not the way to go for a real good site. But for a real “easy to implement” site. But these are just my 2cents.

1 Like

Thanks for your input. @fritexvz tested it in the real world and it was fast. The Speed Insights says it doesn’t have enough real world data, so I’m not too sure where this “28 day” data comes from.

The WP theme I use is super fast, plugins are at a minimum, and Speed Insights doesn’t report anything obvious as being very slow. None of the other speed checkers do either.

I spoke to the guys and they suggested checking with the host, or checking with Cloudflare in case there’s a caching problem.

The FCP seems to be the problem and there aren’t any big blocking resources to prevent this being far quicker than it is. The opportunities suggested by Speed Insights wouldn’t make a dent in the FCP.

Real-World tests are not made out of “one test” its an average of as many tests as possible.
So yes: one realworld tests was good.

Others have been bad in the last 28days in average.

This is a Google standard. So if you want your Real-World data to reflect your current site you will have to wait about 28 days without changing anything.

To explain what causes a high FCP:

We assume your page loads immediately.

Your clients/visitors are loading your site and as soon as they loaded the DOM, their device (we focus on mobile) will process the DOM and will check which files it additionally have to load to render the page.

  1. It will load the initial request (HTML, mostly small)
  2. will process all scripts/styles/links in the header
  3. Then processing the Body and render what it does have.
  • Then it starts loading all the links/ressoucres in the header. The more links/things you have there the longer untill it reaches the FCP.
  • The more different domains it have to resolve + terminating SSL of each of these the longer untill FCP is getting reached
  • the more (renderblocking) JS is in the header the more it blocks rendering and the longer untill FCP.

Renderblocking is considered as everything what is not purely based on a EventListener.

So to start small with your improvements I would advise you to:

  1. start moving external ressoures over and make them beeing served by your Domain, as all other things are way more work on WordPress.
  2. use as many things inline as possible if “above the fold
  3. use preload to prioritice your critical files which contribute to have everything above the fold loaded and therefor rendered faster.

Thats all I can say. But anyway you will have to wait 28 days to make googles “real world data” reflect your changes.

1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.