Update UnderstandingTiming.md

docs/HyperlinkedInformation/UnderstandingTiming.md

@@ -4,20 +4,20 @@ Some notes on the "Timing" tab in `re-frame-trace`.
 
 Two reasons:
 
-1.  Accurately timing something in the browser is almost
+1.  Accurately timing something in the browser is
     a fool's errand. One moment it takes 1ms and the next it 
     takes 10ms, and you’ll never know why. Noisy.
 
-    So, don't ever base decisions on one set of timings.
-    Click the "replay" button ([#115](https://github.com/Day8/re-frame-trace/issues/155)) a few times to see if you 
-    get stable numbers. 
+    So, don't ever draw conclusions from one set of timings.
+    Click the "replay" button ([#115](https://github.com/Day8/re-frame-trace/issues/155)) 
+    a few times to ensure the numbers are stable.
     
-2.  Don't freak out about any apparent slowness. Not just yet, anyway.
+2.  Don't freak out about any apparent slowness. Not initially, anyway.
 
     After all, you're running a dev build, right, not the 
     production build?  And I'm guessing you're also 
-    running a dev build of React? And even `re-frame-trace` itself will add 
-    its own drag too, what with all that creating and analysing of trace.
+    running a dev build of React? And `re-frame-trace`  will itself also add 
+    drag, what with all that creating and analysing of trace.
     
     So, run the production version of your app first, before 
     deciding you have a performance problem. Something what 
@@ -28,7 +28,7 @@ Two reasons:
     "parts" of an Epoch. Is most the time going in views, or 
     maybe one view in particular? Or in 
     one subscription, compared to the others?
-    And, even then, remember point 1 (above). 
+    And, even then, keep in mind point 1 (above). 
     
 ## Know Your Epoch Timeline