English
Internet and Video Call Quality Test
Screen short-term latency and connection stability, compare official Zoom, Teams, or Meet planning guidance, and get cause-specific fixes without joining a meeting.
Browser call connection screen
This check takes about 4 seconds and sends twelve tiny HTTPS requests to the MeterSee edge. It does not join a call, capture media, or inspect your router.
Google Meet
Use broadband, a current supported browser, and stable low-latency connectivity.Meet adapts quality automatically. Google recommends Ethernet or 5 GHz Wi-Fi, avoiding VPN delay, and closing bandwidth-heavy apps when quality falls.
Read the platform's official guidanceReady for a connection screening
Run the short screen before an important call, then follow the cause-specific checks shown in the report.
The browser cannot reproduce a live Zoom, Teams, or Meet media path without joining that service. The Network Information API value is rounded, may be reduced for privacy, and is not a throughput test. Use the meeting app's in-call statistics for endpoint-specific latency, jitter, and packet loss.
Know what this browser screen can—and cannot—prove.
MeterSee times tiny HTTPS requests to its Cloudflare edge. It does not claim to measure RTP jitter, UDP packet loss, upload capacity, or the meeting provider's route, so the real app remains the final authority.
Compare without an optional VPN, then repeat on Ethernet or 5 GHz Wi-Fi.
Pause transfers, move closer to the router, and run two clean comparison tests.
Open the meeting app's live statistics and compare its actual latency, jitter, and packet loss.
HTTPS connection screening
How this test works
Twelve requests to MeterSee produce a nearest-rank median, p90, median absolute change between consecutive successful timings, and failed-request count. The browser downlink hint does not affect the grade.
What this cannot establish
These are HTTPS request durations, not RTP jitter, UDP packet loss, bandwidth, or the meeting provider's route. Repeat under the same conditions and compare the meeting application's own statistics.
Recheck before replacing hardware
Change one variable at a time, repeat under the same conditions, and compare with the operating system or the affected application. An unavailable reading is not a pass.
Relevant fix guides
- WebRTC and UDP packet loss: investigate the actual call before changing the networkRobotic speech and frozen video deserve a structured investigation. A website loading quickly is not proof that the meeting's media route is healthy, and a failed web request is not a lost audio packet.
- Google Meet has no sound: identify the missing audio path firstNo sound can mean that you cannot hear a meeting, nobody can hear you, or a shared video is silent. Those are separate audio paths and should not be repaired with the same checklist.