core web vitals how to optimize them for seo with timestamps YoutubeScribe.com

[0:00] As of this month, Core Web Vitals will
become a part of Google's Page Experience
[0:04] ranking signals.
[0:05] And seeing as it's fairly new, there's a lot
of misinformation and misunderstandings
[0:10] around this topic.
[0:12] So in this video, I'm going to explain
exactly what Core Web Vitals are,
[0:16] why they're important, and how
to improve them for SEO.
[0:19] Stay tuned.
[0:20] [music]
[0:24] Core Web Vitals are made up of 3 metrics
that measure specific aspects of pagespeed.
[0:29] And these metrics include visual load
measured by Largest Contentful Paint,
[0:34] visual stability of your web pages measured
by Cumulative Layout Shift, and interactivity
[0:40] which is done with First Input Delay.
[0:42] Now, like many other Google ranking factors, the
Core Web Vitals can't be looked at independently.
[0:48] They're a part of Google's Page Experience
ranking signals which also includes things
[0:53] like mobile friendliness, safe browsing, HTTPs,
and intrusive interstitials, ie. pop-ups.
[1:01] No one knows exactly how big the impact
will be seeing as it's still very young.
[1:06] Regardless, it's probably still worth improving
your Сore Web Vitals because pagespeed
[1:11] improves conversions.
[1:13] In fact, Google found that when a site meets
the optimal thresholds for the 3 Core Web
[1:18] Vitals metrics, users were 24% less
likely to abandon page loads.
[1:24] On top of that they saw a 22% decrease in
new site abandonments and a 24% decrease
[1:30] in shopping site abandonments.
[1:33] Now, before we get into the actual optimizations,
you need to understand the two main types of
[1:38] data for Core Web Vitals metrics.
[1:41] So the two types of data are field
data and lab test data.
[1:45] Field data includes real user metrics and is
generated from the Chrome User Experience
[1:50] Report, also known as CrUX.
[1:53] Basically, Google takes data from Chrome
users who have opted-in to share information
[1:58] like browsing history.
[1:59] They then take that data and compute the 3
Core Web Vitals metrics which are intended
[2:05] to understand how real-world Chrome
users experience the web.
[2:10] You can see a summarized view of your site's
Core Web Vitals in Google Search Console and
[2:14] page-level metrics in PageSpeed Insights
under the "Field Data" category.
[2:19] Now, a huge con is that field data is
based on a rolling 28-day average.
[2:25] Meaning, if you change something on your site,
the full impact won't be reflected until around
[2:30] 28 days later.
[2:32] This is where lab test data can help.
[2:35] This data is usually generated by tools.
[2:37] And lab test tools are designed to run tests
consistently under the same conditions.
[2:43] Meaning, they won't necessarily reflect "real
world" data because of factors like location
[2:47] and internet speeds.
[2:49] On top of that, bots aren't going to interact
with your content, whereas humans will.
[2:55] You can see lab data in PageSpeed Insights,
with the Lighthouse Chrome Extension and
[2:59] in Chrome Dev Tools.
[3:01] Now, there are 2 important things to note:
[3:04] #1. The metrics are assessed at
the 75th percentile of users.
[3:09] For example, if we look at the PageSpeed
Insights report for our SEO hub page, you'll
[3:14] see that all Core Web Vitals metrics
had greater than 75% good loads.
[3:20] So it passes the Core Web Vitals assessment.
[3:23] Whereas our guide on link building doesn't
pass the Core Web Vitals Assessment because
[3:28] one or more metrics have less than
75% good loads.
[3:33] The second thing to note is that metrics
are measured by device type, meaning
[3:37] mobile Core Web Vitals will be assessed
separately from desktop.
[3:42] And since Google has switched to mobile first
indexing, we're most interested in the mobile
[3:46] scores from a ranking perspective.
[3:49] Now, the downside to these tools is that
you can only check one URL at a time.
[3:54] Or for tools like Google Search Console,
you'll only be able to see field data.
[3:58] So we're actually working on adding Core
Web Vitals in our Site Audit tool, where you'll
[4:02] be able see both field and lab test data
for all your pages.
[4:07] And you can use Site Audit free with
an Ahrefs Webmaster Tools account.
[4:11] Alright, so we're ready to start analyzing
and optimizing pages for the 3 metrics.
[4:16] But before you get started, it's important
that you handle the other basics of Google's
[4:20] Page Experience signals like mobile
friendliness, HTTPS, etc.
[4:25] Again, Core Web Vitals are a part of
the page experience ranking signals.
[4:30] Also, you should take care of basic pagespeed
optimizations like having good hosting, caching
[4:36] your content, compressing and lazy loading
your images, and setting up a CDN.
[4:41] All of these things can help improve
your Core Web Vitals.
[4:45] Now, If you don't know how to do these
optimizations and you use WordPress,
[4:49] then I highly recommend watching our tutorial
on how to speed up a WordPress website.
[4:54] Alright, so with the housekeeping stuff out
of the way, let's dig deeper into each metric,
[4:59] recommended thresholds, and get technical
with solutions to common issues.
[5:04] The first metric is Largest Contentful
Paint or LCP, which tells us about visual
[5:09] loading performance.
[5:11] LCP is simply the single largest visible element
loaded in the viewport, which is the area of
[5:16] the web page that's visible to a user.
[5:19] For example, the LCP for our blog post on
keyword research is the featured image.
[5:25] Other common areas might be a background image,
the H1 tag, or even a paragraph in the content.
[5:32] The recommended target is to have your
LCP load in under two and a half seconds.
[5:37] To check LCP for a page, you can use any of
the aforementioned tools like PageSpeed Insights,
[5:43] the Lighthouse extension, or Chrome Dev Tools.
[5:46] Now, when you use PageSpeed Insights or
Lighthouse, you can use lab data as you make
[5:50] updates because again, the field data is
a rolling average of the last 28 days.
[5:56] To see the largest element that was measured,
scroll near the bottom of the report and click
[6:01] "Largest Contentful Paint Element."
[6:03] So for our keyword research guide,
that would be our featured image.
[6:08] Now, if you're working on a dev site that's
not available to the public, you may want
[6:12] to use Chrome Dev Tools.
[6:14] To get started right click anywhere on the page
you want to test and click Inspect element.
[6:20] Make sure you have the Device set to a Mobile
device, click on Performance, hit the Record
[6:26] button, and refresh the page.
[6:28] After the refresh is done, hit Stop.
[6:31] You should then see LCP in the timing graph.
[6:34] And if you hover over it, you'll see the largest
visible element in the viewport - in this case,
[6:39] our featured image
[6:41] Click it, and you'll see more details below.
[6:44] Now, according to Google, the 4 most common
causes of poor LCP are slow server response
[6:50] times, render-blocking JavaScript and
CSS, slow resource load times, and
[6:55] client-side rendering.
[6:57] If you've implemented the basic optimizations
for pagespeed like good hosting, caching,
[7:02] image optimizations and the use of a CDN,
then that should help with loading performance.
[7:08] But if you have issues with render blocking
JS or CSS, then it gets a bit more technical.
[7:13] And in order to make optimizations effectively,
you need to have a basic understanding of
[7:18] how browsers render pages.
[7:21] So let's say a user enters a URL
in their browser.
[7:24] The browser will then send a get request to
get the contents of the requested URL.
[7:29] Then a DNS lookup happens, which basically maps
out domain names to IP addresses of servers.
[7:36] Once the server IP is found, the request is
sent through, a connection is made with
[7:40] the server, and then the server will
search for the file of the URL.
[7:45] And once it finds it, it'll send that data back
to the browser which will then process
[7:49] the file to show the web visitor
the contents of the page.
[7:53] Now, we won't go further into DNS or hosting
because I want to spend our time focusing on
[7:58] what actually happens during
that processing stage.
[8:02] Assuming you requested an HTML file, the browser
first needs to parse the contents, which basically
[8:07] means to extract the code into bits and pieces.
[8:11] And some of these bits and pieces are going
to be links to resources like images, CSS
[8:16] and JavaScript files.
[8:18] So then all of these resources need to go
through that same process which can be
[8:22] time-consuming if you have a lot of
resources you're requesting.
[8:26] To add on to that, if these files need to load
one by one in order to paint the contents on
[8:31] the screen, then your LCP is going
to get destroyed.
[8:36] But there are ways you can optimize this
process to improve loading performance.
[8:41] So let's talk about optimizing the rendering
process for the 3 main types of resources:
[8:45] images, CSS, and JS files.
[8:49] Let's start with images.
[8:50] Aside from the things that I've already mentioned
like lazyloading and compression, preloading
[8:55] images can significantly reduce
page load times.
[8:58] And preloading basically tells browsers
the resources you want to load first.
[9:03] For example, if you have a featured image
in the viewport, then that's something you'd
[9:07] probably want to preload.
[9:09] And preloading can actually be used
in CSS, JS and fonts too.
[9:14] This topic goes pretty deep, so I'll leave
a link to this great article on preloading
[9:19] responsive images if you want to learn more.
[9:22] As for CSS files, there are a few
things you can do.
[9:25] #1. Minify them.
[9:27] Minification removes all unnecessary characters
from source code which leads to smaller file
[9:32] sizes and faster load times.
[9:35] #2. In-line your critical CSS for
above-the-fold content.
[9:40] This might include your website's font, viewport
settings, background color, and an H1 style
[9:46] to name a few.
[9:47] Doing this will allow your viewers to see
content above the fold before all of those
[9:52] round trips are completed in the processing
stage we talked about.
[9:56] And #3. Remove unused CSS and defer
non-critical CSS.
[10:02] To find CSS that your page isn't using, go
to Chrome Dev Tools, click on the vertical
[10:07] ellipses and hit Run command.
[10:10] Then search for Show Coverage.
[10:13] Click the Reload button here, and you'll be
able to see the CSS and/or JS that hasn't
[10:19] been executed in red.
[10:21] Click one of the URLs and you'll see the
exact lines of code that haven't been
[10:25] executed on that page.
[10:28] From here, you can remove anything that
your site isn't using, or move unused code
[10:32] to a separate file and only load that
resource on pages that need it.
[10:37] Now, for JavaScript, you can do pretty
much the same things.
[10:41] Minify it where it won't break your site
and remove non-critical JS.
[10:45] Now, two other things worth doing is to defer
or asynchronously load JS where appropriate.
[10:51] And you can do this by using the defer
or async attributes in your script tags.
[10:56] Now, to better understand these attributes,
you need to understand what happens when
[11:00] JavaScript files are in your HTML code.
[11:03] Assuming we have a regular <script> tag without
any attributes, the HTML file will start parsing
[11:10] until it hits that script file.
[11:12] Parsing is then paused while the script
is downloaded and then executed.
[11:18] Then the remainder of the HTML
contents gets parsed.
[11:21] So as a result, the JavaScript is
blocking and will delay LCP.
[11:27] Now, if you add the async attribute to the
script tag, then the JS file can actually be
[11:32] downloaded while the HTML is parsing.
[11:35] And even though asynchronously loaded JS
can still block LCP, it ensures that important
[11:40] scripts are run earlier.
[11:43] Finally, is the defer attribute.
[11:45] When added, JavaScript files will be
downloaded while the HTML is parsed.
[11:50] But JS will only be executed after
the parser has completed.
[11:54] So it's not blocking.
[11:56] Very generally speaking, you want to use
the async attribute for scripts needed earlier
[12:01] in the page load and defer anything
that can wait until later.
[12:04] Now, if you don't quite have the technical
skills to do this on your own, then it may
[12:08] be worth hiring a developer and/or
technical SEO who can help.
[12:13] Alight, the next metric is Cumulative Layout
Shift or CLS, which measures visual stability.
[12:19] CLS looks at how much visible content
has shifted in the viewport and measures
[12:23] the distance the affected elements were shifted.
[12:26] For example, if we visit this page and start
scrolling down, you'll see that out of nowhere,
[12:32] ads start to appear, shifting the content.
[12:35] It's annoying, causes a bad user experience,
and that's probably the reason why CLS exists.
[12:41] Now, the way they used to measure this
metric was to continually measure stability
[12:46] even after the page had loaded.
[12:48] But recently, Google decided to measure
CLS in 5-second sessions.
[12:53] And the metric they now report is the 5-second
timeframe where the most shifting occurred.
[12:59] So it's not really cumulative anymore,
but I guess that's besides the point.
[13:03] Now, the recommended threshold by
Google is to have a score of less than 0.1.
[13:08] And you can check these in the same
tools that I've already discussed.
[13:12] So if we look at the example page's scores in
PageSpeed Insights, you'll see that the majority
[13:17] of page loads are way off the mark.
[13:19] Now, if you want to actually see these layout
shifts, you can scroll to the bottom of the page
[13:24] and click on "Avoid large layout shifts"
to see the exact parts that are affected.
[13:30] Now, the most common causes of CLS are
images without dimensions, ads, embeds,
[13:35] and iframes without dimensions, dynamically
injected content and when fonts or styles are
[13:41] applied too late in the code.
[13:43] Fixing any of these issues without
dimensions is pretty easy.
[13:47] For images and videos, just add width
and height attributes to your elements.
[13:51] Alternatively, you can use CSS
aspect ratio boxes.
[13:56] For ads, embeds, and iframes, you can create
static elements to reserve space for them.
[14:02] For example, I'm sure you've seen ads that
suddenly appear and push all the content down.
[14:08] Instead, you can define width and
height attributes for the element.
[14:11] In this case, they've added placeholder text,
which eventually changes to an ad once rendered.
[14:18] Now, if you're unsure as to the exact parts
of the page that are causing CLS-related
[14:22] issues, you can use Webpagetest.org.
[14:25] Just enter a URL and then run the test.
[14:29] Next, find the film strip view and click it.
[14:32] Make sure to set the thumbnail size to Huge
and the thumbnail interval to 0.1 seconds.
[14:39] Finally, check the "Highlight layout shifts" box.
[14:43] Now, as you scroll through the film strip,
any frames with dashed borders are ones
[14:47] that had a layout shift.
[14:49] And the parts that are highlighted in the
frames are where layout shifts occurred.
[14:53] If you want to learn more about optimizing
CLS, I'll leave a link to an article in
[14:57] the description below.
[14:59] Alright, the third and final metric is First Input
Delay or FID, which measures interactivity.
[15:06] The purpose of this metric is to get an
understanding of a user's first impression
[15:10] of a site's interactivity and responsiveness.
[15:13] It measures the time from when a user
first interacts with a page to the time
[15:17] when the browser is able to respond
to that interaction.
[15:21] For example, if you look at this gif from
Requestmetrics.com, you'll see that they've
[15:26] created what appears to be a simple script.
[15:29] Click the button and it stops running
the heavy JavaScript.
[15:33] But the time between clicking and completing
the script took over 1.4 seconds, which isn't
[15:40] ideal for users.
[15:42] The recommended speed for FID is
to stay under 100 milliseconds.
[15:46] Now, different types of interactions will
include clicking a link or button, inputting
[15:51] text into a blank field, selecting
a drop-down menu or whatever.
[15:55] Now, the main cause for slow FID is
heavy JavaScript execution.
[16:00] Basically, a user is trying to interact with
the website, but the browser isn't able to
[16:05] respond because the main thread is
busy doing something else.
[16:09] So the four recommendations that Google
provides is to break up long tasks, optimize
[16:14] your pages for interaction readiness, use a web
worker, and reduce JavaScript execution time.
[16:21] I won't go further on this as First Input
Delay is a field metric, meaning, you can't
[16:25] get lab data for it.
[16:27] Google recommends using Total Blocking Time
but they measure completely different things.
[16:32] Plus editing JS is going to be very situational
for each individual person's scripts.
[16:38] Instead, I'll leave a link to Google's guide
on optimizing FID in the description.
[16:43] So with all of this said, the big question
is… do Core Web Vitals really matter that
[16:49] much that you should put the time,
effort, and potentially money into?
[16:53] And like all answers to SEO questions…
it depends.
[16:58] Do I personally think that Core Web Vitals
will be the difference in ranking #1 and #15?
[17:04] No, I don't.
[17:05] It's still very new and not all webmasters
have the technical knowledge to optimize
[17:09] for these metrics.
[17:11] And I highly doubt that Google will be penalizing
Karen's fashion blog or Joey's recipe site
[17:17] because their ads moved the content a bit.
[17:19] John Mueller said, "Quality content
still comes first.
[17:23] Page experience becomes more important
when there are multiple similar results."
[17:28] That's up for interpretation, but the way
I see it is that Core Web Vitals will play
[17:32] as more of a tiebreaker than a "make
it or break it" kind of ranking signal.
[17:37] Let me know what you think about Google's
new Core Web Vitals release and if you found
[17:40] this video to be helpful, make sure to like,
share, and subscribe for more actionable
[17:45] SEO and marketing tutorials.
[17:47] I'll see you in the next one.

本文档为站内渲染。原始文件本地路径：saas/source/seo-llm/raw-seo知识库-seo方法论-youtube-seo-scripts-ahrefs-scripts-core-we-c28694.txt（仅本地保留，不入库不部署）