How to improve Largest Contentful Paint for a better page experience
How to improve Largest Contentful Paint for a better page experience
Largest Contentful Paint is a metric that measures how quickly a page’s main content loads and renders (or paints) most of its visual elements to the screen. Learn more about what a good Largest Contentful Paint score is, how to measure your website page’s Largest Contentful Paint, and how to optimize servers, networks, and more to improve your page’s Largest Contentful Paint.
Chapters
0:00 Introduction
2:30 What is Largest Contentful Paint (LCP)
4:08 How is LCP measured
4:37 What is a good LCP score
5:55 How to find your LCP score
8:49 Elements that affect LCP
9:00 Servers
9:43 Networks
11:33 Front end code
19:00 Edgecases
21:48 Conclusion
Learn more:
Largest Contentful Paint documentation at web.dev → https://goo.gle/3t85Jaa
CrUX Report → https://goo.gle/3mRQelN
Optimize LCP → https://goo.gle/3DKtFoT
Search Console signup → https://goo.gle/3DH6egu
Workbox → https://goo.gle/3zFHz9D
Learn more about optimizing your site’s caching →https://goo.gle/3BQwUcX
Phil Walton’s Cache first service worker blogpost → https://goo.gle/2WMNlry
Efficiently load third-party JavaScript → https://goo.gle/3jDgoq8
Serve images in modern formats → https://goo.gle/3kNNXFB
Watch more Getting started with Page Experience → https://goo.gle/3xgTJUu
Subscribe so you don’t miss an episode Getting started with Page Experience → https://goo.gle/SearchCentral
#CoreWebVitals #WebDev #PageExperience
product: AMP - Page Experience; fullname: Patrick Kettner; re_ty: Publish;
Content
0.58 -> [Music]
1.599 -> have you ever thought about how hard it
3.199 -> is to answer how long does it take for a
4.96 -> web page to load i i mean seriously
7.04 -> think about it it's not as easy as it
9.04 -> seems the first time i did it i
11.2 -> confidently rattled off a couple of
12.719 -> options the document.unload right well
15.36 -> that only fires when everything is done
17.84 -> i mean if an ad that's 10 trillion
20.32 -> pixels below the article i'm reading
21.92 -> took 2 seconds or 200 seconds to show an
24.4 -> image
25.439 -> why would i care
26.88 -> i don't not really
28.8 -> if that final image isn't blocking me
30.48 -> from my reading document.unload is a
32.8 -> pretty meaningless milestone as a user
35.36 -> well okay so what about uh dom content
37.76 -> loaded right well it's sooner but it's
40.879 -> too soon i mean it's just when content's
43.68 -> been downloaded uh images may not have
45.52 -> rendered style sheets may need to be lay
47.76 -> out the entire page still i mean scripts
49.68 -> could still have tons of apis that they
51.28 -> have to call before the web app even
52.719 -> gets close to being useful
54.719 -> so uh we look to more modern options
56.64 -> like first meaningful paint it's better
58.719 -> for sure but it's the first thing that
61.44 -> is painted and that's not necessarily
63.76 -> always that useful i mean if it's just a
65.439 -> spinner it doesn't really represent a
67.92 -> loaded page at least in a meaningful
70.159 -> sense
71.36 -> it's it's weird but
72.799 -> something that is as important as how
75.439 -> fast our sites are loading is
78 -> kind of complex to figure out but lucky
80.64 -> for us a lot of people feel that way and
82.88 -> with core web vitals and page experience
84.96 -> we finally have a definitive answer to
86.479 -> this question and so much more that's
88.64 -> why today we're taking a look at
90.4 -> improving our largest contentful paint
92.479 -> the issue with the older ways that we
94.32 -> use to figure out when a page is loaded
96.159 -> is that we were looking at the wrong
97.84 -> abstraction you know we were mentally
100.079 -> tying
100.96 -> vaguely related dom events to things
103.119 -> that were much more nuanced than they
105.28 -> could actually be used for that's why i
107.2 -> love page experience it's all about kind
109.2 -> of stepping back from the problems and
110.96 -> getting an answer to the questions that
112.64 -> matter the most to our users on today's
114.799 -> web i mean each of its parts is trying
117.439 -> to answer a fundamental and essential
120.32 -> question to make sure that we can get
122 -> the best user experience possible
124.56 -> with largest contentful paint or lcp we
127.6 -> answer that how fast question
130.16 -> people using our site don't care when a
131.68 -> dom event inspired they care about when
133.52 -> a page is usable or rather when they
135.599 -> think it's usable and that's what lcp
137.84 -> gives us a new browser rent to know the
139.68 -> point at which most users perceive that
141.68 -> a web page has been loaded
144.08 -> but before we can discuss improving lcp
147.599 -> let's make sure that we all understand
149.2 -> just what lcp is
151.28 -> largest contentful paint is admittedly a
153.519 -> mouthful but once we break it down to
155.2 -> what it individual parts means it is a
158.08 -> fairly straightforward idea
160 -> the paint in largest contentful paint is
162.4 -> referring to a paint event
164.48 -> this is browser terminology it's for
166.56 -> when pixels on your screen are rendered
168.64 -> or painted in every time that a pixel
171.28 -> changes the color on your screen that's
172.959 -> a pain event well
174.879 -> maybe it gets murky but we'll talk about
176.879 -> that later on for now you can just
178.48 -> remember when a pixel changes that's a
180.159 -> paint
181.28 -> just like the other web vital events
182.959 -> discussed throughout this series paint
184.959 -> events are exposed as performance
186.8 -> entries that we track and analyze
188.48 -> through the performance observer browser
190 -> api
191.68 -> every time the browser paints we know
194.08 -> about it and understand each and every
196 -> element on the page is bloated it's
199.04 -> cool i mean it's very powerful but it's
201.44 -> overwhelming i mean every paint every
203.84 -> time a pixel is updated it's a lot of
205.76 -> events which is why there's a separate
208 -> more useful largest contentful paint
210 -> event
210.959 -> a contentful paint is a paint event that
214.08 -> specifically draws the pixels of a
215.76 -> handful of dom elements
217.68 -> namely image elements the image elements
220.08 -> used within svg
221.599 -> elements with the background image video
223.68 -> elements block level elements as in
226.239 -> display block yeah those uh when they
228.799 -> contain text
230.159 -> in in short contentful paint is a paint
232.48 -> event that paints content it kind of
235.12 -> makes sense
236.239 -> so what is the largest contentful paint
238.56 -> well that's when the element that uses
240.4 -> the most amount of pixels of all the
241.92 -> elements on our user screen is painted
244.56 -> well mostly but again we'll talk about
246.72 -> the edge cases later on
248.72 -> when we measure lcp we do so in seconds
252.08 -> it's the number of seconds between the
253.92 -> very first bite that the page is loaded
255.92 -> and the final largest contentful paint
257.759 -> event as soon as our users touch tap or
261.04 -> interact with our page that window of
263.04 -> time closes lcp stops being measured
265.759 -> whatever element had the highest number
267.28 -> of seconds between the first byte and
268.96 -> when it was painted is what is reported
271.12 -> for the lcp for that url
273.68 -> like every other part of page experience
275.68 -> every page on your website has its own
277.6 -> lcp score
279.12 -> your home page may have a less than
280.96 -> stellar lcp
282.4 -> but your product or article pages could
284.4 -> have fantastic results neither page
286.639 -> impacts how the others perform on this
288.32 -> metric
289.52 -> all of these results are generated by
291.199 -> and collected from people using your
292.96 -> site so if you see that your page has an
295.12 -> lcp of one second
296.8 -> that's what your real world users are
298.24 -> seeing when they visit so we know what
300.4 -> lcp is but now you may be wondering what
303.039 -> a good or bad lcp result even looks like
305.68 -> the most important thing i think to keep
307.28 -> in mind is that lcp is just one part of
309.919 -> page experience which in turn is just
312.16 -> one of the many many inputs that search
314.8 -> has inside of its secret sauce you know
316.72 -> there isn't really a pass or fail number
319.199 -> when we're talking about these things
320.56 -> it's just a number that's used to
322.4 -> compare similar sites in order to figure
324.32 -> out which one users may have a better
326.08 -> experience with think of it like this if
328.32 -> you had two otherwise identical pages
330.16 -> that exist but one takes twice as long
332.32 -> to render and paint
334 -> which one would you rather use i mean
335.919 -> the faster one right
337.759 -> knowing all that though a good goal to
339.36 -> aim for is that your largest contentful
341.28 -> paint happens in less than 2.5 seconds
343.759 -> for at least 75 of the sessions on your
346.4 -> page
347.52 -> if that sounds complicated to calculate
349.199 -> and track then i've got good news for
350.88 -> you if you've been with us throughout
352.96 -> this series you will already know that
354.72 -> you can quickly get all of your web
356.56 -> vitals and page experience results on
358.479 -> your search console page experience
360.319 -> report
361.44 -> if you aren't already using the search
362.96 -> console you need to sign up for a free
365.039 -> account using one of the links below and
367.12 -> i highly recommend that you do so
369.6 -> the search console gives you extremely
371.919 -> valuable insights into how your web
374.08 -> pages and entire website is performing
377.44 -> once you're logged in we can check out
379.28 -> the web vital section of the page
381.12 -> experience reports and any urls that are
383.36 -> below a 2.5 second goal that we talked
385.44 -> about for lcp will be highlighted for
387.6 -> you
388.319 -> hopefully there's nothing there but if
390.16 -> your sites are anything like mine there
391.68 -> could be a few places where things can
393.36 -> be improved at least a little bit
395.919 -> once we have a specific url that we want
397.759 -> to improve we can roll up our sleeves
399.84 -> and figure out the reason behind our
401.199 -> score
402.16 -> we can open up dev tools in the browser
404.08 -> turn on core web vitals overlay load the
406.16 -> url and
408.639 -> huh
409.599 -> that's where
410.88 -> even though we're just starting we're
412.88 -> coming up to the first potential issue
414.639 -> see my lcp results that are showing here
417.199 -> are a lot faster than what's in the
418.4 -> search console
420.16 -> the only lcp score that truly matters is
422.4 -> the one in the page experience report
424.16 -> this is the exact same information that
425.68 -> search is going to get so remember this
427.919 -> value is coming from your actual users
430.319 -> so if we're seeing a discrepancy between
432.24 -> our search console report and when we
433.919 -> view the site we may need to tweak our
436.08 -> development setup a little bit to more
437.919 -> closely align with the score being
439.36 -> recorded inside of the search console
441.599 -> if you're working on a more powerful
442.8 -> development machine but your users are
444.8 -> on five-year-old phones you may have a
446.8 -> much harder time noticing the problem or
448.639 -> finding a solution
450.479 -> ideally when you're working with page
452.08 -> experience especially the web vitals
453.84 -> portion like lcp you are testing on
456.16 -> devices that are the same or at least
457.84 -> similar to what most of your users have
460.24 -> if you aren't sure what your users have
462 -> you can actually usually find this out
463.44 -> inside of your site's analytics you know
465.039 -> it doesn't have to be exact device
466.479 -> models just an understanding of what the
468.4 -> most common
469.84 -> kind of experience is for people
471.44 -> interested on that page of your site you
473.44 -> know are they using a higher lower end
475.039 -> device is it an older or newer browser
477.599 -> once their screen size you know that
479.039 -> sort of thing if you don't have similar
480.56 -> devices available chrome devtools lets
482.24 -> you set up mid-tier or low-end mobile
484 -> device emulation to get a little bit
485.68 -> closer to what your users may have
487.919 -> once we get our lcp reporting close to
490.16 -> what is actually in the report we can
492.56 -> use the performance observer api to get
494.56 -> more detailed information about this lcp
496.879 -> event like exactly which element is
499.44 -> taking that long to paint
501.12 -> by observing the largest contentful
502.72 -> paint type we can iterate over every lcp
505.12 -> entry from there we can directly check
507.28 -> out the element attribute for each and
508.72 -> every entry
509.84 -> this will give you the actual live dom
511.52 -> node that triggered this lcp event this
514.08 -> could be any of the dom types that we
515.599 -> talked about before images videos even
518.159 -> just text i mean web fonts can actually
520.08 -> frequently inflate your lcp it's
521.76 -> definitely something to look out for
523.76 -> now that we know our page's lcp score
525.6 -> and the elements that's causing it we
526.959 -> can finally dig into some solutions we
529.12 -> can pretty much reduce all lcp problems
531.36 -> down to slow servers slow network and or
534.56 -> slow code
536.08 -> whenever i troubleshoot my problem i
537.6 -> like to start from the start and go to
539.44 -> the finish so we can start with the
541.2 -> server lcp measures from the very first
543.6 -> byte that the browser receives until our
545.279 -> users interact with the page so if our
547.279 -> server is running slow or just not fully
549.44 -> optimized we are inflating our lcp
551.6 -> before we even get a chance to start
552.959 -> running our browser code we could create
555.279 -> an entire series just based off of
557.2 -> optimizing a server so i can't go into
559.12 -> too much depth here but we can share
561.279 -> some high-level guidance to get you
562.72 -> started you'll want to reduce your
564.32 -> server logic and operations to just
566.24 -> what's essential make sure that your cms
568.56 -> or whatever the back end is is caching
570.72 -> pages rather than rebuilding them on
572.24 -> every request
573.44 -> speaking of caching make sure that your
575.12 -> static files like images style sheets
577.12 -> and scripts are served with long-lived
579.2 -> caching headers this will reduce the
580.959 -> number of files your server has to send
582.48 -> out over and over again
584.24 -> once we've verified that our servers are
585.76 -> doing their best we can move on to the
587.36 -> next step the network even if our server
589.68 -> is turbocharged and our front end is the
591.68 -> height of performance if our network is
593.68 -> slow it will undermine all of that work
595.76 -> that's why it's essential to be using a
597.44 -> cdn cdns or content delivery networks
600.48 -> are services you can get to serve copies
602.56 -> of the content on your server on their
604.72 -> servers so if your server is in san
606.72 -> francisco but your user is in logos
609.2 -> rather than every file having to
610.72 -> crisscross a whole bunch of oceans and
612.079 -> continents on every single request a cdn
614.56 -> will copy those files and store them a
616.72 -> lot closer to the end user less distance
619.36 -> means less time spent on the wire so
621.2 -> files load faster bringing down our lcp
623.6 -> the most popular cdns will have data
625.36 -> centers located near the vast majority
627.519 -> of people in the world but make sure
629.68 -> that you're looking at your analytics
631.36 -> for your sites to make sure that the cdn
633.839 -> that you choose is the best for them
636.24 -> of course the fastest way to fulfill a
637.92 -> network request is to just never leave
639.68 -> the user's device so using a service
642 -> worker is a great choice to make our
643.519 -> sites load instantly if you're
645.12 -> unfamiliar service workers are special
647.519 -> javascript files that let you intercept
649.76 -> and respond to network requests directly
651.76 -> within the browser
653.279 -> philip walden an engineer on the chrome
654.88 -> team had a post on his blog recently
656.56 -> about how he lowered the lcp for pages
658.24 -> on his site by nearly 80 percent by
660.48 -> using a service worker with a cash first
662.48 -> strategy you can read more about this
664.24 -> specifically in the links below
666.32 -> well much like server optimizations
668 -> though we could create an entire series
669.68 -> based off of service workers so we can't
671.2 -> get into too much detail in this video
673.44 -> but there is a ton of great information
675.76 -> available online i really really
677.76 -> encourage you to check it out yourself
679.68 -> if you've never used them before there
681.04 -> are tools like workbox which is linked
682.56 -> in the description below it gives you a
684.16 -> fantastic starting point and pre-written
686 -> samples that you can start using today
688.48 -> so our servers are tight our networks
690.399 -> are screaming fast but our lcp still
692.56 -> isn't perfect next place to look would
694.48 -> be our own front-end code
696.56 -> we learned that lcp measures only what
698.16 -> is on the user's screen and stops being
700 -> reported once the page is interacted
701.6 -> with
702.64 -> that means that the element that
703.92 -> triggers our lcp will likely be in that
706.079 -> initial area shown at the top of your
708.24 -> page when the url is first loaded we'll
710.8 -> call that the initial viewport our job
713.68 -> is to make sure whatever is being
715.04 -> rendered in that initial viewport is
717.04 -> able to do so as fast as possible
719.76 -> the first thing we can do to accomplish
721.36 -> this is just remove stuff remove any
724.079 -> scripts and style sheets in the head of
725.76 -> our document that aren't being used on
727.44 -> this page
728.88 -> those can block or slow the browser down
730.88 -> while rendering what is actually being
732.32 -> used it's just eating into our critical
734.399 -> lcp budget taking this a step further we
737.04 -> could remove an entire network round
738.56 -> trip
739.519 -> rather than linking separate files we
741.2 -> can directly add the css and javascript
743.2 -> essential to the initial viewport right
744.959 -> inside of our head
746.48 -> this means that the browser does not
747.92 -> have to find our css download it parse
750.24 -> it and then lay out the page we can just
752.24 -> jump straight to the layout the
753.6 -> millisecond it gets there it's a great
755.44 -> way to squeeze just a little bit more
756.959 -> performance out of each and every page
759.2 -> if we still use scripts on the page
760.72 -> we're going to be looking into both
762.079 -> defer and async
764 -> these are attributes that we can add to
765.68 -> any script tag think of them as signals
768 -> we can give to the browser of different
769.68 -> ways that they can speed up its
771.2 -> rendering see a browser can only do one
773.6 -> thing at a time by default it will go
775.92 -> from the top to the bottom of our code
778 -> downloading and parsing everything
779.68 -> pretty much one line at a time
781.839 -> if we add the async attribute to our
783.44 -> script tag and we're telling the browser
785.36 -> that we are not going to be relying on
787.2 -> any other resource on the page that it
789.04 -> can download the other stuff in the
790.16 -> background it'll execute as soon as it's
792.32 -> done downloading if the script is
794.16 -> important to the site and needs to run
795.6 -> as soon as possible the async attribute
797.68 -> is a great second choice after directly
799.839 -> injecting the script into the head if
801.6 -> the script needs to be on the page but
803.44 -> can wait a little bit and i like to use
805.44 -> defer scripts that use async may
807.6 -> interrupt the browser from rendering
808.959 -> other parts of the dom they execute the
810.959 -> second that they're finished downloading
813.04 -> defer is more polite it will also tell
815.36 -> the browser that it can download and
817.12 -> process other stuff on the page but it
819.04 -> won't interrupt the browser to be
820.48 -> executed it will run after the page has
822.639 -> been fully parsed defer is a great idea
825.04 -> for anything that isn't critical for our
826.48 -> initial viewport things like libraries
828.639 -> video players or widgets used lower down
830.639 -> on the page removing extra network
832.88 -> downloads is great but it isn't always
835.04 -> practical i mean some remote resources
837.519 -> like images or web fonts can't be
839.76 -> inlined without really bloating our file
841.839 -> size if any of our assets are hosted on
844.079 -> other domains like those in a cdn
846.32 -> we can jump start the work the browser
847.839 -> needs to do by adding dns prefetch or
850.56 -> preload metadata to our page
852.8 -> these are more hints that we can share
854.079 -> with the browser to let it do more work
855.68 -> simultaneously
857.04 -> dns prefetch is a signal saying i'm
859.199 -> going to need to download content from
861.04 -> this domain in the future it may seem
863.519 -> kind of silly but it can actually help
865.36 -> quite a bit depending on how our site's
867.12 -> structured the browsers they don't know
869.839 -> how to get to every single website in
871.839 -> the world you know when they look up
873.519 -> something new they use a system called
875.44 -> dns
876.56 -> normally as the browser processes our
878.24 -> code it will discover a url of something
880.24 -> that we want to be downloaded they will
882.16 -> use dns to figure out the ip address of
884.16 -> that site's server and then figure out
885.839 -> how to get to it on the internet even
887.839 -> though it's pretty quick normally it
889.44 -> still takes time and even possibly
892.16 -> dozens of trips through space or around
893.839 -> the world
895.199 -> using dns prefetch we're telling the
897.279 -> browser to do all that work in the
898.56 -> background while processing the page so
900.639 -> that by the time we get to that url in
902.32 -> the code that dns has already been
904.079 -> resolved making our site all the faster
906.72 -> that's not the only work that needs to
907.92 -> be done however if we're following best
909.92 -> practices and only loading content over
911.76 -> https the browser needs to initiate
914.079 -> what's called a handshake to the server
915.839 -> before bytes can be downloaded from it
917.839 -> that handshake is when a few messages
919.92 -> get passed back and forth from the
921.519 -> browser to the server and back to secure
923.839 -> any communication that happens between
925.36 -> them just like dns it happens incredibly
927.76 -> fast already but we can make it all the
929.6 -> faster just by adding a preconnect
931.279 -> statement to our page
932.88 -> just like dns prefetch it's letting the
934.639 -> server know it's okay to do that work in
936.399 -> the background therefore we can kind of
938.24 -> skip past it once we get to it in the
940 -> code
941.04 -> parallelizing these network tasks is
943.04 -> especially helpful on slow networks or
945.04 -> less powerful devices two situations
947.44 -> that can easily result in our lcp taking
949.6 -> longer than that 2.5 second goal if you
952.079 -> have remote content in the initial
953.44 -> viewport dns prefetch and preconnect can
955.839 -> shave even more milliseconds off of our
957.519 -> lcp
958.88 -> a similar concept to dns prefetch and
961.04 -> preconnect is preload
963.44 -> this is yet another piece of metadata
965.279 -> that will tell the browser that we can
966.88 -> actually download and parse the content
969.12 -> so it's going to be a lot more resource
971.12 -> intensive
972.16 -> if we use preload on too many things the
974.32 -> browser can actually get bogged down it
976.16 -> can perform even worse than it does
977.6 -> without it therefore it should only be
979.6 -> used on content that is extremely
981.36 -> important like the stuff in our initial
983.279 -> viewport
984.56 -> we can use preload on scripts style
987.36 -> sheets images videos web fonts i mean
989.92 -> pretty much anything that can trigger an
991.519 -> lcp event
992.959 -> i think the most common cause of bad lcp
995.12 -> that i've seen has got to be images it's
997.519 -> just not surprising images make up
999.279 -> nearly half of the bytes on the average
1000.959 -> desktop or mobile page according to the
1002.959 -> http archive
1004.48 -> yet again image optimizations could be
1006.56 -> its own series but there are some key
1008.56 -> things that you should be ensuring on
1009.839 -> your page to make sure that your site is
1011.6 -> running efficiently as possible
1013.6 -> number one use efficient images make
1016 -> sure that you're not shipping images
1017.68 -> that are way larger than they actually
1019.199 -> need to be displayed and that you're
1021.12 -> compressing your images down as much as
1022.639 -> possible
1023.6 -> tools like swoosh dot app linked below
1026.16 -> can actually automatically compress the
1027.76 -> image and check for visual degradation
1029.839 -> this allows you to get an even smaller
1031.76 -> version of an image that is going to be
1033.439 -> the absolute tiniest thing possible
1035.76 -> every byte saved on our initial viewport
1037.679 -> means our lcp can happen that much
1039.36 -> faster
1040.64 -> for images that are not in the initial
1041.919 -> viewport we're going to make sure to add
1043.52 -> loading equals lazy to them this is a
1045.679 -> fairly new attribute that can be added
1047.199 -> to any image tag that will tell the
1048.88 -> browser that we can delay loading these
1050.64 -> images a little bit because they're less
1052.24 -> likely to be seen right away this will
1054.16 -> allow it to free up other resources for
1056.08 -> more critical content but just make sure
1058.48 -> you're not adding this to content that
1060 -> could be in your initial viewport
1062.08 -> that will deprioritize it and more than
1064.08 -> likely negatively impact our lcp perhaps
1066.559 -> more importantly is to use modern image
1068.48 -> formats browsers and servers have
1070.88 -> content negotiation this is a really
1072.88 -> cool thing it basically means that every
1074.96 -> time a browser sends a request to a
1076.64 -> server it also tells the server the type
1078.559 -> of contents that it supports this is
1080.4 -> really helpful because we can use it to
1081.679 -> know if our user's browsers can support
1083.28 -> things like webp or adif see those are
1086.799 -> modern image formats that we can use
1088.72 -> that can result in images that are up to
1090.799 -> 90 smaller than traditional jpegs
1093.44 -> so when the user's browser is parsing
1095.12 -> our code and finds an image it sends a
1096.88 -> request to our cdn or server to download
1099.12 -> that image at the same time it also says
1101.44 -> hey i support webp or i support avif
1104.799 -> on the server we can check for this
1106.32 -> information and then rather than reply
1108.24 -> with the jpeg or png that we would
1110.24 -> otherwise serve to other browsers we can
1112.32 -> serve that modern smaller file format
1114.799 -> this can have gigantic impact on our lcp
1117.36 -> i mean it can cut double-digit
1118.64 -> percentages out of the bytes that are
1120.16 -> needed to download for our site you know
1121.919 -> if you haven't already make sure that
1123.52 -> you look into shipping modern image
1125.28 -> formats today
1127.36 -> so i know i've said a couple of times
1129.28 -> that we'll talk about that later well
1130.799 -> later is now so here are some of the
1132.72 -> gotchas and nuances to keep in mind when
1134.4 -> you're exploring lcp we've already gone
1136.72 -> pretty long in this video so let's run
1138.4 -> through these as fast as possible
1141.039 -> number one lcp does not look at the
1143.12 -> largest element on the user's screen
1145.36 -> it looks at the element with the most
1146.799 -> number of pixels that are visible
1148.72 -> if you have a gigantic element that's
1150.16 -> clipped or has its opacity sent to zero
1152.16 -> then those non-visible pixels aren't
1154 -> counted towards its size
1155.76 -> number two in order to make sure that we
1157.44 -> don't hurt browser performance when
1158.559 -> checking our performance lcp only looks
1160.48 -> at the initial position and size of an
1162.32 -> element if it's rendered on the screen
1164.08 -> and then is moved off it can still count
1166.32 -> likewise if it renders off the screen
1167.76 -> and then is animated onto the screen it
1169.52 -> will not be counted by lcp
1172 -> number three since lcp is what your
1174 -> users are actually seeing you may get
1175.84 -> some unusually bad lcp scores if a page
1178.24 -> gets loaded into the background window
1179.84 -> or tab
1180.96 -> see those pages are going to be loaded
1182.64 -> much more slowly and lower priority than
1184.64 -> tabs with the foreground so when in
1186.64 -> doubt dive into your own analytics to
1188.24 -> look for patterns that may explain weird
1189.76 -> results number four due to the security
1192.559 -> model on the web you can't get lcp
1194.48 -> information from an iframe on your page
1196.4 -> at least by default as far as the
1197.919 -> browser is concerned however that
1199.44 -> content still impacts your url's lcp
1202.08 -> that means that if you're monitoring
1203.36 -> your lcp via performance observer you
1205.36 -> may actually miss the lcp events that
1207.039 -> are being reported by the browser
1209.12 -> you can avoid this by adding cores to
1210.72 -> the iframes and having them report their
1212.559 -> values to the parent iframe but just
1214.799 -> don't have iframes as little as you can
1217.28 -> and if you do keep them out of your
1218.4 -> initial viewport i mean they're a
1219.6 -> headache you try to avoid it if possible
1222.08 -> number five performance observer does
1224.08 -> not emit events when you get to the page
1225.919 -> by the back or forward browser buttons
1228.08 -> this is because those pages are cached
1229.44 -> in the browser so the same events in the
1231.039 -> pipeline aren't being executed however
1233.28 -> the browser still reports the lcp
1234.88 -> information for those situations since
1236.799 -> as a user it's still a page view i mean
1239.36 -> why would you split those hairs
1241.52 -> edge cases gotta love them and finally
1243.919 -> number six not so much an edge case but
1246.24 -> more of a super important tip you know
1248 -> you can actually get a sneak preview of
1249.6 -> your lcp scores see while the canonical
1252.08 -> information only comes out every 28 days
1254.48 -> we can keep track of how we're doing
1256.08 -> every day using our own analytics and
1257.919 -> the performance observer code we looked
1259.44 -> at earlier
1260.48 -> with google analytics for example we can
1262.4 -> create a custom event and then add the
1264.24 -> lcp information to it whenever a visitor
1266.24 -> comes to our page this means that we get
1268 -> up to the minute lcp results for any
1269.679 -> improvements we're working on rather
1270.96 -> than waiting an entire month to know if
1272.4 -> we even move the needle
1274.64 -> there is a lot to lcp and all the web
1276.88 -> vitals i hope that this has been able to
1278.96 -> shed a little bit of light on it for you
1280.32 -> though you know there absolutely is more
1282.32 -> to the topic so please be sure to share
1284.24 -> any questions that you may have on
1285.36 -> twitter or in the comment sections below
1287.2 -> we'll be sure to answer them for you
1288.799 -> make sure that you also subscribe if you
1290.24 -> haven't already we'll be back soon to
1292 -> check out the final portion of page
1293.44 -> experience see you soon
1295.74 -> [Music]
1306.96 -> you
Source: https://www.youtube.com/watch?v=480m72yjZv8