Why is the FID of my website so ligh?

I have two websites hosted on cloudflare. One is using paid service. Another is using free service. The two websites use the same theme but Google Search console warns FID problem for almost all pages of the 1st one. All web pages of the 2nd one are moderate in terms of FID.

In fact, I have done tons of optimization for the 1st website. There’s almost no extra javascript file except script for lazyload, and CF rocketloader plus two adsense units. This can be verified by pingdom. But pagespeed gives different results. Can you take look at and give any insights?

The 1st website - pagespeed
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.cuded.com%2F2016%2F02%2F55-incredible-cover-up-tattoos-before-and-after%2F&tab=mobile&hl=en

The 1st website - pingdom

The 2nd website - pagespeed
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fnenuno.co.uk%2Fdiy%2Fchristmas-home-decoration-ideas%2F&hl=en

The 2nd website - pingdom

Your suggestions are appreciated!

I’m not sure what FID is, but page tests indicate all the third party resources (Mostly Google services) are weighing your site down.

Yes, if I remove adsense scripts, the speed score would be 100%. But here two sites are using the same number of adsense units. The impact should be the same. And the second site has one image above fold. It should make FID slower. But there’s no warning for this site.

FID - first input delay, means time taken for users to react to the webpage after all scripts are loaded. In Search Console, Google use this metric along with FCP to measure speed performance.

1 Like

FID = first input delay https://almanac.httparchive.org/en/2019/performance#first-input-delay

This metric represents the time from a user’s first interaction with a page’s UI until the time the browser’s main thread is ready to process the event. Note that this doesn’t include the time applications spend actually handling the input. At worst, slow FID results in a page that appears unresponsive and a frustrating user experience.

If you read the Web Almanac 2019 report https://almanac.httparchive.org/en/2019/performance#first-input-delay, you’ll see that like FCP - first contentful paint, FID is dependent on browser/device cpu speed, geographic location of visitors and speed of visitor’s ISP connection. Hence, the difference you see in Google PageSpeed Insights field and origin metrics for mobile vs desktop results. As mobile is tested on Nexus 4 mobile device with 3G mobile speed profile emulation for the lab data test portion.

So you could have 2 sites with same theme with different FID and FCP results due to the 2 sites having different visitor traffic profiles for geographic location, browser/device used and ISP connection speed.

Google Webmaster Console’s Speed report is based on Chrome User Experience data (CRuX) which is real world Chrome visitor data for your sites’ pages - what Google calls field data as opposed to lab data of which both field and lab data make up the components of Google PageSpeed Insights v5 https://developers.google.com/speed/pagespeed/insights/ results.

As the CRuX data is real world, then both your sites have possibility of differing visitor profiles for geographic location, browser/device used and ISP connection speed. You can use your Google Analytics data to drill down into your visitor’s profiles for browser used = Chrome, avg page load speed vs avg dom interactive vs device type mobile/tablet vs desktop and then filter on geographic location i.e. country pin point where your site’s traffic is coming from and their respective speed and browser profiles.

This will help you determine where your FCP/FID metrics are being majorly influenced i.e. if site A has 90% mobile visitors with avg slow mobile device type from say further geographic country from your site origin, then that would have a slower FCP/FID metric than say site B which has 50/50 mobile vs desktop visitors where mobile visitors are on high end flag ship mobile devices with more powerful cpus and on LTE/5G connections and visiting from countries close to your site origin. Such differences will then show up in your Google Webmaster Tool’s Speed reported FIP/FCP metrics.

Note Google PageSpeed Insights v6 will be coming soon which FCP getting a higher weighting and also adding a Total Blocking Time (TBT) and Largest Contentful Paint (LCF) metric Performance Tutorials - Google PageSpeed & Webpagetest.org

2 Likes

@eva2000
Thanks for your reply and resource link.

I understand Google Search Console is based on the data of real world. PageInsight test is considered as Lab testing data. When a site has been optimized to have reduced the average page load time from over 20 seconds to 1 - 2 seconds, it remains mystery to see FID is still ultra slow.

I can believe the problem is not because of the devices of visitors. In GA, even the slowest page marked by GA in Page Timings (check from Behavior ->Site Speed ->Page Timings) was caused by individual device from certain city). Most visitors are using modern devices with fare fast network.

In the link provided by you,

The ECT results above seem to suggest that there is a correlation between connection speed and FID performance. As users’ effective connection speed decreases, the percent of websites on which they experience fast FID also decreases:

This is also my hypothesis. But the connection speed what I understand is based on network, CDN, Server and website design. If you look at the testing result of pageinsight, I would expect the page should finish drawing in the first 1 or 2 screenshots. So the current connection speed is not so nice. In this perspective, FCP also has impact on FID. For example, all of my pages used to have image above fold. But now you can check I started to move them below. So the page doesn’t have to load the page when first loading because lazy load. This action is normally interpreted to reduce FCP. But it also helps to reduce FID.

