Summary
When Chrome's automatic page translation is enabled for English → Japanese before https://speed.cloudflare.com/ loads, Cloudflare Speed Test reports an extremely low and clearly incorrect download bandwidth.
With automatic translation disabled and the page reloaded, the same connection reports approximately 80–90 Mbps.
Simply using Chrome's translation feature is not enough to reproduce the problem reliably. The important condition appears to be that translation is already active during the very early stage of page initialization.
The issue reproduces on both Android and Windows Chrome.
Steps to reproduce
- Open
https://speed.cloudflare.com/ in Chrome.
- Make sure automatic translation from English to Japanese is disabled.
- Reload the page.
- The speed test reports a normal download speed, approximately 90 Mbps in my environment.
- Enable Chrome's automatic translation for English → Japanese (for example, "Always translate English").
- Reload
https://speed.cloudflare.com/ so that automatic translation is active from the beginning of page loading.
- Let the speed test run.
- The displayed download bandwidth starts at approximately 5 bps or 5 kbps and gradually increases, but stops at around 90 in the initially selected unit — for example, around 90 bps or 90 kbps — instead of reaching the expected ~90 Mbps.
Reproducibility and translation timing
Automatic translation enabled before page load reproduces the issue consistently in my testing.
Manual translation behaves differently:
- Simply enabling translation manually does not reliably reproduce the problem.
- If I trigger manual translation at the very earliest moment immediately after initiating the page load, I can sometimes reproduce the issue, but not consistently.
- If the page load is already underway and I enable translation afterward, the issue does not occur.
This suggests that the problem is related specifically to translation being active during the initial initialization of the speed test, rather than translation of the rendered page in general.
Clearing cookies and site data does not resolve the issue.
Recovery behavior
Disabling translation alone does not immediately restore correct measurements.
To recover, I need to:
- Disable automatic translation.
- Reload the page.
After reloading with translation disabled, the speed test returns to normal.
Comparison with other browsers and devices
Android
Same Android device and network:
- Chrome, automatic translation disabled, after reload: approximately 90 Mbps
- Chrome, automatic translation enabled before page load: incorrect bps/kbps-range result
- Firefox: approximately 90 Mbps
- Firefox with automatic translation enabled: normal result
- Fast.com in Chrome: approximately 50 Mbps
Windows
- Chrome with automatic translation disabled: normal result
- Chrome with automatic translation enabled before page load: the same extremely low bandwidth issue occurs
- Firefox: normal result
- Firefox with automatic translation enabled: normal result
The fact that the issue occurs on both Android and Windows Chrome, but not Firefox even with Firefox's automatic translation enabled, suggests that it is specific to the interaction between Chrome's translation implementation and Cloudflare Speed Test.
Additional observation
The incorrect result appears to be associated with the unit selected during the initial measurement.
For example:
- If the initial display uses
bps, the value starts at roughly 5 bps, rises gradually, and stops around 90 bps.
- If the initial display uses
kbps, the value starts at roughly 5 kbps, rises gradually, and stops around 90 kbps.
The actual connection is capable of approximately 80–90 Mbps.
This makes the behavior look more like a measurement, initialization, or unit/scaling problem than an actual reduction in network throughput.
Expected behavior
Chrome's automatic page translation should not change the network bandwidth reported by Cloudflare Speed Test.
The test should report approximately the same result regardless of whether automatic page translation is enabled.
Actual behavior
If Chrome's automatic translation is active from the beginning of page loading, the reported download bandwidth is several orders of magnitude lower than the actual connection speed.
Turning translation off after the problem has occurred is not enough to restore the measurement. Translation must be disabled and the page must then be reloaded.
Environment
Android
- OS: Android 15
- Chrome: 151.0.7922.173
- Firefox: 148.0
- Translation language: English → Japanese
Windows
- OS: Windows 11
- Chrome: 151.0.7922.174
- Firefox: 154.0
- Translation language: English → Japanese
Test URL: https://speed.cloudflare.com/
Notes
Because the issue depends on whether Chrome translation is already active during the initial page load, this may involve an interaction during speed-test initialization rather than the translated DOM itself.
There are existing issues involving PerformanceResourceTiming / transferSize, such as #36. This may or may not be related, but the reproduction trigger described here is distinct and highly consistent: Chrome automatic translation being active from the beginning of page loading.
Summary
When Chrome's automatic page translation is enabled for English → Japanese before
https://speed.cloudflare.com/loads, Cloudflare Speed Test reports an extremely low and clearly incorrect download bandwidth.With automatic translation disabled and the page reloaded, the same connection reports approximately 80–90 Mbps.
Simply using Chrome's translation feature is not enough to reproduce the problem reliably. The important condition appears to be that translation is already active during the very early stage of page initialization.
The issue reproduces on both Android and Windows Chrome.
Steps to reproduce
https://speed.cloudflare.com/in Chrome.https://speed.cloudflare.com/so that automatic translation is active from the beginning of page loading.Reproducibility and translation timing
Automatic translation enabled before page load reproduces the issue consistently in my testing.
Manual translation behaves differently:
This suggests that the problem is related specifically to translation being active during the initial initialization of the speed test, rather than translation of the rendered page in general.
Clearing cookies and site data does not resolve the issue.
Recovery behavior
Disabling translation alone does not immediately restore correct measurements.
To recover, I need to:
After reloading with translation disabled, the speed test returns to normal.
Comparison with other browsers and devices
Android
Same Android device and network:
Windows
The fact that the issue occurs on both Android and Windows Chrome, but not Firefox even with Firefox's automatic translation enabled, suggests that it is specific to the interaction between Chrome's translation implementation and Cloudflare Speed Test.
Additional observation
The incorrect result appears to be associated with the unit selected during the initial measurement.
For example:
bps, the value starts at roughly 5 bps, rises gradually, and stops around 90 bps.kbps, the value starts at roughly 5 kbps, rises gradually, and stops around 90 kbps.The actual connection is capable of approximately 80–90 Mbps.
This makes the behavior look more like a measurement, initialization, or unit/scaling problem than an actual reduction in network throughput.
Expected behavior
Chrome's automatic page translation should not change the network bandwidth reported by Cloudflare Speed Test.
The test should report approximately the same result regardless of whether automatic page translation is enabled.
Actual behavior
If Chrome's automatic translation is active from the beginning of page loading, the reported download bandwidth is several orders of magnitude lower than the actual connection speed.
Turning translation off after the problem has occurred is not enough to restore the measurement. Translation must be disabled and the page must then be reloaded.
Environment
Android
Windows
Test URL:
https://speed.cloudflare.com/Notes
Because the issue depends on whether Chrome translation is already active during the initial page load, this may involve an interaction during speed-test initialization rather than the translated DOM itself.
There are existing issues involving
PerformanceResourceTiming/transferSize, such as #36. This may or may not be related, but the reproduction trigger described here is distinct and highly consistent: Chrome automatic translation being active from the beginning of page loading.