Apply suggestions from code review

Co-authored-by: Nicolò Ribaudo <[email protected]>

Author: Jack-Works

src/content/configuration/experiments.mdx

@@ -214,13 +214,13 @@ Defaults to the value of [`futureDefaults`](#experimentsfuturedefaults).
 
 Enable support of the tc39 proposal [Deferring Module Evaluation](https://github.com/tc39/proposal-defer-import-eval).
 This allows deferring the evaluation of a module until its first use.
-This is useful when using dynamic `import()` is problematic.
+This is useful to synchronously defer code execution when it's not possible to use `import()` due to its asynchronous nature.
 
 - Type: `boolean`
 
 This feature requires the runtime environment to have [`Proxy`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) (ES6) support.
 
-Enable the following syntaxes:
+Enables the following syntaxes:
 
 ```js
 import defer * as module from 'module-name';
@@ -235,9 +235,9 @@ export function f() {
 
 #### Limitations of magic comments (`/* webpackDefer: true */`)
 
-It's suggested to put the magic comment after the `from` keyword, other positions may work, but have not been tested.
+It's suggested to put the magic comment after the `from` keyword. Other positions may work, but have not been tested.
 
-Putting the magic comment after the `import` keyword is known to be broken, it will break the filesystem cache.
+Putting the magic comment after the `import` keyword is incompatible with the filesystem cache.
 
 ```js
 import /* webpackDefer: true */ * as ns from '...'; // known broken

src/content/guides/lazy-loading.mdx

@@ -102,11 +102,11 @@ index.bundle.js     548 kB       1  [emitted]  [big]  index
 
 ## Defer Import Example
 
-W> This section does not lazy "load" a module, but lazy "evaluate" a module. This means that the module is still downloaded and parsed, but its evaluation is lazy.
+W> This feature does not lazily "load" a module, but it lazily "evaluates" a module. This means that the module is still downloaded and parsed, but its evaluation is lazy.
 
 In some cases, it might be annoying or hard to convert all uses of a module to asynchronous, since it enforces the unnecessary asyncification of all functions, without providing the ability to only defer the synchronous evaluation work.
 
-The tc39 proposal [Deferring Module Evaluation](https://github.com/tc39/proposal-defer-import-eval) is to solve this problem.
+The TC39 proposal [Deferring Module Evaluation](https://github.com/tc39/proposal-defer-import-eval) is to solve this problem.
 
 > The proposal is to have a new syntactical import form which will only ever return a namespace exotic object. When used, the module and its dependencies would not be executed, but would be fully loaded to the point of being execution-ready before the module graph is considered loaded.
 >