- 1) Setup
- 2) Outside my controls:
- 3) Tools I use when testing
- 4) Different loading Attributes:
- 5) Comparison with all the loading attributes:
- 6) Should I preload hero images? (Dilemma)
- 7) Ways to get the Screen resolution
- 8) What else can we do with these data?
- 9) Debug Largest Contentful Paint Elements with Web Vitals JS:
- 10) Plugins Recommendation:
- 11) Conclusion:
- 12) Recommendation
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 for more details.
The question usually comes to our mind:
- Whether to preload the hero image or featured 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 web-vitals JS libraries and provide 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 & testing, preloading critical resources like web fonts, and above-the-fold images improves LCP and it can reduce Cumulative Layout Shift (CLS) metrics too and you can see the result in the conclusion.
Setup
- loading=”lazy“
- loading=”eager” and
- loading=”eager” with rel=”preload“
- Creative Agency Landing page template with Elementor without any optimization (With Cloudflare as CDN and Cloudinary as image CDN).
- Fast 3G connection for testing for details views from Firebase Performance Monitoring services
Outside my controls:
- There are lots of rendering Blocking resources.
- Inconsistency in Time for First Byte (TTFB).
- The page is tested in fast 3G, which means there is 100 to 500ms latency & the larger the file sizes the more time to parse and download the resources.
Tools I use when testing
Chrome Dev tools
WebPageTest
With a fast 3G connection without cache.
Different loading Attributes:
Loading=”lazy”:
By default, WordPress will lazyload above-the-fold images by implementing the native lazyloading or Browser Level Lazyloading technique.Filmstrip
Loading=”eager”:
You can see the waterfall chart, my featured image is loading at 29 marks in WebPageTest results which is far better than the loading=”lazy” attribute counterpart and we can see images are loading much earlier even though there are lots of problems with being considered.Filmstrip
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 be due to Cloudinary & Cloudflare response time.Loading=”eager” with rel=”preload”:
After implementing the loading=”eager” attribute with rel=”preload” hints, the hero image/featured image is loading much quicker and is visible to the users.Filmstrip-
Comparison with all the loading attributes:
- 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 is the comparison in webpagetest, if you want to see it 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 visitor’s screen size.
Ways to get the 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 to 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 it) 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 Dev tools or use LT Browser 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 and sending the debug_target in Google Analytics Events data. And figure out whether it is a good idea to preload a hero image or not.
- In Advanced testing, you can use the webpagetest – Desktop Browser Dimensions feature (see the screenshot below).
One of the ways I used to identify or debug the Largest Contentful Paint(LCP) is by implementing Web Vitals JS libraries and analyzing the data with the help of Data Studio and Web Vitals report.
Example use – Remove unused CSS article and creative Landing Page Template.
Debug Largest Contentful Paint Elements with Web Vitals JS:
I use Web-vitals JS libraries and send the debug_target (CSS selector) / debug_identifiers events to GA4 and then send it to Data Studio to visualize the data.
If you inspect elements on my post and search it with the ‘selector’ below, it will refer to my hero image and title tag.
div.elementor-widget-container>div.post–wrapper>img.feature-image.skip-lazy.wp-image-5405
The first selector refers to my Feature image because it is the largest element on the page.
Debug identifier is referring to me as an H1 tag.
div.elementor-widget-container>div.post–wrapper>h1.post–title
2nd CSS selectors refer to my (H1) Heading tag because H1 to H6 are block-level elements and it is visible in the initial viewport of the post.
Plugins Recommendation:
From my understanding, not all people are tech-savvy like me who love digging around, and sometimes it is not possible to what I did on my landing page or blog post, so it means your best way is to implement it with the help of 3rd parties plugins that will automatically preload critical resources (like CSS, fonts, etc):
- Swift Performance Pro (Affiliate Link): See Version 2.3 (beta) ([NEW] Preload Images) to learn more (if you have a screenshot referring to preloading, please send it to me)
- Automatically Preload “Featured image“ with PHP: Only works with feature images (Attachment below), not with any images visible in the initial viewport or above the fold.
add_action('wp_head', 'preload_featured_image', 1);
function preload_featured_image(){
if ( has_post_thumbnail() ){
$id = get_post_thumbnail_id();
$src = wp_get_attachment_image_src( $id, 'large' );
$srcset = wp_get_attachment_image_srcset( $id, 'large' );
$sizes = wp_get_attachment_image_sizes( $id, 'large' );
echo '<link rel="preload" as="image" href="'.$src[0].'" imagesrcset="'.$srcset.'" imagesizes="'.$sizes.'"/>';
}
}
- Autoptimize: It doesn’t preload all the featured image, right now you have to manually preload the image.
Conclusion:
I have over 4K users that use 1920×1080 screen resolutions accordingly to Google Analytics that are a huge user base.- Bots can inflate my data.
- Adblocker like uBlock Origin blocks all any tracking so it means data will not send by the browsers to GA Servers.
- Some people preferred disabling JS entirely.
Recommendation
The best way to figure out the largest Contentful paint (LCP) elements is by monitoring and gathering real user data with the help of web-vitals JS libraries or any RUM solution and deciding properly. Because Preloading and Pre-connect can become a double-edged sword if you didn’t do it properly.- Thank you Gijo Varghese for reviewing my post and providing me FlyingPress image.
- Thank you Nicola Caldognetto for sharing the PHP code on the WP Speedmatters’s Facebook Group.
