Client-side performance testing

[ycombinator]

• Browser rendering time
• Requests being made to server, etc., can we reduce them?
• Page size
• Google Page Speed recommendations
• YSlow 2.0

[rdodev]

Google PageSpeed reports the following:

• Mobile Experience 64/100 (Fail):
  • too many calls for external CSS files
  • rendering-blocking js
  • recommendations:
  • inline rendering-blocking CSS instead of external files
  • minify external css files
  • inline blocking js instead of loading from external sources
  • tracking/analytics code causing issues.
• Desktop Experience 87/100:
  • same recommendation as above, but they aren't as important and are "optimizations" not as urgent.

I'm still doing other assessments. Will report later.

[rdodev]

Unfortunately, YSlow2 (desktop) scores have actually gone down from last time I ran them (used to be at or above 90/100), now shows 82/100 with the following notable issues:

• Grade C on HTTP requests: too many requests for external scripts (9)
• Grade F on CDN: there are 8 assets (216.6K GZip in size) that should be CDN'd
• Grade F on expire headers
• Grade B on DNS lookups: assets are spread through several different domains requiring several DNS lookups.
• Grade D on entity tags: we should add etags to our assets.
• Grade F on cookie-free domains: There are 11 components that are not cookie-free.

[kenperkins]

• We can't do much more with CSS other than what I did in #506, there's only 1 CSS file, which makes a single CSS import to google web-fonts
• We also can't really control the external scripts:
  • highlight.min.js (highlighting)
  • eluminate.js (not sure, @jnoller?)
  • 90378974.js (same host as eluminate.js)
  • cookie-id.js (dc.rackspace.com?)
  • rules_90378974.js
  • conversion.js (google ad services)
  • ga.js (google analytics)

[rdodev]

As per conversation with Ken, our priority will be finding a way to push stuff to CDN as that would give us the highest bang for our buck, at the moment. My proposal for injecting CSS into the html wasn't counting on the fact that we use css libs that would make html substantially bigger than it needs to be. We also agreed there's not much we can do about external-loading JS since it's mostly tracking/analytics that's "outside our control". Our page will still score low for mobile users, but w/o substantial engineering time, it's not likely we will be able to up mobile score by all that much, so we're tabling that as a long-term type of thing.

[ycombinator]

Moving https://github.com/rackerlabs/developer.rackspace.com/issues/477 out of Backlog into Must Haves list per @rdodev's comment above.

[rdodev]

I don't think there's a tool to easily cross-check which css rules we use in our html? If there is such tool, we could have 87% of the CSS payload:

1253 rules (87%) of CSS not used by the current page.
main-2c91613a80c39c3d97c3cea1537f4e57.css: 87% is not used by the current page.

[rdodev]

Here's a screen capture of the render-clocking scripts, for the record only since we know we can't really get rid of those (specially the analytics/tracking ones).

[kenperkins]

@rdodev let me see if I can prune out some bootstrap.

[ycombinator]

We agreed that this is not a blocker for launch and @kenperkins is busy with #513 right now so moving this to the Backlog.