diff --git a/.alexrc b/.alexrc
index b8f06d37fd66..6c510021a81b 100644
--- a/.alexrc
+++ b/.alexrc
@@ -17,6 +17,8 @@
     "fire",
     "remains",
     "jade",
-    "failed"
+    "failed",
+    "white",
+    "colors"
   ]
-}
\ No newline at end of file
+}
diff --git a/content/comparison.md b/content/comparison.md
index ab71fc71fa11..a48fdde66471 100644
--- a/content/comparison.md
+++ b/content/comparison.md
@@ -57,4 +57,4 @@ X is the length of the path string
 
 It's important to note some key differences between _loading_ and _bundling_ modules. A tool like [SystemJS](https://github.com/systemjs/systemjs), which can be found under the hood of [JSPM](http://jspm.io/), is used to load and transpile modules at runtime in the browser. This differs significantly from webpack, where modules are transpiled (through "loaders") and bundled before hitting the browser.
 
-Each method has it's pros and cons. Loading and transpiling modules at runtime can add a lot of overhead for larger sites and applications comprised of many modules. For this reason, SystemJS makes more sense for smaller projects where fewer modules are required. However, this may change a bit as [HTTP/2](https://http2.github.io/) will improve the speed at which files can be transferred from server to client. Note that HTTP/2 doesn't change anything about _transpiling_ modules, which will always take longer when done client-side.
+Each method has it's advantages and disadvantages. Loading and transpiling modules at runtime can add a lot of overhead for larger sites and applications comprised of many modules. For this reason, SystemJS makes more sense for smaller projects where fewer modules are required. However, this may change a bit as [HTTP/2](https://http2.github.io/) will improve the speed at which files can be transferred from server to client. Note that HTTP/2 doesn't change anything about _transpiling_ modules, which will always take longer when done client-side.
diff --git a/content/guides/code-splitting.md b/content/guides/code-splitting.md
index dc0793ec5bc0..32e8ce1d2826 100644
--- a/content/guides/code-splitting.md
+++ b/content/guides/code-splitting.md
@@ -69,15 +69,15 @@ module.exports = {
     index: './src/index.js',
     another: './src/another-module.js'
   },
-  output: {
-    filename: '[name].bundle.js',
-    path: path.resolve(__dirname, 'dist')
-  },
   plugins: [
     new HTMLWebpackPlugin({
       title: 'Code Splitting'
     })
-  ]
+  ],
+  output: {
+    filename: '[name].bundle.js',
+    path: path.resolve(__dirname, 'dist')
+  }
 };
 ```
 
diff --git a/content/guides/lazy-loading.md b/content/guides/lazy-loading.md
index 485ee02a16a6..d28d76b867db 100644
--- a/content/guides/lazy-loading.md
+++ b/content/guides/lazy-loading.md
@@ -12,7 +12,7 @@ related:
 
 T> This guide is a small follow-up to [Code Splitting](/guides/code-splitting). If you have not yet read through that guide, please do so now.
 
-Lazy, or "on demand", loading is a great way to optimize your site or application. This practice essentially boils down to splitting your code at logical breakpoints, and then loading it once the user has done something that requires, or will require, a new block of code. This speeds up the initial load of the application and makes the lightens its overall weight as some blocks may never even be loaded.
+Lazy, or "on demand", loading is a great way to optimize your site or application. This practice essentially involves splitting your code at logical breakpoints, and then loading it once the user has done something that requires, or will require, a new block of code. This speeds up the initial load of the application and makes the lightens its overall weight as some blocks may never even be loaded.
 
 
 ## Example
@@ -67,7 +67,7 @@ __src/index.js__
 +     var print = module.default;
 +
 +     print();
-+   })
++   });
 
     return element;
   }