This one really does re-encode
Most conversions between video containers are a shuffle rather than a rebuild. An MP4 and a MOV can both hold an H.264 video stream, so moving between them means lifting the stream out of one wrapper and dropping it into the other. It takes seconds and every pixel is identical afterwards.
MP4 to WebM is not that. WebM is a Matroska derived container that only accepts VP8, VP9 or AV1 video with Vorbis or Opus audio, and an MP4 almost always holds H.264 with AAC. There is no overlap, so every frame is decoded and encoded again from scratch. That is why this page promises minutes where the MOV page promises seconds, and why the progress bar on each row is worth watching.
What to expect on your machine
The encoder runs as WebAssembly on a single thread, which is slower than the multi threaded build you would get from a desktop install of ffmpeg. In our own measurements a ten second 360p clip took under twenty seconds including the time to fetch the engine. A minute of 1080p is a several minute job, and a phone will be slower still.
Two practical consequences. Keep the browser tab in the foreground: background tabs get their timers throttled, which stalls the work and makes it look far slower than it is. And if you only need part of the video, cut it before converting rather than after.
Choosing WebM on purpose
Convert mp4 to webm when the destination asks for it. That is usually one of three cases: a project that will not ship patent encumbered codecs, an upload form that rejects MP4, or a web page where you want a video tag with no licensing questions attached. Every current browser plays WebM inline.
Stay on MP4 for everything else. It is the format phones record, editors expect and social platforms prefer, it decodes in hardware nearly everywhere, and converting away from it costs you a generation of quality for nothing if the destination would have accepted it anyway.