
<div class="font-semibold">In my job I work on SEO and that means having a good website. With tools like Pagespeed Insights and the Core Web Vitals it’s possible to measure if your website is “good”. But how does that reflect on SEO? And more importantly; what do these metrics mean and how to use them to improve your website.</div>

---

## Google Pagespeed Insights (PSI)
Pagespeed Insights is a tool created by Google to test, measure and report useful metrics about the (technical) performance of web pages. It gives a lot of information but the most noticeable one, and usually the one to brag about, is the PSI Score.

<img src="https://jacht.digital/wp-content/uploads/psi-score.png" loading="lazy" alt="PSI Score" />

Although it doesn’t say much, a “perfect” score always looks good and a high score (90+) does mean you’re doing something right. At least from a technical point of view, because it can’t check if your content makes sense or content is readable in any way.

So even though a good score helps with SEO, because it means your website has a good performance which is good for visitors, it’s only a very small fraction of the final search rank which search engines calculate.
That said; Google has already said for several years that performance and user experience is becoming a bigger factor in their search ranking, especially for mobile. And because of this having a website which is (also) performant on mobile devices is probably more important.

## Core Web Vitals
For a couple of years Google has put the focus on 3 specific metrics called the Core Web Vitals. These metrics are Largest Contentful Paint (LCP), First Input Delay (FID) and Cumulative Layout Shift (CLS). And even with these 3 metrics in the spotlight, the rest is still as important if not more important.

<div class="flex flex-row flex-nowrap gap-3 max-w-full">
    <div class="flex-1"><img src="https://jacht.digital/wp-content/uploads/cwv-lcp.png" loading="lazy" alt="Largest Contentful Paint (LCP)" /></div>
    <div class="flex-1"><img src="https://jacht.digital/wp-content/uploads/cwv-fid.png" loading="lazy" alt="First Input Delay (FID)" /></div>
    <div class="flex-1"><img src="https://jacht.digital/wp-content/uploads/cwv-cls.png" loading="lazy" alt="Cumulative Layout Shift (CLS)" /></div>
</div>

### Largest Contentful Paint (LCP)
The LCP measures how long it takes till the largest element in the viewport (visible part) is loaded. Usually this is the hero (with image or video background). It does not measure the time for this single element, but the time till the element has been fully loaded. So all scripts and styles in the head will also count towards this, and of course images and external assets which are used above the fold.
In short; it measures the time till the page is loaded within the screen.

### First Input Delay (FID)
FID is a time metric which measures the time it takes for an event to react. For example it takes the time between a user clicking on a button and the moment the browser is executing the action attached to the button. Normally a browser will do this directly (within 10ms), but if a browser is still working on stuff in the background like loading assets or running scripts, this can slow down a lot.

### Cumulative Layout Shift (CLS)
CLS is not something you can easily measure, and is not time based but a score. It checks for elements which move around, or cause movement of elements. For example when you load an image, which obviously can take some time, the content below it will change its position the moment the image is loaded. Or when you use javascript to position content after the page has been loaded. These movements will give a higher, and thus worse, score on the CLS. This score is calculated by the impact (how much does it disturb the layout) and the distance (how many pixels does it move).

### Other metrics
Besides these 3, which together make the Core Web Vitals, there are several other metrics which are measured by PageSpeed Insights and are just as important to look into when optimizing your website or page.

<dl>
<dt><strong>First Contentful Paint (FCP)</strong></dt>
<dd>Measures the time till the first piece of content (like text or image) is rendered on the page. So the first time "any" content is visible in the browser.</dd>

<dt><strong>Speed Index</strong></dt>
<dd>Measures the time it takes to render elements on the page. For example the time it takes to request, download and show an image on page.</dd>

<dt><strong>Time to Interactive (TTI)</strong></dt>
<dd>Measures the time till the page is fully interactive. This means that the full page is loaded, including images, scripts and styles, and the visitor is able to see and do anything the page is supposed to do (like clicking a button or scrolling the page).</dd>

<dt><strong>Total Blocking Time (TBT)</strong></dt>
<dd>The aggregated time of long tasks. Any task (like a mouse click) which takes longer than 50ms to respond is a long task. The TBT will take the time above the 50ms, and add all long tasks together. For example if a task takes 70ms the TBT will be increased by 20ms.</dd>
</dl>

