NetworkManager-wait-online.service delays boot by 6 seconds on Lubuntu 20.04 (in other words, boot time was increased by 100% - and reduced by 50% by running `sudo systemctl disable NetworkManager-wait-online.service`)

systemd-analyze critical-chain

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @12.047s
└─multi-user.target @12.047s
  └─postfix.service @12.043s +3ms
    └─postfix@-.service @9.924s +2.116s
      └─network-online.target @9.916s
        └─NetworkManager-wait-online.service @2.522s +7.392s
          └─NetworkManager.service @2.193s +327ms
            └─dbus.service @2.190s
              └─basic.target @2.170s
                └─sockets.target @2.170s
                  └─snapd.socket @2.169s +1ms
                    └─sysinit.target @2.161s
                      └─systemd-timesyncd.service @1.962s +198ms
                        └─systemd-tmpfiles-setup.service @1.890s +43ms
                          └─local-fs.target @1.875s
                            └─boot-efi.mount @1.861s +14ms
                              └─systemd-fsck@dev-disk-by\x2duuid-DCEC\x2dD9F8.service @1.749s +110ms
                                └─dev-disk-by\x2duuid-DCEC\x2dD9F8.device @1.739s

systemd-analyze critical-chain [after]

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @5.923s
└─multi-user.target @5.923s
  └─postfix.service @5.919s +3ms
    └─postfix@-.service @2.500s +3.416s
      └─network-online.target @2.410s
        └─network.target @2.410s
          └─NetworkManager.service @2.136s +273ms
            └─dbus.service @2.131s
              └─basic.target @2.109s
                └─sockets.target @2.109s
                  └─snapd.socket @2.107s +1ms
                    └─sysinit.target @2.078s
                      └─systemd-timesyncd.service @1.920s +157ms
                        └─systemd-tmpfiles-setup.service @1.828s +81ms
                          └─local-fs.target @1.815s
                            └─boot-efi.mount @1.803s +12ms
                              └─systemd-fsck@dev-disk-by\x2duuid-DCEC\x2dD9F8.service @1.709s +91ms
                                └─dev-disk-by\x2duuid-DCEC\x2dD9F8.device @1.708s

When there are multiple tasks being done and some task depend on another it is possible that making some task faster will not improve things.

This may happen when some task was waiting anyway. When overall process can be made faster by speeding up some task, then one may say that it is on "critical path".

See https://en.wikipedia.org/wiki/Critical_path_method

So, given these dependencies, I do not see why or how anything could be optimized

By eliminating waiting for network connection this part of boot process was reduced from 12s to 6s. This delay was utterly pointless and should not exists at all, no idea why it is present (it would make sense in case of booting from network drive, but then it should be present in that part of boot process - not affecting majority with local drives).