Spelling nits for `code-splitting.md`

Really enjoyed the newest code-splitting docs!

I caught a minor spelling error: `interuptive` -> `interruptive`. I decided to indulge the writer in myself, and chose to rephrase some things that I thought could be clearer.

That said, I recognize that many of the changes I'm making are subjective. More than happy to simply fix the typo, but I thought I'd submit this to see if others agree with my phrasing changes.

content/docs/code-splitting.md

@@ -44,7 +44,7 @@ console.log(add(16, 26)); // 42
 > 
 > Your bundles will end up looking a lot different than this.
 
-If you're using [Create React App](https://github.com/facebookincubator/create-react-app), [Next.js](https://github.com/zeit/next.js/), [Gatsby](https://www.gatsbyjs.org/), or a similar tool you will have a Webpack setup out of the box to bundle your
+If you're using [Create React App](https://github.com/facebookincubator/create-react-app), [Next.js](https://github.com/zeit/next.js/), [Gatsby](https://www.gatsbyjs.org/), or a similar tool, you will have a Webpack setup out of the box to bundle your
 app.
 
 If you aren't, you'll need to setup bundling yourself. For example, see the
@@ -59,17 +59,18 @@ if you are including large third-party libraries. You need to keep an eye on
 the code you are including in your bundle so that you don't accidentally make
 it so large that your app takes a long time to load.
 
-But if your app keeps growing, eventually you'll end up with a large bundle. So
-it's good to get ahead of the problem and start "splitting" your bundle.
-[Code-Splitting](https://webpack.js.org/guides/code-splitting/) is a feature
-of bundlers like Webpack and Browserify (via
+To avoid winding up with a large bundle, it's good to get ahead of the problem 
+and start "splitting" your bundle.
+ [Code-Splitting](https://webpack.js.org/guides/code-splitting/) is a feature
+supported by bundlers like Webpack and Browserify (via
 [factor-bundle](https://github.com/browserify/factor-bundle)) which can create
 multiple bundles that can be dynamically loaded at runtime.
 
 Code-splitting your app can help you "lazy-load" just the things that are
 currently needed by the user, which can dramatically improve the performance of
-your app. Overall you haven't reduced the amount of code in your app, but
-you've avoided loading code that the user may never need.
+your app. While you haven't reduced the overall amount of code in your app, 
+you've avoided loading code that the user may never need, and reduced the amount
+of code needed during the initial load.
 
 ## `import()`
 
@@ -96,7 +97,7 @@ import("./math").then(math => {
 > 
 > The dynamic `import()` syntax is a ECMAScript (JavaScript)
 > [proposal](https://github.com/tc39/proposal-dynamic-import) not currently
-> accepted into the language standard. It is expected to be accepted within the
+> part of the language standard. It is expected to be accepted within the
 > near future.
 
 When Webpack comes across this syntax, it automatically start code-splitting
@@ -107,16 +108,16 @@ out of the box in [Next.js](https://github.com/zeit/next.js/#dynamic-import).
 If you're setting up Webpack yourself, you'll probably want to read Webpack's
 [guide on code splitting](https://webpack.js.org/guides/code-splitting/). Your Webpack config should look vaguely [like this](https://gist.github.com/gaearon/ca6e803f5c604d37468b0091d9959269).
 
-When using [Babel](http://babeljs.io/) you'll need to make sure that Babel can
-parse the dynamic import syntax but is not transforming it. For that you will need [babel-plugin-syntax-dynamic-import](https://yarnpkg.com/en/package/babel-plugin-syntax-dynamic-import).
+When using [Babel](http://babeljs.io/), you'll need to make sure that Babel can
+parse the dynamic import syntax without transforming it. For that, you will need [babel-plugin-syntax-dynamic-import](https://yarnpkg.com/en/package/babel-plugin-syntax-dynamic-import).
 
 ## Libraries
 
 ### React Loadable
 
-[React Loadable](https://github.com/thejameskyle/react-loadable) provides you
-with a nice API for introducing code splitting into your app wherever you
-render a component.
+[React Loadable](https://github.com/thejameskyle/react-loadable) wraps
+dynamic imports in a nice, React-friendly API for introducing code 
+splitting into your app at a given component.
 
 **Before:**
 
@@ -148,14 +149,13 @@ React Loadable helps you create
 [error states](https://github.com/thejameskyle/react-loadable#loading-error-states),
 [timeouts](https://github.com/thejameskyle/react-loadable#timing-out-when-the-loader-is-taking-too-long),
 [preloading](https://github.com/thejameskyle/react-loadable#preloading), and
-more. It can even help you [server-side](https://github.com/thejameskyle/react-loadable#------------server-side-rendering)
-render an app with lots of code-splitting.
+more. It can even help you [server-side render](https://github.com/thejameskyle/react-loadable#------------server-side-rendering) an app with lots of code-splitting.
 
 ## Route-based code splitting
 
 Deciding where in your app to introduce code splitting can be a bit tricky. You
-want to make sure you choose places that will split bundles evenly, but not be
-terribly interuptive to the users of your app.
+want to make sure you choose places that will split bundles evenly, but won't
+disrupt the user experience.
 
 A good place is to start is with routes. Most people on the web are used to
 page transitions taking some amount of time to load. You also tend to be