### Field Data vs Lab Data
On PageSpeed Insights you will see 2 types of data; Field Data (Discover what your real users are experiencing) and Lab Data (Diagnose performance issues). And you might notice that some metrics appear in both but have different values.

Field Data takes the averages from actual visitors on your website from the past 28 days, which has been gathered by Chrome/Chromium users who visited your website. These numbers won’t change directly the moment you make changes to your website and may not be very precise. However it does give a good indication of the average user experience of visitors. Especially when looking at the percentages, which indicated how many visitors had a good, medium or poor experience the past month.

<img src="https://jacht.digital/wp-content/uploads/cwv-assessment.png" loading="lazy" alt="Core Web Vitals Assessment" />

The Lab Data is gathered at this moment and are actual numbers. Even though it’s not 100% accurate since it doesn’t run on an actual browser, and different browsers may behave differently, it still is the best list to keep an eye on when working on improvements.
Also keep in mind that the tests are run from a server local to the tester, and not the location of the server. So it’s possible that if 2 people run a test on the same page, but from different locations, the results are different. And even from the same location it’s possible that the score changes a bit since there are a lot of other factors which may affect the speed of your website.

### So what is Lighthouse?
When looking around PageSpeed Insights and Core Web Vitals, you might find another name popping up a lot: Lighthouse.
Lighthouse is the tool used by Google to gather the measurements and statistics it uses for PSI and CWV. You’ll also be able to find in it Chrome, Opera or any Chromium based browser as part of the DevTools (Press Command+Option+J (Mac) or Control+Shift+J (Windows, Linux, ChromeOS) to jump straight into the Console panel).
It’s also available as a browser extension for <a href="https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk" target="_blank" rel="noopener">Chrome, Opera</a> and <a href="https://addons.mozilla.org/nl/firefox/addon/google-lighthouse/" target="_blank" rel="noopener">Firefox</a>, but also as a <a href="https://github.com/GoogleChrome/lighthouse#using-the-node-cli" target="_blank" rel="noopener">CLI tool</a>.
There’s even a tool which allows you to scan your whole website at once: <a href="https://unlighthouse.dev/" target="_blank" rel="noopener">Unlighthouse</a>. However if you already use tools like SERanking, AHrefs or Semrush then this is already done for you (with more detailed information about the issues).


### Low scores and how to fix them
There can be many reasons why the score for your website is not in the green, but luckily does Google also give information about what is causing the issues and where to look for a fix. These could be as simple as adding a width and height to images or lazy loading external files, but can also mean the server needs to be upgraded or improved caching methods need to be implemented.

<img src="https://jacht.digital/wp-content/uploads/psi-metrics.png" loading="lazy" alt="PageSpeed Insights Metrics" />

The metrics are primarily technical topics which can be solved either at server level (hardware, programming and <a href="/blog/understanding-cache">cache</a>) or are more frontend focused (fonts, large images and javascript).

This might not look like it affects SEO, but it actually does. Google tracks these metrics because it’s how the visitor sees and feels about your website. Nobody likes a slow and unresponsive website, so your ranking will be affected when these numbers are all in the red.
You don’t have to worry that a single orange or red number will set you back 10 places in the results, but if your competitors are doing better, they can be listed above you.

To improve these numbers it’s important to understand why they aren’t as good as Google would like, and if it’s something you can and want to improve.

## Quick wins
The first step is looking at the ‘opportunities’, which Google believes are quick and easy to fix, and helps with the overall performance of your page/website.

For example providing .webp images instead of .jpg and .png may give a small speed boost since they are generally smaller in size. However, and this is something Google doesn’t tell you, it’s important to set a fallback as well since older browsers may not support these ‘next-gen formats.’

Also deferring scripts (= loading them when possible while not blocking the rest of the page) is a good way to increase the speed of your page loading. But this should be done with care because some scripts must be loaded for the page to function properly.
‘Render-blocking resources’ will be improved by this, just like lazy-loading images and other media.

An important thing to look at are the differences between Desktop and Mobile, because they may give different suggestions, or have a much larger impact on mobile.

