diff --git a/website/src/pages/index.mdx b/website/src/pages/index.mdx
index 7e6248b..f0ed07a 100644
--- a/website/src/pages/index.mdx
+++ b/website/src/pages/index.mdx
@@ -402,6 +402,28 @@ const x: Array<string> = ['foo', 'bar'];
 const y: ReadonlyArray<string> = ['foo', 'bar'];
 ```
 
+### Type Imports and Exports
+
+TypeScript allows specifying a `type` keyword on imports to indicate that the export exists only in the type system, not at runtime.
+
+Type imports must always be separated <Rule href="https://typescript-eslint.io/rules/consistent-type-imports/" />:
+
+- Tree Shaking and Dead Code Elimination: If you use `import` for types instead of `import type`, the bundler might include the imported module in the bundle unnecessarily, increasing the size. Separating imports ensures that only necessary runtime code is included.
+- Minimizing Dependencies: Some modules may contain both runtime and type definitions. Mixing type imports with runtime imports might lead to accidental inclusion of unnecessary runtime code.
+- Improves code clarity by making the distinction between runtime dependencies and type-only imports explicit.
+
+```ts
+// ❌ Avoid using `import` for both runtime and type
+import { MyClass } from 'some-library';
+
+// Even if MyClass is only a type, the entire module might be included in the bundle.
+
+// ✅ Use `import type`
+import type { MyClass } from 'some-library';
+
+// This ensures only the type is imported and no runtime code from "some-library" ends up in the bundle.
+```
+
 ### Services
 
 Documentation becomes outdated the moment it's written, and worse than no documentation is wrong documentation. The same applies to types when describing the modules your app interacts with, such as APIs, messaging systems, databases etc.