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

I am not familiar with systemd-analyze critical-chain or even with the terminology involved (like what is a "critical path") but what I can guess from the information above is that you are trying to measure how long it takes for some "graphical.target" to start, and that "graphical.target" depends on some "multi-user.target", which in turn depends on the "postfix.service", which in turn depends on the network. So, given these dependencies, I do not see why or how anything could be optimized. Whether "multi-user.target" should or should not depend on some mail service is another question, but that's what it depends on.

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).