close to 500kb of resources required to load

[shane-tomlinson]

We are starting to suffer from bloat, which isn't great when loading on a 3G or Edge connection.

484kb

[zaach]

@vladikoff is looking into webpack.

[shane-tomlinson]

@vladikoff is looking into webpack.

Awesome, I was thinking yesterday that something like that must exist by now.

[shane-tomlinson]

FWIW, after gzip is enabled, ~200KB is transferred across the wire. We still suffer from the number of requests and the latency introduced by each.

[ncalexan]

I am worried about the initial load time if we use fxa-content-server in Firefox for iOS. @shane-tomlinson suggested that some of the JavaScript code could be loaded while the user is completing the form. In particular, he suggested that the crypto bits (jwcrypto) could be fetched and parsed asynchronously. Can somebody estimate feasibility?

[ckarlof]

I am worried about the initial load time if we use fxa-content-server in Firefox for iOS.

Before we start optimizing:

• What is the current load time in different environments and on different iOS devices?
• What is the target load time, and is there any context around that number?

[ncalexan]

On Mon, Jan 26, 2015 at 10:47 AM, Chris Karlof notifications@github.com
wrote:

I am worried about the initial load time if we use fxa-content-server in
Firefox for iOS.

Before we start optimizing:

• What is the current load time in different environments and on
  different iOS devices?

Mozilla's first rule: any discussion can be derailed by asking for data.
In this case, I think it's somewhat relevant. I propose to run the
simulator with the Mac OS X "Network Link Conditioner" set to a few
relevant settings and report back with some of that data. I don't think
this is very representative, but it's very difficult to collect this data.
I see 4-10 second "real first paint" times on YVR office wifi and an iPad 3
mini. (By "real first paint" I mean after XHR localization has finished.)

• What is the target load time, and is there any context around that
  number?

Target load time is 0 seconds, since that's what we'd get with a native UI
implementation :)

[ckarlof]

Target load time is 0 seconds, since that's what we'd get with a native UI

This isn't a useful number, because we can't achieve that. I want to know what load time is minimally acceptable in your context.

I'm not trying to derail the conversation. I want you to use the Web flow. Optimizing the flow is work, and I'm hesitant to embark on a vague optimization effort when there is a lack of clarity around how much optimization is required for it to be a contender. The outcome I'm trying to avoid is @shane-tomlinson spending two weeks on optimization and feeling good about it, and you coming back and saying "Pretty good, but it's still not good enough".

There may also be some cheap wins possible here, like priming the Web cache with a background load, or preemptively loading the page in the background when the user is close a sign-in.

@shane-tomlinson, do you have any thoughts on wins on our side we can do fairly easily?

[ncalexan]

On Mon, Jan 26, 2015 at 11:38 AM, Chris Karlof notifications@github.com
wrote:

Target load time is 0 seconds, since that's what we'd get with a native UI

This isn't a useful number, because we can't achieve that. I want to know
what load time is minimally acceptable in your context.

I'm not trying to derail the conversation. I want you to use the Web flow.
Optimizing the flow is work, and I'm hesitant to embark on a vague
optimization effort when there is a lack of clarity around how much
optimization is required for it to be a contender. The outcome I'm trying
to avoid is @shane-tomlinson https://github.com/shane-tomlinson
spending two weeks on optimization and feeling good about it, and you
coming back and saying "Pretty good, but it's still not good enough".

There may also be some cheap wins possible here, like priming the Web
cache with a background load, or preemptively loading the page in the
background when the user is close a sign-in.

@shane-tomlinson https://github.com/shane-tomlinson, do you have any
thoughts on wins on our side we can do fairly easily?

This is what I want to know too. I don't want to embark on some
optimization re-architecture for the hell of it, but I don't have any way
to say what is "minimally acceptable". Most folks will interact with the
fxa-content-server exactly once, and in that context I honestly expect 5
seconds of load time is totally reasonable; but I've implemented it, and 5
seconds without feedback feels like an eternity. It's clear after doing
the flow even once that we need to first show an interstitial and only show
the sign in page when it's actually loaded [1]. In the end, this isn't
about the actual number of seconds until the page renders, it's about the
perceived snappiness of the process. Can we make it feel responsive enough
with the interstitial and subsequent transition animations?

I'm not trying to allocate work here, I just want to understand what can be
done. I tried to bring this up on the list specifically so it wasn't
framed as a feature request. Can somebody just tell me -- sketch for me --
what the technical possibilities are, so I can have a decent conversation
with our UX team?

[1] Desktop completely ignores this and we're just lucky most Desktop
devices render quickly and have fast connections. Desktop also doesn't do
anything reasonable when the content server can't be reached at all.

[ckarlof]

@johngruen will provide some thoughts on changes to make the loading experience appear less slow.

[pdehaan]

Probably not helpful, but I saw this the other day and it sounded interesting:
https://medium.com/@karimaliz/basket-js-script-loader-that-caches-scripts-in-localstorage-544a93827a5 (and http://addyosmani.github.io/basket.js/).

Wouldn't help with the initial 500kb hit, but may make subsequent requests much faster if we cache the ~360KB of minified JavaScript in the user's local storage. (although they'd still have the 70KB of fonts and 30KB of CSS to load).

[ckarlof]

Dumb question: WTF are we still loading fonts for?
I thought it was to have consistency with the font on FxOS. Anyone want to champion that?

[pdehaan]

I vote for Comic Neue: http://comicneue.com/
PR incoming!

[shane-tomlinson]

@ckarlof - @zaach and I proposed the same thing here. @ryanfeeley ixnayed the idea.

[ryanfeeley]

You can't precisely design a modern web UI without controlling the fonts. At a minimum, line heights vary by font varying vertical text alignment inside boxes and buttons. That said, Firefox OS likely already has Fira Sans installed, so maybe there is a way to avoid downloading it there.

[vladikoff]

From mtg:

Let's look at our loading times and go from there: #2958