technichal seo

4.4/5 - (10 votes)

How to improve CWV?

According to Google research, mobile Internet users only hold their attention on the screen for 4-8 seconds at a time.
So, you have less than 8 seconds to get the user interested in your site.

Go to Core Web Vitals (CWV)

Core Web Vitals measures how long it takes to execute the script functions required to paint the top part of a web page.
When your page is rated positively by CWV, it means that the user will most likely not leave the page due to the slow loading.



Expected Page Experience update

CWV will presumably become a ranking factor.
The Page Experience Ranking, which is likely to roll out gradually from mid-June to August 2021, will include:

  • Core Web Vitals. Largest Contentful Paint (LCP). First Input Delay (FID). Visual Stability.
  • Mobile usability.
  • Security issues.
  • HTTPS.
  • Ads experience.

New Site Report in Search Console



Search Console now includes a Page Quality Report. Includes data for the last 90 days.

For a URL to be considered “good”, it must meet the following criteria:

  • The URL has a Good status in the Core Web Vitals report.
  • According to the mobility report, the URL has no mobile usability issues.
  • There are no security problems on the site.
  • The URL is served over HTTPS.
  • The site has no ad issues, or the site has not been rated for ad quality.

The new report offers widgets with links to reports for each of the five “Good” criteria.



Largest Contentful Paint (LCP)

Measured by the point on the page load timeline when the largest image or text block of the page is displayed in the viewport.
Pages using the same page templates usually share the same LCP node.
3/4 of the pages should reach the LCP in less than 2.5 seconds.

What could an LCP be?

The LCP metric measures when the largest text or image element in the viewport is visible.
Possible elements that can be LCP node on the page include:

  • Elements img.
  • Image elements inside the svg tag.
  • video elements.
  • Background images are loaded via the CSS url () function.
  • Text nodes inside block elements.

Additional elements such as svg and video are expected in the future.

What could be causing a bad LCP?

Poor LCP causes four common problems:

  • Slow server response time.
  • JavaScript and CSS with blocking rendering.
  • Slow loading time of resources.
  • Rendering on the client side.

Diagnosing bad LCP due to slow server response times

Time to First Byte (TTFB)

IF you constantly see bad TTFB in your data, then it is slow server response time.

How to fix slow server response times

The server response time depends on many factors, depending on the technological stack of the site.
Here are some possible ways to improve TTFB:

  • Optimize your server.
  • Use a CDN.
  • Caching.

Diagnosing bad LCP due to blocking JavaScript and CSS rendering

How to fix render blocking CSS

CSS blocks rendering and affects the performance of the critical render path. By default, CSS is treated as a render-blocking resource.

The browser loads all CSS resources, regardless of their blocking or non-blocking behavior.

Minify CSS.

Install a plugin that will systematically minify scripts.

Defer non-critical CSS.

If styles are used on another page, create a separate stylesheet for those pages that use it to call.

Inline critical CSS.

Include the critical path CSS used for the content at the top of the page (as indicated in the code coverage report) directly in head.

Use dynamic media queries.

Media queries are simple filters that, when applied to CSS styles, break out the styles depending on the types of devices.

Using dynamic media queries means that instead of calculating the styles for all viewports, you’re calling and calculating those values to the requesting viewport.

How to fix JavaScript blocking rendering

Minify and compress JavaScript files.

Minification involves removing unnecessary spaces and code. It is best to do this systematically with a JavaScript compression tool.

Compression involves algorithmic changes to the data format for efficient communication with the server and client.

Defer unused JavaScript.

Code splitting breaks up large chunks of JS to deliver smaller packages. Then you can download the ones that matter first to the top of the page.

How to fix third party scripts blocking rendering:

Postpone the execution of scripts.

If the script does not affect the content at the top of the page, use the async or defer attributes.

Remove scripts.

If the script uses (iframe) in the header, remove it.

Consolidate scripts.

And analyze the value of third-party scripts – how much is their presence more important than website performance?

Diagnostics of poor quality LCP due to slow resource loading

Here are ways to combat the most common causes of slow resource loading:

1. Optimize and compress images.
Nobody needs a 10MB png file.
2. Preload critical resources.
If the resource is part of a critical path, a simple rel = “preload” attribute tells the browser to fetch it as quickly as possible.
3. Compress text files.
4. Responsive layout based on the method of network connection.
A mobile device on a 4G network is unlikely to need to download resources oriented for viewing on an Ultra 4K monitor.
5. Cache resources
Core Web Vitals is a way to measure the performance of your rendering strategies.
All render options create web pages, but CWV metrics measure how quickly what matters most is done and when it matters.

