Set kern.msgbuf_show_timestamp to 1 and you get timestamps in dmesg; you can then deduct the boot time from /var/run/dmesg.boot and look for large jumps in the timestamps, i.e. what tasks take longer and block the boot process.
TBH I couldn't care less about the OS boot times, as long as the system always comes up reliably and reproducibly. History has shown that all attempts to "improve" boot times e.g. by doing things in parallel make system startup (a lot) less reliable. Firmware/BIOS initialization on servers takes *a lot* longer than booting the OS, which is also only done every few weeks anyways - so who cares about a few seconds more or less at OS boot?
And regarding desktops/laptops pretty much the same is true - most EFI implementations on consumer hardware have become so bloated, that they will easily take somewhere between 10-20 seconds to initialize (at cold boot) and finally handing over to the bootloader/OS, which from any halfway modern NVMe SSD will easily boot in that same timeframe.
Usually the biggest factors at boot are setting the time via ntp at boot (but shouldn't be skipped, especially on wonky consumer gear with bad RTCs) and dhclient waiting for a lease. The latter can be optimized by using 'background_dhclient' or 'NOSYNCDHCP', but this *will* usually break services that need a working network connection - i.e. it violates the hard requirement for a reliable and reproducible boot sequence.
