959835 - bing search suggestions feel faster than google's

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Awesomescreen, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

It would be good to understand why

Comment 1

[Doug Turner (:dougt)]

What is bing's search url?  What is google's?

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

https://mxr.mozilla.org/mozilla-central/source/mobile/locales/en-US/searchplugins/google.xml#18
https://mxr.mozilla.org/mozilla-central/source/mobile/locales/en-US/searchplugins/bing.xml#18

so, you're right that the difference is http vs. https

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

There are a bunch of recently filed bugs to switch all search providers to https

Comment 4

[Aaron Train [:aaronmt]]

Such as?

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Aaron Train [:aaronmt] from comment #4)
> Such as?

The overall tracking bug for switching all in-product HTTP requests to HTTPS requests is bug 771788. The bugs for Bing specifically are bug 958873 and bug 958874. Bug 958874 is about search suggestions specifically.

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2)
> so, you're right that the difference is http vs. https

That's a little over-simplified but I admit that HTTPS is a component in the issue.
One problem is that google.com recently ADDED an OCSP URL to their SSL certificates, after not having one for a long time. This caused a big regression in performance for their site in Firefox, but their root CA required them to do it. On desktop Firefox, this is papered over because we preconnect to the default search provider before the user even starts typing, so first-connection SSL handshake latency is mostly taken care of already.

We can, and should if we're not already, be using the preconnection strategy for searches on Android. If we're not, it is no wonder that we're seeing extra latency.

In Gecko 28 and 29 and also later releases, we will have multiple optimizations for speeding up SSL, including TLS False Start and improved OCSP processing. This should help reduce latency further. However, it won't reduce latency as much as preconnection, AFAICT. So, we should figure out if we're doing preconnections or not for searches on Android. Does anybody know?

Also, please see bug 507641. All of our networking optimizations are in Gecko, so if we're not using Gecko to do networking we won't get those networking optimizations. We should get together and decide how to resolve bug 507641 once and for all, because bug 507641 means, IIUC, that we probably have bad and unnecessary latency between the time the user initiates the search (or taps a suggestion) and the time that the SERP loads, that we don't have on desktop.

tl;dr I think it is very likely that we can get https://bing.com and https://google.com working much better on Android than either search engine is currently working. Let's not get overly worried about the "switch to HTTPS" bugs as everybody is committed to making sure that things are resolved well.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Brian Smith (:briansmith, :bsmith; NEEDINFO? for response) from comment #5)
> (In reply to Aaron Train [:aaronmt] from comment #4)
> > Such as?
> 
> The overall tracking bug for switching all in-product HTTP requests to HTTPS
> requests is bug 771788. The bugs for Bing specifically are bug 958873 and
> bug 958874. Bug 958874 is about search suggestions specifically.
> 
> (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #2)
> > so, you're right that the difference is http vs. https
> 
> That's a little over-simplified but I admit that HTTPS is a component in the
> issue.
> One problem is that google.com recently ADDED an OCSP URL to their SSL
> certificates, after not having one for a long time. This caused a big
> regression in performance for their site in Firefox, but their root CA
> required them to do it. On desktop Firefox, this is papered over because we
> preconnect to the default search provider before the user even starts
> typing, so first-connection SSL handshake latency is mostly taken care of
> already.
> 
> We can, and should if we're not already, be using the preconnection strategy
> for searches on Android. If we're not, it is no wonder that we're seeing
> extra latency.

We do speculative connect to the default search engine before we display the engines:
https://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#6847

Comment 7

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.