diff --git a/performance/font-loading.md b/performance/font-loading.md
index 82c3273..0573743 100644
--- a/performance/font-loading.md
+++ b/performance/font-loading.md
@@ -9,7 +9,7 @@
   - [font-display CSS](#font-display-css)
   - [Loading fonts with JavaScript](#loading-fonts-with-javascript)
   - [Preloading webfonts](#preloading-webfonts)
-  - [Self host webfonts if possible](#self-host-webfonts-if-possible)
+  - [Self host webfonts](#self-host-webfonts)
 
 ## When to use webfonts
 
@@ -30,12 +30,12 @@ As a Frontend Developer, it's your role to provide technical guidance and feedba
 
 We do not prescribe a particular implementation. Each team should determine which implementation is best suited for them. However, before selecting an implementation a team should be mindful of our working practices such as:
 
-- [Graded Browser Support](https://github.com/springernature/frontend-playbook/blob/main/practices/graded-browser-support.md)
+- [Graded Browser Support](../practices/graded-browser-support.md)
   - Is the implementation supported by all "enhanced" browsers? If not, is there a good justification for selecting it anyway?
   - Does the implementation work in conjunction with the Cut The Mustard technique?
-- [Progressive Enhancement](https://github.com/springernature/frontend-playbook/blob/main/practices/progressive-enhancement.md)
+- [Progressive Enhancement](../practices/progressive-enhancement.md)
   - This is not meant to force you to choose a non-js implementation, but rather for you to ensure you consider what will happen for users in varying circumstances from the beginning.
-- [Our Performance Goals](https://github.com/springernature/frontend-playbook/blob/main/performance/performance-checklist.md)
+- [Our Performance Goals](../performance/performance-checklist.md)
   - What impact will the implementation have on the page performance of your site?
 
 ## Quick tips
@@ -76,10 +76,10 @@ If you have to load a font the conventional way using a `<link>` then consider u
 
 ### Self host webfonts
 
-Any webfonts you use must be self-hosted - avoid using a font-hosting service.
+[As any other static asset](../practices/managing-static-assets.md), any webfonts you use [MUST](../README.md#key-words) be self-hosted - avoid using a font-hosting service.
 
-Every major browser now implements HTTP cache partitioning in order to prevent leaking of the users' browser history, and avoid cross-site tracking and cross-site search attacks. This means that there's no performance benefit from using an external service to host our webfonts.
+As major browsers now implement HTTP cache partitioning to prevent leaking of the users' browser history and mitigate cross-site tracking and search attacks, there's no performance benefit from using an external service to host our webfonts.
 
-Using an external font-hosting service can actually worsen performance in important markets like China, as opening a connection to a new host can sometimes be very slow, or even fail completely, due to the filtering done by the Great Firewall.
+Using an external font-hosting service can negatively impact performance in markets like China, as opening a connection to a new host can sometimes be very slow, or even fail completely, due to the data filtering mechanism of the Great Firewall.
 
-But most importantly, using external font-hosting services we risk passing personally identifiable information (PII) from your users to those font-hosting services, increasing the risk of litigation.
+When self hosting the fonts is not possible due to for example licensing issues, you MUST ensure data protection policies are followed and user consent is obtained before connecting to remote origins. This practice prevents unauthorised disclosure of personally identifiable information (PII) to external services, reducing litigation risks.