Correct misspelling and punctuation errors

src/content/guides/build-performance.md

@@ -14,7 +14,7 @@ This guide contains some useful tips for improving build/compilation performance
 
 ## General
 
-The following best practices should help whether or not you are in [development](/guides/development) or building for [production](/guides/production).
+The following best practices should help, whether you're running build scripts in [development](/guides/development) or [production](/guides/production).
 
 
 ### Stay Up to Date
@@ -23,7 +23,7 @@ Use the latest webpack version. We are always making performance improvements. T
 
 [![latest webpack version](https://img.shields.io/npm/v/webpack.svg?label=webpack&style=flat-square&maxAge=3600)](https://github.com/webpack/webpack/releases)
 
-Staying up to date with __Node.js__  can also help with performance. On top of this, keeping your package manager (e.g. `npm` or `yarn`) up to date can also help. Newer versions create more efficient module trees and increase resolving speed.
+Staying up-to-date with __Node.js__  can also help with performance. On top of this, keeping your package manager (e.g. `npm` or `yarn`) up-to-date can also help. Newer versions create more efficient module trees and increase resolving speed.
 
 
 ### Loaders
@@ -64,14 +64,14 @@ module.exports = {
 
 ### Bootstrap
 
-Each additional loader/plugin has a bootup time. Try to use as few different tools as possible.
+Each additional loader/plugin has a bootup time. Try to use as few tools as possible.
 
 
 ### Resolving
 
-The following steps can increase the speed of resolving:
+The following steps can increase resolving speed:
 
-- Minimize the number of items in `resolve.modules`, `resolve.extensions`, `resolve.mainFiles`, `resolve.descriptionFiles` as they increase the number of filesystem calls.
+- Minimize the number of items in `resolve.modules`, `resolve.extensions`, `resolve.mainFiles`, `resolve.descriptionFiles`, as they increase the number of filesystem calls.
 - Set `resolve.symlinks: false` if you don't use symlinks (e.g. `npm link` or `yarn link`).
 - Set `resolve.cacheWithContext: false` if you use custom resolving plugins, that are not context specific.
 
@@ -96,7 +96,7 @@ Decrease the total size of the compilation to increase build performance. Try to
 
 The `thread-loader` can be used to offload expensive loaders to a worker pool.
 
-W> Don't use too many workers as there is a boot overhead for the Node.js runtime and the loader. Minimize the module transfers between worker and main process. IPC is expensive.
+W> Don't use too many workers, as there is a boot overhead for the Node.js runtime and the loader. Minimize the module transfers between worker and main process. IPC is expensive.
 
 
 ### Persistent cache
@@ -118,9 +118,9 @@ The following steps are especially useful in _development_.
 
 ### Incremental Builds
 
-Use webpack's watch mode. Don't use other tools to watch your files and invoke webpack. The built in watch mode will keep track of timestamps and passes this information to the compilation for cache invalidation.
+Use webpack's watch mode. Don't use other tools to watch your files and invoke webpack. The built-in watch mode will keep track of timestamps and passes this information to the compilation for cache invalidation.
 
-In some setups watching falls back to polling mode. With many watched files this can cause a lot of CPU load. In these cases you can increase the polling interval with `watchOptions.poll`.
+In some setups, watching falls back to polling mode. With many watched files, this can cause a lot of CPU load. In these cases, you can increase the polling interval with `watchOptions.poll`.
 
 
 ### Compile in Memory
@@ -143,12 +143,12 @@ Be aware of the performance differences of the different `devtool` settings.
 - The `cheap-source-map` variants are more performant, if you can live with the slightly worse mapping quality.
 - Use a `eval-source-map` variant for incremental builds.
 
-=> In most cases `cheap-module-eval-source-map` is the best option.
+=> In most cases, `cheap-module-eval-source-map` is the best option.
 
 
 ### Avoid Production Specific Tooling
 
-Certain utilities, plugins and loader only make sense when building for production. For example, it usually doesn't make sense to minify and mangle your code with the `UglifyJsPlugin` while in development. These tools should typically be excluded in development:
+Certain utilities, plugins, and loaders only make sense when building for production. For example, it usually doesn't make sense to minify and mangle your code with the `UglifyJsPlugin` while in development. These tools should typically be excluded in development:
 
 - `UglifyJsPlugin`
 - `ExtractTextPlugin`
@@ -160,7 +160,7 @@ Certain utilities, plugins and loader only make sense when building for producti
 
 ### Minimal Entry Chunk
 
-webpack only emits updated chunks to the filesystem. For some configuration options (HMR, `[name]`/`[chunkhash]` in `output.chunkFilename`, `[hash]`) the entry chunk is invalidated in addition to the changed chunks.
+webpack only emits updated chunks to the filesystem. For some configuration options, (HMR, `[name]`/`[chunkhash]` in `output.chunkFilename`, `[hash]`) the entry chunk is invalidated in addition to the changed chunks.
 
 Make sure the entry chunk is cheap to emit by keeping it small. The following code block extracts a chunk containing only the runtime with _all other chunks as children_:
 
@@ -201,11 +201,11 @@ module.exports = {
 
 ### Node.js Version
 
-There has been a [performance regression](https://github.com/nodejs/node/issues/19769) in the latest stable versions of Node.js and its ES2015 `Map` and `Set` implementations. A fix has been merged in master, but a release has yet to be made. In the meantime, to get the most out of incremental build speeds, try to stick with version 8.9.x (problem exists between 8.9.10 - 9.11.1). webpack has moved to using those ES2015 data structures liberally, and it will improve the initial build times as well.
+There has been a [performance regression](https://github.com/nodejs/node/issues/19769) in the latest stable versions of Node.js and its ES2015 `Map` and `Set` implementations. A fix has been merged into master, but a release has yet to be made. In the meantime, to get the most out of incremental build speeds, try to stick with version 8.9.x (the problem exists between 8.9.10 - 9.11.1). webpack has moved to using those ES2015 data structures liberally, and it will improve the initial build times as well.
 
 ### TypeScript Loader
 
-Recently, `ts-loader` has started to consume the internal TypeScript watch mode APIs which dramatically decreases the number of modules to be rebuilt on each iteration. This `experimentalWatchApi` shares the same logic as the normal TypeScript watch mode itself and is quite stable for development use. Turn on `transpileOnly` as well for truly fast incremental builds.
+Recently, `ts-loader` has started to consume the internal TypeScript watch mode APIs which dramatically decreases the number of modules to be rebuilt on each iteration. This `experimentalWatchApi` shares the same logic as the normal TypeScript watch mode itself and is quite stable for development use. Turn on `transpileOnly`, as well, for even faster incremental builds.
 
 ```js
 module.exports = {
@@ -227,7 +227,7 @@ Note: the `ts-loader` documentation suggests the use of `cache-loader`, but this
 
 To gain typechecking again, use the [`ForkTsCheckerWebpackPlugin`](https://www.npmjs.com/package/fork-ts-checker-webpack-plugin).
 
-There is a [full example](https://github.com/TypeStrong/ts-loader/tree/master/examples/fast-incremental-builds) on the ts-loader github repository
+There is a [full example](https://github.com/TypeStrong/ts-loader/tree/master/examples/fast-incremental-builds) on the ts-loader github repository.
 
 ---
 
@@ -236,14 +236,14 @@ There is a [full example](https://github.com/TypeStrong/ts-loader/tree/master/ex
 
 The following steps are especially useful in _production_.
 
-W> __Don't sacrifice the quality of your application for small performance gains!__ Keep in mind that optimization quality is in most cases more important than build performance.
+W> __Don't sacrifice the quality of your application for small performance gains!__ Keep in mind that optimization quality is, in most cases, more important than build performance.
 
 
 ### Multiple Compilations
 
-When using multiple compilations the following tools can help:
+When using multiple compilations, the following tools can help:
 
-- [`parallel-webpack`](https://github.com/trivago/parallel-webpack): It allows to do compilation in a worker pool.
+- [`parallel-webpack`](https://github.com/trivago/parallel-webpack): It allows for compilation in a worker pool.
 - `cache-loader`: The cache can be shared between multiple compilations.
 
 
@@ -256,7 +256,7 @@ Source maps are really expensive. Do you really need them?
 
 ## Specific Tooling Issues
 
-The following tools have certain problems that can degrade build performance.
+The following tools have certain problems that can degrade build performance:
 
 
 ### Babel
@@ -266,8 +266,8 @@ The following tools have certain problems that can degrade build performance.
 
 ### TypeScript
 
-- Use the `fork-ts-checker-webpack-plugin` for type checking in a separate process.
-- Configure loaders to skip type checking.
+- Use the `fork-ts-checker-webpack-plugin` for typechecking in a separate process.
+- Configure loaders to skip typechecking.
 - Use the `ts-loader` in `happyPackMode: true` / `transpileOnly: true`.