Bugzilla

The layout for apple.com changed back so I was able to remeasure. I was not able to reproduce the original delay of > 1s: I found fenix is at most 500ms slower than Chrome. Here are my results (note: with only one replicate):

|Scenario|FF delay v. Chrome to first paint|FF delay v. Chrome to visual completeness|
|-|-|-|
|1. Type "https://www.apple.com" (no redirect)|100ms|0ms|
|2. Search by autocomplete "apple.com" (is redirect)|33ms|-200ms|
|3. Launch new tab, do #2 (no redirect)|500ms|267ms|
|4. Click link http://apple.com (is redirect)|267ms|33ms|
|5. Click link https://www.apple.com (no redirect)|400ms|266ms|

### Known issues
Expanding upon comment 5, there are two known issues in fenix that cause delays of ~200-500ms. The root cause is that some loading events get scheduled on the main thread but these are blocked by a UI transition of ~200-500ms (note: I never measured this duration in a robust way). https://github.com/mozilla-mobile/fenix/issues/21530#issuecomment-938954112 explains this more thoroughly. The two issues occur:
- because of the front-end code, for most load calls (it's optimized when typing a url on the search screen) https://github.com/mozilla-mobile/fenix/issues/21530
- because of the platform code, when page loads have a redirect bug 1734916

### Explanation of results
All in all, **I suspect the performance issues I can reproduce on apple.com can be attributed to the two bugs mentioned above.** I think we should address them and retest. See below for a more detailed explanation.

I tested a variety of cases to try to work around the known issues:
- Case #1 is expected to have none of the issues and it's results are within the noise, as expected
- Case #2 is expected to have the redirect issue but, curiously, it doesn't perform that way. It could be a fluke
- Case #3 is expected to have the front-end issue and it shows
- Case #4 is expected to have the redirect issue and may or may not have the front-end issue (but to a lesser degree): it shows
- Case #5 may or may not have the front-end issue (but to a lesser degree): the difference is larger than expected but perhaps explainable but the front-end issue

The layout for apple.com changed back so I was able to remeasure. I was not able to reproduce the original delay of > 1s: I found fenix is at most 500ms slower than Chrome. Here are my results (note: with only one replicate):

|Scenario|FF delay v. Chrome to first paint|FF delay v. Chrome to visual completeness|
|-|-|-|
|1. Type "https://www.apple.com" (no redirect)|100ms|0ms|
|2. Search by autocomplete "apple.com" (is redirect)|33ms|-200ms|
|3. Launch new tab, do #2 (no redirect)|500ms|267ms|
|4. Click link http://apple.com (is redirect)|267ms|33ms|
|5. Click link https://www.apple.com (no redirect)|400ms|266ms|
|6. Click link from google.com search results|-33ms|-200ms|

### Known issues
Expanding upon comment 5, there are two known issues in fenix that cause delays of ~200-500ms. The root cause is that some loading events get scheduled on the main thread but these are blocked by a UI transition of ~200-500ms (note: I never measured this duration in a robust way). https://github.com/mozilla-mobile/fenix/issues/21530#issuecomment-938954112 explains this more thoroughly. The two issues occur:
- because of the front-end code, for most load calls (it's optimized when typing a url on the search screen) https://github.com/mozilla-mobile/fenix/issues/21530
- because of the platform code, when page loads have a redirect bug 1734916

### Explanation of results
All in all, **I suspect the performance issues I can reproduce on apple.com can be attributed to the two bugs mentioned above.** I think we should address them and retest. See below for a more detailed explanation.

I tested a variety of cases to try to work around the known issues:
- Case #1 is expected to have none of the issues and it's results are within the noise, as expected
- Case #2 is expected to have the redirect issue but, curiously, it doesn't perform that way. It could be a fluke
- Case #3 is expected to have the front-end issue and it shows
- Case #4 is expected to have the redirect issue and may or may not have the front-end issue (but with a shorter UI thread blockage): it shows
- Case #5 may or may not have the front-end issue (but with a shorter UI thread blockage): the difference is larger than expected but perhaps explainable but the front-end issue
- Case #6 may or may not have the front-end issue and the redirect issue (but with a shorter UI thread blockage): it doesn't appear it has either, though. This is the case comment 0 uses, I believe

The layout for apple.com changed back so I was able to remeasure. I was not able to reproduce the original delay of > 1s: I found fenix is at most 500ms slower than Chrome. Here are my results (note: with only one replicate):

|Scenario|FF delay v. Chrome to first paint|FF delay v. Chrome to visual completeness|
|-|-|-|
|1. Type "https://www.apple.com" (no redirect)|100ms|0ms|
|2. Search by autocomplete "apple.com" (is redirect)|33ms|-200ms|
|3. Launch new tab, do #2 (no redirect)|500ms|267ms|
|4. Click link http://apple.com (is redirect)|267ms|33ms|
|5. Click link https://www.apple.com (no redirect)|400ms|266ms|
|6. Click link from google.com search results|-33ms|-200ms|

### Known issues
Expanding upon comment 5, there are two known issues in fenix that cause delays of ~200-500ms. The root cause is that some loading events get scheduled on the main thread but these are blocked by a UI transition of ~200-500ms (note: I never measured this duration in a robust way). https://github.com/mozilla-mobile/fenix/issues/21530#issuecomment-938954112 explains this more thoroughly. The two issues occur:
- because of the front-end code, for most load calls (it's optimized when typing a url on the search screen) https://github.com/mozilla-mobile/fenix/issues/21530
- because of the platform code, when page loads have a redirect bug 1734916

### Explanation of results
All in all, **I suspect the performance issues I can reproduce on apple.com can be attributed to the two bugs mentioned above.** I think we should address them and retest. See below for a more detailed explanation.

I tested a variety of cases to try to work around the known issues:
- Case #1 is expected to have none of the issues and it's results are within the noise, as expected
- Case #2 is expected to have the redirect issue but, curiously, it doesn't perform that way. It could be a fluke
- Case #3 is expected to have the front-end issue and it shows
- Case #4 is expected to have the redirect issue and may or may not have the front-end issue (but with a shorter UI thread blockage): it shows
- Case #5 may or may not have the front-end issue (but with a shorter UI thread blockage): the difference is larger than expected but perhaps explainable but the front-end issue
- Case #6 may or may not have the front-end issue and the redirect issue (but with a shorter UI thread blockage): it doesn't appear it has either, though