initial commitHEADmaster

1 files changed, 35 insertions, 0 deletions

diff --git a/sifterapp/complete/webpagetest-notes.txt b/sifterapp/complete/webpagetest-notes.txt
new file mode 100644
index 0000000..0dbbe05
--- /dev/null
+++ b/sifterapp/complete/webpagetest-notes.txt
@@ -0,0 +1,35 @@
+
+> Performance audit...
+> 
+> 0. Scope: SifterApp.com - Basically everything on our marketing site (not
+> on a subdomain) is static content created by Jekyll and served straight
+> through Nginx.
+> 
+> 1. Context: Our marketing site used to live within the application
+> codebase, and so Rails and Capistrano handled most of the asset
+> optimization and serving. Now that it's all Jekyll, we're just tossing
+> files up via Nginx with little consideration for performance. We need to
+> fix that, especially for mobile. (And eventually, I even see the picture
+> element as being part of that.)
+> 
+> 2. Front-end/back-end, nothing's off limits. I expect that we'll have room
+> for improvement in both areas. Just looking at the scores from the tests
+> and a cursory glance at the resulting advice, we'll need to make some
+> changes with all of it. The big thing is that I just don't have the
+> bandwidth to research it and understand the best solutions for us.
+> 
+> 3. Structure of article. I think it should focus primarily on the tools and
+> the information that they provide and only use Sifter as examples. That way
+> it's about the tools instead of Sifter. My only fear is that if we're
+> already optimized in some areas, there won't be as much to share about what
+> the tools help you find. That is, our performance may suck but not bad
+> enough to show the full capabilities of the tools.
+> 
+> I know there are countless tools/techniques that make sense, and I see them
+> in two distinct categories. 1.) Tools that help you see your problems. 2.)
+> Tools that help you fix your problems. I'd like to see us focus on the
+> tools that help you see the problems to focus on the "bug" finding aspect.
+> For each of the problems, I think we should link to relevant tools or
+> tutorials that can help solve the problem, but we should leave the
+> researching and choosing of those tools to the reader.
+>