<figure>
<img src="https://jacht.digital/wp-content/uploads/oppertunities-desktop.png" loading="lazy" alt="oppertunities desktop" />
<figcaption>Desktop</figcaption>
</figure>

<figure>
<img src="https://jacht.digital/wp-content/uploads/oppertunities-mobile.png" loading="lazy" alt="oppertunities mobile" />
<figcaption>Mobile</figcaption>
</figure>

As the images show, which are from the same page, desktop and mobile show slightly different possible fixes. Although the one that is almost always shown on live websites is the “Reduce unused Javascript” opportunity. The reason is simple: Google Tag Manager and Google Analytics.

This might sound strange, but the performance drop for using GTM and GA is actually terrible. Not only does it add a lot of additional files to the loading queue, but they’re also loading a lot of code which probably is never used. And lastly, the caching rules on these files are terrible, which again is seen as bad practice by Google.
And while adding a lot of tracking and analytics scripts GTM is normal, these only add to an overall bad performance.

So fixing everything isn’t always possible, but knowing what the reason is means you can make a better decision on what you can do and where to focus your attention.


How good is you page
The next part of the PSI report is the Diagnostics. These indicate the more technical issues with your website, which can be hard to improve without rewriting code (both front- and backend).

For example “Avoid an excessive DOM size” is seen a lot at WordPress websites which use a theme or page builder, which are known for adding a lot of extra elements to the HTML. Of course these builders are great to quickly build a nice website without any programming knowledge, but the code quality is far from great.
It can also mean there are just too many elements on the page created by an excessive amount of content presented which are badly optimized.

<figure>
<img src="https://jacht.digital/wp-content/uploads/diagnostics-desktop.png" loading="lazy" alt="diagnostics desktop" />
<figcaption>Desktop</figcaption>
</figure>

<figure>
<img src="https://jacht.digital/wp-content/uploads/diagnostics-mobile.png" loading="lazy" alt="diagnostics mobile" />
<figcaption>Mobile</figcaption>
</figure>


When looking at the mobile version of the same page two of the biggest red flags are “Reduce the impact of third-party” and “Reduce Javascript execution time”.
These are usually caused by tracking and analytics scripts from third parties, like Google Tag Manager and the other tools it loads.
These are scripts you can’t really control on how they do their job, but it is possible to reduce the impact when loading the page especially when those scripts aren’t needed at that specific page or can be loaded at a later time, by using modified triggers.

The “First Contentful Paint (3G)” is the same as the FCP metric, except it’s measured at a mobile 3G connection, meaning it’s slower than average internet speeds. This results in external files (like javascripts and stylesheets, but also images and fonts) to be loaded slower and will cause the website to show something at a later stage than prefered.
One of the major fixes is to use proper caching so files are loaded faster from the server, and have good browser cache rules in place for returning visits. But the test won’t have browser cache, so it will always load all files at every request.
There are many ways to optimize the loading speed of files, like minifying scripts and stylesheets, compressing images, swapping fonts and of course lazy loading media files. All these optimization techniques will ensure the FCP is as fast as possible (and many other metrics), but may increase the CLS because things will happen after the page is loaded and layout shifting will happen since elements will suddenly take up more or less space than initially available.


## Specific solution for my problem
PageSpeed Insights is testing a lot of different things, and a lot of stuff can be broken or require optimizations. Going through each possible problem and providing a fix for each use-case would probably add another 100 pages of text and code examples, and won’t be enough for all possible scenarios.
Most issues which come up through the Core Web Vitals and PageSpeed Insights checks are technical and require a developer or technical solution to be solved. But understanding what the issue is and where to look for an answer is the first step to improvement.


How to use Core Web Vitals & Google Pagespeed Insights


<div class="font-semibold">Redirects are a SEO experts biggest friend but at the same time something that can kill your SEO scores when done wrong. This guide will explain which types of redirects there are, how they work and when to use them properly.</div>

---

## What is a redirect?
A redirect is a way to tell a browser or search engine bot that the URI they landed on is moved to another location. This can be permanently, temporarily or just a way send the visitor to a new location when needed.

