I see, the loopback device setup takes very long for some reason. I’ve tried to analyze it a while ago in another topic Snapd causing lengthy boot time? but it looked like the problem is in the kernel. This is probably running from a spinning hard disk drive, isn’t it? Anyway, I don’t think that’s a fair justification for this being slow.
Another observation is that on my Arch and openSUSE boxes, snapd.service does not appear in the critical chain. In fact, it’s not really wanted by the multi-user.target. While on 20.04 cloud image, it’s clearly enabled and in the critical path. You can try running systemctl disable snapd.service snapd.seeded.service, which will prevent snapd from being started during boot, but will keep the snapd.socket around, so snap commands will work normally. A downside is that automatic updates will not be applied until the snapd daemon has been started.