
<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
}
```

Definitive Guide to Redirects

<div class="font-semibold">This snippet allows you to make (almost) any header sticky on the page which hides itself when you scroll down, but pops-up again when you scroll up. And as a bonus a step-by-step guide on how to implement this in Oxygen Builder.</div>

---
It’s simple, yet a very fancy, way to prevent your header taking up space which can be used for displaying your content. This snippet contains a small piece of Javascript and a couple of lines of CSS, and in return you’ll get the following:


<p class="codepen" data-height="500" data-theme-id="dark" data-default-tab="result" data-slug-hash="MWmLdKX" data-user="Grezvany13" style="height: 300px; box-sizing: border-box; display: flex; align-items: center; justify-content: center; border: 2px solid; margin: 1em 0; padding: 1em;">
  <span>See the Pen <a href="https://codepen.io/Grezvany13/pen/MWmLdKX">
  Sticky Header - Scroll Up Show</a> by Johan de Jong (<a href="https://codepen.io/Grezvany13">@Grezvany13</a>)
  on <a href="https://codepen.io">CodePen</a>.</span>
</p>
<script async defer src="https://cpwebassets.codepen.io/assets/embed/ei.js"></script>

If you look at the source of the above example it may look a lot to handle, so let’s break it down. And don’t worry about the HTML or LESS, the important parts are just a single class in the HTML and a couple of lines of (plain) CSS.

## HTML
This is the easiest part; add a single class to the element you want to make sticky! That’s it, no complex HTML structure or the need to redesign your website to have a simple script be able to do it’s work.
```html

<header class="jd-sticky">
</header>


<div class="jd-sticky">
</div>


<nav class="jd-sticky">
</nav>
```
Just add .jd-sticky to whatever element you want to have sticky, and continue the next steps to have it work.

## CSS
The second step is to add a class to the element you want to make sticky, which in this case is the header.
```css
/**
 * Sticky CSS
 */
/* add padding-top to match height of the header */
body {
    padding-top: 70px;
}
/* on mobile the header is twice as hight, and so should the padding be */
@media (max-width: 768px) {
    body {
        padding-top: 140px;
    }
}
/* make header fixed to the top */
.jd-sticky {
    position: fixed;
    top: 0;
    /* and a smooth transition, so it won't just pop in and out the screen */
    transition: top 700ms linear;
}
```
Two things are happening here; first we add a padding-top to the body, so there will always be some room for the header to be displayed. The reason is because of the second part of the CSS; we make the header stick to the top of the page with position:fixed, which puts the whole element over the rest of the content.
Of course you’ll need to change the padding (both for desktop and tablet/mobile) based on the size of your header element.

With just this small CSS snippet you will already have a sticky header, but we obviously want a bit more.

## Javascript
The last step is to add some javascript which will handle the showing and hiding of the header when scrolling up and down.
```javascript
/**
 * Sticky JS
 */
/* set the element you want to make sticky */
const headerElem = document.querySelector('.jd-sticky');
/* set the offset on which the hide effect has to wait */
const scrollOffset = 200;

/* DO NOT MODIFY BELOW */
/* get the current page position */
let prevScrollpos = window.pageYOffset;