For SEO redirects are usually used in cases like:
- Change of domain name; for example you've acquired a .com version of your domain and want to use it as the main URL for your website.
- Changed the location of an existing page/post; for example all blog articles used to be at `/blog/title-of-article` but you moved them to `/news/title-of-article`.
- Multiple URI's going to the same page/post; most seen in ecommerce where you can access products through multiple URL's.
- Deletion of locations; it's not bad to remove old and outdated content, but the URL might still have backlinks.

## Different types of redirects
As Google explains it, there are 2 types of redirects: temporary (weak) and permanent (strong) redirects. However it would make more sense to add a third type: ignore (none). This will make sense when you understand the different status codes for redirect.

Redirects are usually indicated with a HTTP Status Code in the 300 range, similar to the 100, 200, 400 and 500 status codes which are used by servers to return the status of the request.
Redirection messages may have any code or message as long as it's in the 300 range (so 300 till 399), hoever a couple are standardized:

### 300 Multiple Choice
The request has multiple possible responsives and it's up to the browser, bot or user to decide how to proceed. This shouldn't be used on regular websites since there is no way to handle this automatically, but can be of use in API's.
For example: you try to go to `/my-account/` but aren't logged in yet. Instead of returning a 401 Unautorized response you could offer 2 possible redirects; one to `/login/` and one to `/register/`. Again, not very usefull for regular websites, but an API could use this perfectly fine.

### 301 Moved Permanently
Short and simple, the URL which has been requested has been moved to a different location permanently. Keep in mind that this redirect does not care which method (GET, POST, PUT, DELETE, etc.) was used and should be used for the redirect request. By default a browser will use the same method (eg. submitting a form to URL 1 with a redirect will correctly submit it to the final URL without a problem). This will let search engines remove the old URL and contents, and start indexing the new location instead.

### 302 Found
The location has been changed temporarily, but the current URL should still be used (now and in the future). Search engines will keep the current (or actually old) URL and it's contents and ignore the redirect itself. In short; simply ignore the redirect (although do show the contents of the new location for now). Browsers will handle it automatically.