How to fix client side rendering

1. Minimize critical JavaScript.
Use code splitting and inline functions in the header for the functionality above. Inline scripts must be <1KB.
2. Use server side rendering.
If your servers are running JS elements, you can return fully rendered HTML. Note that this will increase your TTFB as the scripts are executed before your server responds.
3. Use pre-rendering.
At build time, run your scripts and prepare HTML for incoming requests. This option provides the best server response time, but does not work for sites with frequently changing products or prices.
To be clear: dynamic rendering is not a client-side rendering solution. It can even become a client-side problem.

First input delay (FID) First input delay

Indicates responsiveness to user input.

It is measured by the time from the moment the user first interacts with the page until the moment the browser can actually start processing in response to it.
3/4 pages must have FID less than 100 milliseconds.

Use total block time (TBT) for tests
Since the FID is only available as test data, tests must use the total block time. They achieve the same end result with different thresholds.
TBT is measured by the total time that the main thread is busy with tasks that exceed 50ms.
We need to keep within 300 milliseconds.

What Causes Bad FID?

A bad FID can occur due to the JS taking up the main thread, which means you have to wait for user interaction.

What page elements are affected by FID?
FID is a way to measure the activity of the main stream. Before the elements on the page can respond to user interaction, you must complete the running tasks on the main thread.

Here are some of the more common elements that keep the user waiting:

  • Text fields.
  • Flags.
  • Radio buttons (input and textarea).
  • Drop-down lists (select).
  • Links

How to fix a bad FID

Stop loading a lot of third party scripts.

Third-party code makes your performance dependent on someone else.
You depend on their scripts and their effectiveness.

Free up the main download thread by splitting larger tasks.

For example, you send one massive JS bundle per page, there are many features in this bundle that don’t affect the page.
Regardless, every JS function must be loaded, parsed, compiled, and executed.

By splitting this large packet into smaller ones and sending only the ones that are in use, you free up the main thread.

Check your tag manager.
Tag managers can be lengthy input handlers blocking downloads.

Execute JS packages in the order you want.

  • Use rel = preload.
  • Add the async attribute.
  • Defer script execution using the defer attribute.

Cumulative Layout Shift (CLS)

Responsible for visual stability.
The measurement is based on the number of frames in which the element (s) are visually moved and the total distance, in pixels, that the element (s) are moved.
CLS is the only Core Web Vital not measured over time. Instead, CLS is a calculated metric.
¾ pages must have a CLS score more than 0.10.

Diagnosing bad CLS

What can be counted in CLS?

If an item appears in the original viewport, it becomes part of the metric calculation.
If you load the footer before the main content and it appears in the viewport, then the footer is part of your (terrible) CLS score.

What Causes Bad CLS?

This could very well be your cookie notice

How to fix bad CLS

Always include width and height size attributes in images and videos.
But responsive web design has fewer height and width declarations. The effect is to rearrange the pages after the image appears on the screen.
It is best to use the user’s browser style sheets based on the aspect ratio of the image.

Third-party advertising on the site does not definitely positively affect the performance of the site and CLS in particular.
Better to immediately identify the largest ad that can be used in the ad slot and reserve the ad space. If there is no announcement yet, insert a blank. This is better than shifting the layout later.

Avoid pasting new content over existing content.
Avoid ads at the top of the page.
Preload fonts and important resources.
Late font loading causes blinking and page reloading.

Preloading tells the browser that you would like to receive the font before the browser detects it, because it is important for the current page.

Avoid chains for resources needed to create content at the top of the page.
Chaining occurs when you call a resource that calls a resource. If a critical resource is called by a script, it cannot be called until that script is executed.

Avoid document.write ()
Modern browsers support lookahead parsing of the main download thread.
They start working ahead of time while scripts are being loaded and executed – but document.write () appears and declares that whatever was done beforehand was useless.

Future CWV Metrics

Google intends to update the Page Experience components annually. Future CWV metrics will be just as open to use as they were when they were originally released.
This will allow SEO specialists to more carefully approach the issue of site optimization and anticipate changes in the ranking of sites in advance.
As SEO specialists, we can diagnose and provide solutions to improve the user experience. Technical SEO Optimization – website performance is an overall reflection of the health of a site.

Comments are closed