Check how long it takes to boot:

systemd-analyze time

returns

Startup finished in 16.619s (firmware) + 10.201s (loader) + 36.729s (kernel) + 41.034s (userspace) = 1min 44.586s
graphical.target reached after 23.396s in userspace

This shows how long it takes for the Linux kernel and base system services to load. It doesn’t account for the time your graphical interface requires to boot up.

To put it another way, this shows you how much time is required, from the moment the kernel is loaded until you are dropped to the Linux console.

However, you can also see the time required by the graphical interface to initialize with this command:

systemd-analyze critical-chain

returns

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 @23.396s
└─multi-user.target @23.396s
  └─libvirt-guests.service @23.378s +18ms
    └─libvirtd.service @3.189s +20.187s
      └─network.target @3.189s
        └─NetworkManager.service @2.333s +855ms
          └─dbus.service @2.223s
            └─basic.target @2.207s
              └─sockets.target @2.207s
                └─docker.socket @2.206s +965us
                  └─sysinit.target @2.203s
                    └─apparmor.service @1.458s +745ms
                      └─local-fs.target @1.457s
                        └─run-user-1000-gvfs.mount @15.641s
                          └─run-user-1000.mount @14.700s
                            └─swap.target @1.607s
                              └─dev-mapper-ubuntu\x2d\x2dvg\x2dswap_1.swap @1.565s +36ms
                                └─dev-mapper-ubuntu\x2d\x2dvg\x2dswap_1.device @1.565s

Use the following command to check which service takes most of time

systemd-analyze blame

returns

         30.898s apt-daily.service
         20.417s rsyslog.service
         20.187s libvirtd.service
          5.774s systemd-networkd-wait-online.service
          3.654s docker.service
          1.841s apt-daily-upgrade.service
          1.820s snapd.service
          1.487s plymouth-quit-wait.service
           993ms dev-mapper-ubuntu\x2d\x2dvg\x2droot.device
           855ms NetworkManager.service
           768ms fwupd.service
           752ms udisks2.service
           745ms apparmor.service
           736ms networkd-dispatcher.service
           725ms snap-gnome\x2dcalculator-544.mount
           710ms networking.service
           697ms thermald.service
           680ms snap-netbeans-10.mount
           674ms snap-gnome\x2dlogs-81.mount
           661ms systemd-resolved.service
           643ms systemd-timesyncd.service
           642ms systemd-logind.service
           558ms ModemManager.service
           550ms apport.service
           544ms gpu-manager.service
           528ms motd-news.service
           502ms grub-common.service
...

and now analyze each major process. For example, to get further information on the AppArmor Service, to see if you can disable it or speed it up, use:

systemctl status apparmor.service

returns:

● apparmor.service - AppArmor initialization
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
   Active: active (exited) since Sat 2019-11-23 10:23:26 GMT; 2 days ago
     Docs: man:apparmor(7)
           http://wiki.apparmor.net/
  Process: 1181 ExecStart=/etc/init.d/apparmor start (code=exited, status=0/SUCCESS)
 Main PID: 1181 (code=exited, status=0/SUCCESS)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Also check the journal:

journalctl -u apparmor.service

returns:

-- Logs begin at Sun 2019-11-24 02:17:01 GMT, end at Mon 2019-11-25 21:05:42 GMT. --
-- No entries --

If you want to disable auto-starting of services during boot you can use the following command:

sudo systemctl disable some-time-eater-service.service --now

However, you might want to see which other services needs the service in question. To check use the following command

systemctl list-dependencies some-time-eater-service.service --reverse

Note: Replace some-time-eater-service.service with actual service name like postgresql@9.5-main.service.

Note that, disabling auto-start doesn't make a service non-startable. The service can be started after boot when requirement arises. If you want to completely disable it, read the next section

If you want to completely disable a service so that it can't be started, you should use mask instead of disable. Like this

sudo systemctl mask <SERVICE-NAME>

Replace the <SERVICE-NAME> with actual name of a service

The difference between mask and disable is mask make a service completely disable, you can't start it. You must unmask to start it with systemd (you can still start with service). But disable simply disable auto-start of a service, you can start it later.

For example, After masking my postgresql@9.5-main.service service, when I wanted to start it with systemctl the following message is shown

Failed to start postgresql@9.5-main.service: Unit postgresql@9.5-main.service is masked.