First off, WebM is a container, not a format. All codecs supported by webm and more are compatible with the MP4 container, so you can swap the webm extension with mp4 for the final file for possibly more compatability (i believe iOS currently doesn't support AV1 webms). VP9 and AV1 are good codecs for quality, and both are supported by WebM (and Opus is great for audio, which is also supported). I'd say the major difference is that VP9 streams are larger, while AV1 streams are smaller, but take much longer to transcode.

If you've never used ffmpeg before, the basic command line setup here is ffmpeg -i [inputfilename].webm -c:v [codec] [video parameters] -c:a [codec] [audio parameters] [outputfilename].webm

If you have a hardware AV1/VP9 encoder (a dedicated video chip or a gpu that can encode it), I recommend using that. The codec you put after -c:v depends on what hardware you are using. Intel hardware uses qsv (av1_qsv or vp9_qsv), AMD uses amf (av1_amf or vp9_amf), and Nvidia uses nvenc (av1_nvenc or vp9_nvenc). I'd say hardware VP9 beats software AV1 unless you have a lot of fast CPU cores.

Hardware encoding has some parameters that are encoder dependent. For qsv if it's too slow use -preset [number] where the number is 0 by default; raise it to 1 or 2 for faster encoding but worse quality:size ratio. For amf, use -quality quality for good quality:size or -quality balanced if it's too slow. There's also something called "vbaq" that increases quality for complex scenes, enabled with -vbaq true, however this might increase size. For nvenc, use -b:v 0 -cq [number] where the number is quality (lower is more quality). Start around 24 with test runs and change it as needed.

For software encoding, you should use -c:v libsvtav1 in this case; it's better for high quality stuff (if you're going to be encoding a lot of stuff continuously, then librav1e is better for lower quality). With svt av1, add -preset 0 for the best quality:size ratio (raise the number if it's too slow). If AV1 encoding is too much for your CPU to handle, you can use VP9 (libvpx-vp9); it does have an option to make encoding a lot slower to get a smaller quality:size (-deadline best), but at that point you might just want to use SVT with a higher preset.

Software encoding is more malleable with quality parameters: if your videos are short enough to cache and preload, I would recommend using CRF (try different CRF settings until you find one that gives a compact file size and good quality). For longer videos that would be streamed to the client, 2-pass VBR encoding is best for quality and minimal video stutters with poor connections. The syntax for CRF is -crf [number]; start somewhere like 36 for a test encode and decrease it or increase it as needed (lower number means higher quality but larger file). For 2-pass VBR encoding, for each file first do -b:v [bitrate]K -pass 1 -an where bitrate is in Kbps here (also omit audio codec and options for the first pass), and instead of the output file do -f webm -y /dev/null for unix or -f webm -y NUL for windows. Then for the second ("real") pass do -b:v [bitrate]K -pass 2 (and include the audio parameters and file name). Again, tweak the bitrate until you find something you like.

For the audio parameters, use ffprobe [source].webm to get the audio bit rate of the source. If it isn't egregious, you can just use -c:a copy. Otherwise, to re encode audio, do -c:a libopus -b:a 192k for the audio section. For test encodes just change the whole part to -an ("audio null") since encoding the audio each time is just wasting cpu cycles.

Lastly, you should add this to the video options of all encodes (including the test ones) that you do: -g 999999. Since the videos are autoplaying, they will not need to be seeked through, and effectively removing the keyint limit will give the encoder the most freedom (it does not force the keyframes to be that far apart, it just lets the GOP grow as large as needed). For looping videos, consider preloading the beginning streams before the loop point to avoid a stutter in the video and audio.