/* monitor when the page is being scrolled */
window.addEventListener('scroll', () => {
    /* check if the scroll offset is passed */
    if (window.pageYOffset > scrollOffset) {
        /* get the new page position after scrolling */
        let currentScrollPos = window.pageYOffset;
        /* check the new page position with the old position */
        if (prevScrollpos > currentScrollPos) {
            /* if scrolling UP, show the sticky element */
            headerElem.style.top = '0';
        } else {
            /* if scrolling DOWN, hide the sticky element */
            headerElem.style.top = '-100%';
        }
        /* set the page position, so it can be checked the next time */
        prevScrollpos = currentScrollPos; 
    }
});
```
The Javascript is very simple, but very effective. It takes the element which needs to be affected, in this case .jd-sticky, and will change the top position depending on your scroll behavior.

And that’s all folks! Just a single class added to your HTML and a couple of lines of CSS and Javascript, and you’ll have easy sticky header with scroll effects.

## Oxygen
Since we at Jacht.digital use Oxygen Builder a lot, and know it can be a bit challenging to add custom styles and scripts, here a step-by-step guide on how to do it yourself.

It doesn’t matter what your current website looks like, so in this example we simply took one of the default presets in Oxygen Builder. It is important that the whole block, in this case the header, can be selected as one.

<img src="https://jacht.digital/wp-content/uploads/sticky-oxygen-step0-1024x608.png.webp" loading="lazy" alt="Step 0" />

As with the implementation without Oxygen Builder, all you have to do now is add the .jd-sticky class to the header element. This can be done by selecting the element from the Structure list and add the classname manually in the right sidebar. Make sure you didn’t select a breakpoint or state, otherwise it may only work in those specific cases.

<img src="https://jacht.digital/wp-content/uploads/sticky-oxygen-step1.png.webp" loading="lazy" alt="Step 1" />

Now it’s time for the CSS and Javascript, which can be added easily with a codeblock. In this example we added the codeblock component “somewhere” in the header element, so it’s easier to find back. However as long as it’s always available when you show the header (so anywhere in any template or reusable-part which is shown together with the header) you’ll be fine.

In here we add the CSS in ‘Advanced’ -> ‘CSS’ and make the changes when needed.

<img src="https://jacht.digital/wp-content/uploads/sticky-oxygen-step2-1024x608.png.webp" loading="lazy alt="Step 2" />

And we add the Javascript in ‘Advanced’ -> ‘JavaScript’.

<img src="https://jacht.digital/wp-content/uploads/sticky-oxygen-step3-1024x608.png.webp" loading="lazy" alt="Step 3" />

Keep in mind that Oxygen Builder is not very smart when it comes to loading javascripts in the editor, so if you just copy&paste the code it will most likely show an error message that variables already exist.
To fix this all you have to do is place the code inside the following block:

```javascript
(function() {
    // rest of code
})();
```

Now save the template and you’re done!

<figure><video controls="" src="https://jacht.digital/wp-content/uploads/sticky-oxygen-video.webm"></video></figure>

Sticky header with show/hide on scroll


<div class="font-semibold">In a world where websites need to be fast and everyone shouts to optimize everything, there is one thing which is always mentioned: "cache". But what is it, how does it work and which layers of cache are there?</div>

---
## What is Cache
> A cache is a hardware or software component that stores data so that future requests for that data can be served faster.
> 
> *source: [Wikipedia](https://en.wikipedia.org/wiki/Cache_(computing))*

Most websites and web applications need to execute code to be able to generate the HTML required for the browser to display. Depending on the code this can be very slow, especially when a lot of calculations are needed.

For example a simple WordPress website will run several queries to a database, loop over the results, put everything in their correct structure and markup, and only then it will send all the data (at once) back to the browser.

With proper caching in place the above will only happen once, for all visitors, until it needs to be refreshed. And not only will it make responses much quicker for the visitors, but it will also reduce the stress on the server, which in result will make it faster in case some content is not cached yet.

Of course the above image is a simplified view on how cache works and can be in multiple layers, even at the same time. It can be handled at the server, at the client and in between. Usually complimenting each other, but sometimes also working against each other.

## How does it work
Don’t worry, this won’t be a very technical explanation on how it all works. That would require a full post per cache layer. However in essence they all work the same.

When a request is made by the browser (entering the URL or clicking a link) this will go towards the server. A cache system will catch this request and check if it already knows what should be returned as a response. If it does, it will stop the normal request and send the data it has directly back to the browser.

In case it has no cached response it will wait till the server has handled the request and catch the response while it’s sent back to the browser. At this moment it will store both the request and the response in its own storage. This way, the next time the exact same request comes by it can send back the response which it has stored.

### But what happens when the response isn’t valid anymore?
There are many reasons why a cached response is not correct anymore and needs to be removed or replaced by an updated version.
Most cache systems have a maximum lifetime or  for data to be valid before it will delete it and wait for an updated response. This can be as short as milliseconds up to years if needed or wanted.

In addition to a maximum lifetime, do most cache systems have the option to “purge” their cache, either per item or everything at the same time. And some systems even allow the client, like a browser, to request uncached responses or only when the creation time is within a specific timeframe.

## The many methods and layers of cache
Now that we know what cache is and how it works, let’s look at “a couple” of methods which are commonly used in PHP web development.

### Server-Level Caching
#### PHP Opcode Caching
Whenever a piece of PHP code is executed the server needs to read all the files from the hard drive and combine them before it can read and run the code. With Opcode Caching the code from the scripts is stored in the memory of the server for quicker access since reading data from memory is a lot faster than from a drive.
Some well known engines are OPcache, APC, and Xcache.

#### Object Cache
Access to the database can be slow, especially with more complex queries. With Object Cache the queries, and their results, are stored in memory or a seperate location to return the data even faster.

Redis and Memcached are common systems used for this.

#### Page Cache
The name says it all, it stores the complete (HTML) page into a cache so it returns everything at once, without the need of compiling the code or doing (heavy) database queries.
For example Nginx and Redis can do this.

#### Web Server Accelerator
Web server accelerator, sometimes referred to as reverse proxies or Application Delivery Controllers, does the same as Page Caching except it works before hitting the server software itself. This means even less to do for the server and thus more resources available for other requests.
Varnish is one of the most common tools.

#### Content Delivery Network (CDN)
A CDN works differently from the above types of caching, because it’s (usually) not handled by the same server as where the website/application is running.

By offloading assets like images, stylesheets and javascript files to a completely different server optimized for serving those files it will reduce the amount of requests made to the server. In some cases it’s even possible to access files which are used across multiple websites, making browser cache even more optimal.

### Application-Level Caching
#### Browser Caching
By setting a minimum (or maximum) lifetime to an asset on the server the browser will not only download the file, but also store it locally. This way, the next time the same file is required it will simply take the stored version instead of downloading it again from the server.

All browsers do this by default, but it does require proper settings at the server (or CDN).

### Other types?
#### Cache prefetching
Not really a type of caching, but it certainly speeds up the process of requesting and receiving data. By requesting data before it’s actually needed, at a time where it doesn’t hurt performance, the moment the data is needed it will already be present and the browser doesn’t need to wait for it.

It’s possible to do 2 types of prefetching: **DNS Prefetch** and **Content Prefetch.**
With DNS Prefetch only the DNS records are retrieved, which means the IP address and location (through the maze of servers all around the world) are gathered and stored. Normally this can take some time, so doing this beforehand will make loading files from that specific location (usually an external location) a bit faster.

Content Prefetch will get files and assets before required, and places it in the browser cache for quicker access in the future. In some cases even full pages are being loaded, making the transition from the current to the next page almost instant.

## So what do I need?
In short; all of them. Each cache system works differently but can work together with other levels without a problem. Just keep in mind that some systems require complex configurations specifically for your website or application. However a lot has been configured already when using a good hosting provider, plugins/extensions for your CMS/framework and standard setups.

One thing to keep in mind is the complexity of your project and how dynamic it has to be. Caching is most useful for static content, especially Page Cache and CDN’s. When you have a lot of dynamic content (like  a search page with a lot of different filters) you’ll be better off with more high level caching like Object Cache

Blog

How to use Core Web Vitals & Google Pagespeed Insights

Definitive Guide to Redirects

Sticky header with show/hide on scroll

Understanding Cache