.

It’s part your adsense code too one slower of your 2 sites Google Adsense/doubleclick’s main thread blocking time is 2x times that of faster one of your sites which would also be affected by client device.

Also remember for Google Webmaster Console Speed reported FID it’s based on a 95% percentile value not averages or median metrics https://support.google.com/webmasters/answer/9205520?ref_topic=7440006#about_data. So what is reported is aggregated FID for 95% of visitors.

Agg FID (aggregated FID) shown in the report is the lowest common FID for 95% of the visits to a URL in the group.

That would generally report higher numbers with 95% percentile than it would if averages or median was used.

I ran webpagetest.org for both your site urls over nexus 5 3g fast speed profile for chrome and can clearly see on one site page interactive time is delayed much further when compared https://www.webpagetest.org/video/compare.php?tests=200201_KR_cddbfeb61fb9a6acd69b8b5d8c08b3e5,200201_SR_14deb10e2bb6a6493818158d1072cbb7 you can use waterfall slider to switch between both results

individual tests

on slow page interactive site

on faster page interactive site

PageSpeed Insights, WebPage Test and Lighthouse are all Google based and run from the Lighthouse API. (That’s the engine underneath.)

PageSpeed Insights does show lab data - but with enough views it shows real-world user metrics or RUM data. Just like yours does now - it’s the traffic light colours: green, orange, red.

Your website loaded instantly for me on desktop, but obviously mobile is your main goal.

It seems like you’ve got a lot of JavaScript, which is what is probably affecting your FID times.

What I’d do is forget all the preconnects, because they will most likely be loading individual resoureces quicker, but overall they will be quite intensive - 6 or 7 preconnects.

Instead, self-host your font files. Subset them using https://transfonter.org/ to get the size down even more. Then preload them site wide or on a page-by-page basis if you don’t use them on every page.

Obviously fonts are important so you don’t get any FOUT or FOIT, etc.

Then Rocket Loader will do its thing better without all the preconnects, but obviously it’s all about testing and more testing.

Ideally you want your above the fold javascript loading early, then the less important stuff later on.

Good luck!

@davidelstob73

Thanks for your reply.

I tested by removing the preconnect.You can see the speed will be dramatically slower.
Test on FF browser
https://www.webpagetest.org/result/200201_RJ_b64e8d665e7e0d10e0a16f286ea56601/1/details/#waterfall_view_step1
Test on Chrome broswer
https://www.webpagetest.org/result/200201_RJ_59326666f13d39bda902832e8cd38ee6/1/details/#waterfall_view_step1

When I added the preconnects back to the header, obtained the similar result as @eva2000 tested

https://www.webpagetest.org/result/200201_RJ_59326666f13d39bda902832e8cd38ee6/1/details/#waterfall_view_step1
Here is the preconnect codes. Actually, there’re only 3 preconnects. Others are dns-prefetch as backup, which is less resource intensive.

<link rel="dns-prefetch" href="https://pagead2.googlesyndication.com">
<link rel="preconnect" href="https://pagead2.googlesyndication.com">
<link rel="preconnect" href="https://www.google-analytics.com" >
<link rel="dns-prefetch" href="https://adservice.google.com">
<link rel="preconnect" href="https://adservice.google.com">
<link rel="dns-prefetch" href="//www.google.com">
<link rel="dns-prefetch" href="https://stats.g.doubleclick.net">
<link rel="dns-prefetch" href="https://tpc.googlesyndication.com">
<link rel="dns-prefetch" href="https://googleads.g.doubleclick.net">
<link rel="dns-prefetch" href="https://www.googletagservices.com">

I do need preload the font. But this problem happened before I set font preload.

Obviously you know your website better than me, but the prefetch and preconnect (I wasn’t really differentiating between them) are connecting things like adverts after the document is complete. So they aren’t super critical.

I’d priorotise your fist 8 or so items before doc complete - the blue line.

Also if you set your Cloudflare page rules to cache everything - you can easily get TTFB down to > 200 ms, even on shared hosting.

Don’t want to be a self-promoter, but I’ve got an article showing how to do it. Even if you skim it and get the bits you need. I’m sure you’d find it helpful.

I’m presuming you’re on WordPress?

Are you running Autoptimize or Fast Velocity Minify? You really need one of them with W3 Total Cache or equivalent.

I’m on Hostinger and they use LiteSpeed Web Server, so thought I’d try LiteSpeed Cache out, as it pairs up well with the LiteSpeed back end. Was really pleased with the result, as it does Critical CSS on every page, not just first page. It does the job of 4 or 5 other plugins so it’s a good option to slim one’s plugin footprint.

