Table of Contents
Whenever I run a Page Speed Insights (PSI) test on my post or page, PSI captures my hero image as the Largest Contentful paint (LCP) element. (See the screenshot below).
What is Largest Contentful paint (LCP)?
The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.
Follow Web.dev article on Largest Contentful Paint in more details.
The question usually comes to our mind:
- Whether to preload hero image or feature image?
- Is it worth preloading or not?
Today in this blog post, I’m going to answer your question with real data or Field data using Google Analytics and web-vitals JS libraries and give you 3rd parties plugin recommendations.
From the field data, webpagetest result, and web-vitals JS data, you can decide whether it is the best decision to preload the hero image or not.
From my research, preloading critical resources like web fonts, images that are above-the-fold improves LCP and you can see the result in the conclusion.
Setup
This is a test between-
- loading=”lazy“
- loading=”eager” and
- loading=”eager” with rel=”preload“
In this example, I took the Creative Agency landing page template I created with Elementor with no Optimization other than Cloudflare and Cloudinary for image optimization (Referral Link).
I use Fast 3G for my testing because I usually test it in extreme cases because I can’t expect everyone will be using 4G connection when they visit my website. See the screenshot below in last 30 days.
Environments:
Things you need to considered before complaining are-
- There are lots of rendering Blocking resources
- Inconsistency in CDN cache hit ratio.
- Because the page is tested in fast 3G, it means there are 100 to 500ms latency it means larger the file sizes it will take more time to parse and download the resources.
Chrome Dev tools
With fast 3G connection without cache.
WebPageTest
With fast 3G connection without cache.
Different loading Attribute:
Loading=”lazy”:
By default, WordPress will lazyload above-the-fold images too by implementing the native lazy loading technique.
The featured image is loading at a 5.72sec mark in Chrome Dev tools Network panels.
Waterfall chart
You can see the waterfall chart, my featured image is loading at 36 marks in WebPageTest results and when the image is fully loaded LCP is also trigger. See the screenshot below
Loading=”eager” attribute:
You can see the waterfall chart, my featured image is loading at 29 marks in WebPageTest results which is far better than loading=”lazy” attribute counterpart and we can see image are loading much earlier even though there are lots of problems to be consider.
The featured image is loading at a 4.22sec mark in Chrome Dev tools Network panels.
Waterfall chart
The featured image is loading at 29 marks in WebPageTest results which is much better than the previous one but can be improved further with the help of rel=”preload”
Now we can see the inconsistency in LCP measurement because it can due to CDN cache hit ratio, 3rd parties domain response time ( cloudinary, unpack) and Cloudflare response time.
Loading=”eager” with rel=”preload”:
After implementing loading=”eager” attribute with rel=”preload”, the hero image/featured image is loading much quicker and visible to the users and it improve LCP.
We can see a huge improvement from 5.72sec to 2.26sec.
Waterfall chart
After setting the loading=”eager” attribute and preloading, my featured image is loading at 8 marks in WebPageTest results which is far better than loading=”lazy” and “eager”
Comparison:
- First Screenshot: with loading=”lazy” attribute.
- Second screenshot: with Loading=”eager” attribute
- Third screenshot: With loading=”eager” + rel=”preload”
As you can see from the above comparison, there are benefits of preloading the hero image.
Here the comparison in webpagetest, if you want to see for yourselves. But the question is still there.
Should I preload hero images? (Dilemma)
Thank you to Phil Walton and Barry Pollard for their incredible tutorials on the web.dev in debugging web vitals in the field and the smashing magazine respectively, their tutorials help me debug the problems and give me insights on what to do.
To answer the question, Yes, it depends on your/mine visitor’s “Screen Resolution”.
Ways to get the Screen resolution
I assumed most webmasters/ website owners already implemented Google Analytics or any analytics on their websites and collected tons of user data.
Universal Analytics (UA) users:
If you’re a UA user, you need to click the ‘Audience tab’ this will open the drop-down menu and you need to click ‘Technology’ and choose ‘Browser OS’.
Follow the steps
- Audience
- Technology
- Select the date and choose Screen resolution:
Google Analytics 4 (GA4)
To get your visitor’s screen resolution, head over to the ‘User’ tab then click the ‘Tech’ and click the Overview to view what browsers, OS, Device category your visitors are using, etc.
Follow the steps
- Tech
- Overview
- Select the date and set it to last 28 days or 30 days or more, this way you will see more data
- Screen Resolution
Scroll down you will see ‘Screen resolution’ and click the ‘view screen resolution’ button.
I used GA 4 for 2 days and discontinued it because GA4 has fewer features (when I was using) compared to Universal analytics and if I use Google Tag Manager JS to deploy Google Analytics, it will add more weight to my website.
What else can we do with these data?
- You can simulate Screen resolution or screen size on your Chrome Dev tools and see if your hero image is in the viewport or not.
- You can also simulate and test your site in Browserstack or Lambda (Affiliate Link), etc and do the same thing.
- Using Web-Vitals JS libraries.
- You can use the webpagetest – Desktop Browser Dimensions feature (see the screenshot below) in Advanced testings.
One of the ways I used to identify or debug Largest Contentful Paint(LCP) is by implementing Web Vitals JS libraries and we can analyze the data with the help of Web Vitals Report.
I will take remove unused CSS manually article as an example to demonstrate because I barely don’t have enough data to show you from the above example.
If you inspect elements on my post and search it with the ‘selector’ below, it will refer to my hero image. ( Please watch the video, if you don’t know)
div.elementor-widget-container>div.post–wrapper>picture>div.image-zoom-wrapper>img.image-zoom
(Above debug identifiers (CSS selectors) is referring to my hero image and % of page hits on the elements is 31.67% (screenshot below) which is high, so it means loading=”eager” with preloading is a great idea to implement).
div.elementor-widget-container>div.post–wrapper>h1.post–title
Debug identifier is referring to me as an H1 tag.
2nd CSS selectors are referring to my (H1) Heading tag because H1 to H6 are block-level elements.
But I still don’t understand why my code block (screenshot below) that is way below the fold is considering LCP.
div.elementor-widget-container>pre.wp-block-code>code
If you know why my code block is referring to LCP, please let me know and I need to learn.
From my understanding, not all people are tech-savvy like me, and sometimes it is not possible what I did on my landing page or blog post, so it means your best way is to implement is recommending you 3rd parties plugins that will identify critical resources (like CSS, fonts, etc) and preload your critical resources automatically:
- Swift Performance Pro: See the Version 2.3 beta to learn more (if you have a screenshot referring to preloading, please send it to me)
- Elementor Pro – custom Code (affiliate link). (not the best method but doable)
- WP Rocket (Affiliate link): WP Rocket does preload stylesheets, Fonts automatically but not the featured image yet.
- Automatically Preload “Featured image“ with PHP: This PHP code below only works with feature images not with a site logo or any images that are in the viewport or in above the fold.
add_action('wp_head', 'preload_featured_image', 0);
function preload_featured_image(){
if ( has_post_thumbnail() ){
$id = get_post_thumbnail_id();
$src = wp_get_attachment_image_src( $id, 'full' );
$srcset = wp_get_attachment_image_srcset( $id, 'full' );
$sizes = wp_get_attachment_image_sizes( $id, 'full' );
echo '<link rel="preload" as="image" href="'.$src[0].'" imagesrcset="'.$srcset.'" imagesizes="'.$sizes.'"/>';
}
}
Conclusion:
I have over 4K users that use 1920×1080 screen resolutions accordingly to Google Analytics that are really huge user base.
So I decided to test my removed unused CSS article in webpagetest with the different screen resolutions and turn out my feature or hero image in 1920×1080 screen resolution is my Largest Contentful Paint.
So I took the decision and my Best solution is to preload the feature image.
You can see the full comparison in full detail I have tested on the webpagetest. I hope it helps you too
if you love this kind of post and gave you insights on whether to preload or not preload feature images.
Don’t forget to support me by buying a cup of coffee or use my Affiliate link presents in the post. (This commission comes at no additional cost to you but it will keep the website a little help and write more comprehensive articles just for you)
- Thank you Gijo Varghese for reviewing my post and providing me FlyingPress image.
- Thank you Nicola Caldognetto for sharing the PHP code.
Thank you for reading till this end. Stay safe 🙂
