diff --git a/windows-apps-src/debug-test-perf/optimize-gridview-and-listview.md b/windows-apps-src/debug-test-perf/optimize-gridview-and-listview.md
index 9ae48b203e..f2212013c7 100644
--- a/windows-apps-src/debug-test-perf/optimize-gridview-and-listview.md
+++ b/windows-apps-src/debug-test-perf/optimize-gridview-and-listview.md
@@ -237,7 +237,7 @@ The general strategy for the [**ContainerContentChanging**](/uwp/api/windows.ui.
     }
     ```
 
-4.  If you run the app now and pan/scroll quickly through the grid view then you'll see the same behavior as for as for **x:Phase**.
+4.  If you run the app now and pan/scroll quickly through the grid view then you'll see the same behavior as for **x:Phase**.
 
 ## Container-recycling with heterogeneous collections
 
@@ -315,4 +315,4 @@ When recycling an item (**ListViewItem**/**GridViewItem**), the framework must d
 
 When there is an uneven distribution of items that use different item templates then new item templates will likely need to be created during panning, and this negates many of the gains provided by virtualization. Additionally, an item template selector only considers five possible candidates when evaluating whether a particular container can be reused for the current data item. So you should carefully consider whether your data is appropriate for use with an item template selector before using one in your app. If your collection is mostly homogeneous then the selector is returning the same type most (possibly all) of the time. Just be aware of the price you're paying for the rare exceptions to that homegeneity, and consider whether using [**ChoosingItemContainer**](/uwp/api/windows.ui.xaml.controls.listviewbase.choosingitemcontainer) (or two items controls) is preferable.
 
- 
\ No newline at end of file
+