blob: 0dbbe052e8ffd749c87810f92c7dddb2d02536f6 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
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.
>
|