### 303 See Other
Again an 'ignore' response search engines, because it simply means "you're at the right place, but the final response is somewhere else" and only applies to POST and PUT requests (which search engines don't do). For example when you're done submitting a form to an URL it can return a 303 to indicate that the thank you page is somewhere else. Browsers will handle this correctly, and is especially usefull in API's.

### 304 Not Modified
A 304 status means that the result is cached by the browser, and therefor doesn't need to do a full request to the server. This only works when the first request (before it was cached) contains the correct headers to indicate the response is allowed to be cached. This is usually the case for static files (images, scripts, stylesheets). For search engine bots this has no effect and is (indirectly) ignored, however proper cache headers for static files is very important for SEO since it will indicate the website is optimized for performance.

### 307 Temporary Redirect
Works the same as a 302 Found response, except that it's more strict when it comes to the method which was used in the original request. For example when the URL was accessed through a POST, the redirect must be a POST as well. Browsers will do this automatically (also with a 302 response), however a 307 is a better version and should be used unless technically a 302 is required.

### 308 Permanent Redirect
The 308 response is  a stricter version of the 301 response, where again the request method must match the original request. Search engines will re-index the new location and remove the old one, while browsers will simply redirect directly without any issues.

## Alternative redirection methods

### Meta refresh
A meta refresh can be handled by the server (response headers) or client (HTML meta tag), and can be used for both a permanent and a temporary redirect. Google Search will handle instant meta refresh redirects as permanent, meaning the refresh rate is set to 0. Delayed meta refresh redirects, so a refresh rate more than 0 seconds, is handled as a temporary redirect.
This should only be used when it's not possible to set proper server redirects with the 300 status codes.

```html
<head>
   <meta http-equiv="Refresh" content="0; URL=https://example.com/">
</head>
```

### Javascript redirect
In Javascript it's also possible to send a visitor to a new location. There are several usecases for this from a browser perspective, however for SEO it's a bad idea to implement. Google Search may see the redirect correctly, but only once the original URL has been crawled fully. So don't rely on this for setting up redirects for an URL, although browsers will handle this as long as Javascript is enabled and no errors occur loading the page.

```js
window.location = "https://example.com/";
```

### Crypto redirects
If none of the above can be implemented a simple link on the original page can tell your visitors they need to visit a new URL for the content. This will not be handled by browsers or search engines at all.

```html
<body>
   <p>This page has been redirected to <a href="https://example.com/">example.com</a>.
</body>
```

### Canonicals
Technically not a redirect, but extremely important for search engines. When you have one piece of content available on multiple locations (multiple domains, different URI's, etc.) they might be flagged as duplicate content, causing a SEO penalty. To resolve this set up a canonical URL to only one location, so that all the others are simply seen as alternatives. Search engines will then only return the "master" URL when people search for it, but will still allow the alternative URL's as valid results when searching specifically on the other locations.
So it's not a real redirect visible for users, but search engines will know the real URL of the current content is somewhere else.

## How to implement a redirect correctly

### WordPress
There are multiple plugins for WordPress which allow you to set up redirects.

[Redirection](https://wordpress.org/plugins/redirection/) is probably the most known plugin to do this. This plugin makes extremely easy to set up redirects and even automatically creates redirects when changing post/page titles and thus permalinks.
It also has the option to set up the redirection in .htaccess or create NGINX rules (depending on the server software and permissions available). And the best thing is, it's completely free.

SEO plugins like [Yoast SEO](https://wordpress.org/plugins/wordpress-seo/), [SEOPress](https://wordpress.org/plugins/wp-seopress/), [Rank Math SEO](https://wordpress.org/plugins/seo-by-rank-math/) and many others, also have redirections build in, including a lot of other nice features to improve your website for SEO. Keep in mind though that a paid version may be required to get all the features.

### Apache - `mod_alias`
To setup redirects with Apache, which can be done through server configs, virtual hosts, directories and .htaccess files, which uses the `mod_alias` module you can use the follow examples:
```apache
# 301 Permanent redirect:
Redirect permanent "/old" "http://example.com/new"
Redirect 301 "/old" "http://example.com/new"

# 308 Permanent redirect:
Redirect 308 "/old" "http://example.com/new"


# 302 Temporary redirect:
Redirect temp "/two-old" "http://example.com/two-new"
Redirect 302 "/two-old" "http://example.com/two-new"

# 307 Temporary redirect:
Redirect 307 "/old" "http://example.com/new"
```

### Apache - `mod_rewrite`
Just like `mod_alias` you can use `mod_rewrite` to setup redirect in Apache.
```apache
RewriteEngine on

# 301 Permanent redirect:
RewriteRule   "^/old$"  "/new"  [R=301]

# 308 Permanent redirect:
RewriteRule   "^/old$"  "/new"  [R=308]


# 302 Temporary redirect:
RewriteRule   "^/old$"  "/new"  [R]
RewriteRule   "^/old$"  "/new"  [R=302]

# 307 Temporary redirect:
RewriteRule   "^/old$"  "/new"  [R=307]
```

#### So what is the difference between `mod_alias` and `mod_rewrite`?
Normally they work the same at server level, by taking the incomming URL and returning the "redirected" content, but without actually telling the visitor that this happened.
However `mod_rewrite` does allow you to actually create a real redirect with the `[R]` flag, and even specificy what kind of redirect it is (eg. `[R=301]` for a permanent redirect).
Addtionally do you have way more control about when and how to handle incomming and outgoing requests by using `RewriteCond`. This will enable using query strings, user agents and IP addresses to define when the redirect should happen.

So if possible, try to use `mod_rewrite`, but `mod_alias` can be used as well if needed.

### NGINX
Unlike Apache it's not possible to have an .htaccess file in your directory to set up redirects, but is it required to set them up in the config file instead.

```nginx
location = /old {
  # 301 Permanent redirect:
  return 301 $scheme://example.com/new

  # 308 Permanent redirect:
  return 308 $scheme://example.com/new


  # 302 Temporary redirect:
  return 302 $scheme://example.com/new

  # 307 Temporary redirect:
  return 307 $scheme://example.com/new
}
```

Blog: Technical SEO

How to use Core Web Vitals & Google Pagespeed Insights

Definitive Guide to Redirects