How can I triage slow userspace boot time?

Question

I am experiencing extremely slow userspace load time compared to the kernel loading time, as it can be seen in this systemd-analyze:

jnavarro@almanzora:~$ systemd-analyze 
Startup finished in 14.134s (kernel) + 1min 30.675s (userspace) = 1min 44.809s 
graphical.target reached after 12.124s in userspace

When I also asks the systemd-analyze blame I do not see any "good candidate":

jnavarro@almanzora:~$ systemd-analyze blame
          7.387s NetworkManager-wait-online.service
          6.863s plymouth-quit-wait.service
          1.996s docker.service
          1.966s exim4.service
          1.895s systemd-cryptsetup@luks\foo\bar\zaz\.service
          1.256s fwupd.service
          1.061s upower.service
          1.008s alsa-restore.service
           978ms dev-mapper-almanzora\foo\bar\zaz.device
           756ms udisks2.service

Any idea where I can find what is slowing down my boot time? Seems like systemd cannot help me anymore.

--EDIT--

systemd-analyze critical-chain output:

jnavarro@almanzora:~$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @12.124s
└─multi-user.target @12.124s
  └─docker.service @10.127s +1.996s
    └─network-online.target @10.125s
      └─NetworkManager-wait-online.service @2.737s +7.387s
        └─NetworkManager.service @2.416s +319ms
          └─dbus.service @2.413s
            └─basic.target @2.392s
              └─sockets.target @2.392s
                └─docker.socket @2.390s +1ms
                  └─sysinit.target @2.387s
                    └─sys-fs-fuse-connections.mount @22.662s +9ms
                      └─systemd-modules-load.service @548ms +95ms
                        └─systemd-journald.socket @531ms
                          └─-.mount @526ms
                            └─systemd-journald.socket @531ms
                              └─...

Answer 1

If systemd-analyze blame does not identify the delaying application/service this may mean that something else other than systemd is causing the delay.

• This could be caused by a device... Try to remove all unplug-gable devices (usb etc.) and reboot, a firmware/driver could cause the delay

• You could login as tty2 after boot (ctrl+alt+f2) to avoid loading the desktop and its applications, then from there use ps to see what's running and what took time to execute.

ps -eo pid,lstart,cmd will list started tasks with the time/date they were started and with ps -aux you could check the used cpu time per process.

• Also a defective hardware (like hard drive) may cause delay as well, you can check with a live cd, or by booting a different kernel version, or a different distribution then check if it's impacted as well