You might want to give that a try. I’ve done a review on that also, but there are plenty of good tutorials out there on W3 Total Cache, as you are no doubt aware.

@davidelstob73 Nice to see another fellow pagespeed addict on the forums - though I guess all Cloudflare customers would be too :slight_smile: Nice guide and even nicer page speed for your pagespeedtweaks.com site - see you’re using Workbox based service worker too :slight_smile: Curious, if you’re using Litespeed web server, you might as well use Litespeed’s Wordpress cache plugin instead of W3 Total Cache ? StackPath CDN can get expensive, one of my clients traffic would cost US$5,000+ per month on StackPath CDN versus Cloudflare Business Plan at US$200/month !

For my Wordpress blog at https://servermanager.guide/, I use my own developed Centmin Mod LEMP stack with Nginx with PHP-FPM with Wordpress Profile Guided Optimization training and use autoptimize plugin + my autoptimize gzip companion plugin (serve precompress css/js files) along with PHP-FPM fastcgi_cache guest full HTML page caching + Cloudflare free plan outlined at https://servermanager.guide/122/how-to-install-wordpress-on-centmin-mod-lemp-stack-guide/ along with some Cloudflare worker caching.

Optimally deployed preconnect and dns prefetch hints will always be beneficial for page speed which you have experienced from your own webpagetest.org tests. So if they result in better page speed, keep them in play :slight_smile:

The other thing you can do to rule out ads related javascript as a problem and variance is test webpagetest.org and use advance scripting outlined at https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/scripting#TOC-block to block individual 3rd party requests and/or domains in your webpagetest.org tests so you can look at respective site’s frontend and backend (web server, php, mysql) factors that come into play.

1 Like

Hi again and thanks for the kind words.

Where do I start, lol?

  1. Service workers - yeah I have been experimenting with them for a while, the AMP ones are super easy as it’s only one line of code, then AMP take over the implementation.
  2. Workbox seem more tempremental, but service workers do seem finicky in general. Even one’s set up by Googlers, etc. Anyhow, instead of caching different sections I saw a snippet to cache everything and then it was pulling in the 4 x workbox scripts. However, I got downgraded on my WebPageTest caching for not using a CDN, even though it was all on workbox.cdn. So I decided to self-host the workbox scripts and lump them into one file for a few quick wins. Realistically, hardly anyone is going to install it so it’s just me ticking boxes for the PWA result on Lighthouse.
  3. Someone commented, my only comment up to now, haha! And the guy mentioned LiteSpeed cache, which is why I decided to review it because it’s growing in stature and everyone’s hammered W3 for tutorials. It really surprised me how good it was. I’m planning on doing more testing then probably moving over from W3, however, the speed isn’t much different and I like W3 for the security headers. The thing is though you can copy the security header code from W3TC that it places in .htaccess and reuse it on other plugins. Suppose we’ve all got our own tricks that we might or migth not use!
  4. I’m only on Hostinger Shared Hosting, as my blogs are all quiet, but this is the first new site I’ve put a lot of effort in so hoping to get some traffic next year. Only on $10 a month Stackpath, nowhere near your friend’s level. :slight_smile:
  5. Planning on upgrading to CentOS and VPN next, is it quite easy to use?
  6. Need to grab some dinner, but if you want to hit me up sometime on my email - [email protected] sometime we can perhaps swap some ideas when you get chance. You can perhaps point me in the right direction with CentOS. Never used it before, just messed about with Kali Linux and Fedora a few years ago pretending to be the next big hacker. :slight_smile:

Nice chatting!

I only use CentOS for my Centmin Mod LEMP stack so it’s all I know and I created a web performance subforum for my Centmin Mod users at https://community.centminmod.com/forums/web-development-web-performance.60/ some of the discussions probably right up your alley too :slight_smile: So bit biased as to whether it’s easy to use CentOS :slight_smile:

Even did some comparison pagespeed tests for my Centmin Mod Wordpress installer which can use Cache Enabler full page guest HTML cache in advanced mode (which totally bypasses PHP unlike it’s default install mode) vs OpenLitespeed + Litespeed Wordpress cache plugin https://community.centminmod.com/threads/wordpress-webpagetest-pagespeed-comparison-for-cyberpanel-1-7-rc-openlitespeed-vs-centmin-mod-lemp.15211/ though the Litespeed Wordpress cache plugin has had many improvements since I last tested.

Unfortunately, if you’re using Google Adense or 3rd party ad scripts, Google Pagespeed mobile 3G speed based FID/FCP will always be relatively lower than desktop.

1 Like