Open Bug 959835 Opened 7 years ago Updated 4 years ago

bing search suggestions feel faster than google's

Categories

(Firefox for Android :: Awesomescreen, defect)

ARM
Android
defect
Not set
normal

Tracking

()

People

(Reporter: blassey, Unassigned)

References

Details

(Keywords: perf)

It would be good to understand why
What is bing's search url?  What is google's?
There are a bunch of recently filed bugs to switch all search providers to https
Such as?
(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.
Keywords: perf
OS: Mac OS X → Android
Hardware: x86 → ARM
See Also: → 958873, 958874, 771788
(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
Assignee: dougt → nobody
You need to log in before you can comment on or make changes to this bug.