In Japan, now more than 80% internet users enjoy broadband connection. I think it would be a good idea to optimize some of network settings with firefox-l10n.js, including: * content.notify.interval * network.http.max-connections * nglayout.initialpaint.delay
11 years ago
90% for Korea.
They are network-relating prefs and we need take care about including prefs like them but network environment is region dependent and ja/ko are used almost only in one contry (Japane/Korea). So, optimizing these prefs in firefox-l10n.js is reasonable we believe. Please give approval to change these prefs in firefox-l10n.js.
Some entries from Fasterfox "Optimized; within the RFC specs" mode: user_pref("network.http.max-connections", 40); user_pref("network.http.max-connections-per-server", 16); user_pref("network.http.max-persistent-connections-per-proxy", 12); user_pref("network.http.max-persistent-connections-per-server", 6); user_pref("nglayout.initialpaint.delay", 0);
The OECD is reporting that: * Denmark, the Netherlands, Switzerland, Korea and Norway and Iceland lead the OECD in broadband penetration, each with over 29 subscribers per 100 inhabitants. * Fiber connections account for 36% of all Japanese broadband subscriptions and 31% in Korea. http://www.oecd.org/document/54/0,3343,en_2649_33703_38690102_1_1_1_1,00.html
CCing Assignees and QA Contacts for da-DK, nl-NL and sv-SE. They might be interested in...
Summary: Optimize Firefox 3 network settings for broadband users (ja/ja-JP-mac) → Optimize Firefox 3 network settings for broadband users (ja/ja-JP-mac and perhaps other markets)
Do we ignore the mobile users?? e.g., PHS/H".
And I have a question. Can some office users allow this growing? E.g., 100 employer office might not have too wider line than home users. I think that the users can choose the band width at first Fx booting. (Of course, it might be too late for fx3.)
(In reply to comment #6) > Do we ignore the mobile users?? e.g., PHS/H". We don't. Just intend to optimize for the widest user base. (In reply to comment #7) > And I have a question. Can some office users allow this growing? E.g., 100 > employer office might not have too wider line than home users. I think that the > users can choose the band width at first Fx booting. (Of course, it might be > too late for fx3.) Enterprise sysadmins can easily configure their settings, like proxies, with an extension or centralized control system (MCD) if needed.
(Removing two aliases from CC due to bugspam, sorry. Please add CC yourself if you're interested.)
(In reply to comment #8) > (In reply to comment #6) > > Do we ignore the mobile users?? e.g., PHS/H". > > We don't. Just intend to optimize for the widest user base. I cannot accept it excepting that we produce the simple way for changing it. > (In reply to comment #7) > > And I have a question. Can some office users allow this growing? E.g., 100 > > employer office might not have too wider line than home users. I think that the > > users can choose the band width at first Fx booting. (Of course, it might be > > too late for fx3.) > > Enterprise sysadmins can easily configure their settings, like proxies, with an > extension or centralized control system (MCD) if needed. I agree for the big companies/organizations. However, the most Japanese companies are small. I worry about them. (Note that I'm not sure we have such users. However, they should be our hidden new users.)
Wait, looks like the prefs are not localizable.
Okay, Comment 3 was just a reference. Let's discuss the practical values.
My conclusion: Unless there is some pref which make users feel better without large side effect, we should not set these pref in l10n. Details: I think these settings should be *relatively* appropriate. Current Firefox setting is optimized for US/World average network environment and not appropriate for countries in which broadband connection is widely used. Network connections are relative to countries and some of the setting should also be relative. But at the same time, you know, we must not ignore RFC and must not force sysadmins change their server config (settings in Fasterfox cannot be accepted). # Setting used in Fasterfox is out of discussion As long as I considered about each pref, it seems that we cannot make almost user feel apparently better without any side-effect. Current default values are not best for broadband but reasonable. for example: - nglayout.initialpaint.delay = 250 is already enough short. We cannot feel much better if we change this to 100 etc. - network.http.max-persistent-connections-per-server = 2 is small for broadband user but we cannot change as long as we respect RFC 2616 If we change this to lager value, servers may be going to be in trouble. - network.http.max-connections = 24 may be small but larger value will not make us feel much better. # exception is only when Fx restore sessions maybe If Firefox will change network settings automatically depending on how the network speed is, it's better but that feature is not required for Fx3.
I don't like the complexity here. Just for press reviews alone, this sounds yacky. And running performance tests would yield even stranger results. There isn't really *that* much of a strict mapping between locale and region, too. Feels like a recipe for trouble from a messaging point of view. If we feel that we have a really good set of pref settings for broadband users, we shouldn't set those per locale, but pack them up in an extension and make that really popular on AMO instead. At least that'd be my angle on things. CCing mconnor and beltzner for comments from a Firefox product POV.
We should not make this setting different for different locales due to reasons stated earlier. However, we should consider upping it by default as IE8 is bumping from 2->6: http://www.ajaxperformance.com/2008/03/16/testing-ie8s-connection-parallelism/ Why not do the same for Beta5?
Shall we close this bug and file a new one for your suggestion?
(In reply to comment #16) > Shall we close this bug and file a new one for your suggestion? > Yes, filed bug 423377.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.