systemd is one of the most popular choices of service managers that acts as the init (PID=1) process on Linux distributions. Although some distributions prefer simpler alternatives such as OpenRC for Alpine Linux and Gentoo or BusyBox for embedded environments, chances are that you are using systemd at this moment.

One essential tool that systemd provides for profiling and debugging the boot process is systemd-analyze. Although this is more of a “Swiss army knife” kind of tool in that it can provide security recommendations for service isolation, s-can an display PCR registers of TPS, etc. we are going to use it strictly for figuring out the bottlenecks that prevent our system from booting faster.

Try to run the time sub-command of systemd-analyze. This will tell you how long it took for your system to reach userspace and start up all (relevant) services. Here, we have multiple stages enumerated:

1. firmware: This represents the time the BIOS / UEFI took to detect and initialize the hardware, run its Power On Self Test (POST) and load the next bootloader in the chain.
2. loader: This is most likely the time spent in GRUB. Note that not all bootloaders report this elapsed time. They need to implement systemd's Boot Loader Interface.
3. kernel: Fairly straightforward. It's the amount of time needed by the kernel to reach the point where it forks into userspace after being loaded into memory by the bootloader. During this time, hardware detection takes place, drivers are being assigned and initialized, and worker threads are being spawned.
4. userspace: This covers the critical service startup phase. May optionally include the rootfs pivot if an initial ramdisk is used.

What are your boot times and how would you go about optimizing each category?

Since the most likely candidate for optimization is usually the userspace component, let's take a look at the critical-chain sub-command. This feature will show us the most costly chain of dependencies that delay a certain unit. If no unit is passed as an argument, it will automatically select the default unit (i.e., graphical.target most likely).

Note however that each unit can have multiple dependencies but whose initialization is usually parallelized. Meaning that once you solve the most egregious delays, the critical chain may change to another path of the dependency tree.

graphical.target @10.072s
└─multi-user.target @10.072s
  └─docker.service @9.239s +832ms
    └─network-online.target @9.236s
      └─NetworkManager-wait-online.service @3.231s +6.003s
        └─ ...

In the example above we see that the default target is delayed primarily by the docker service that is waiting for the NetworkManager to be brought online. So a first step would be do disable it if it's not necessary immediately after boot. If you want to see the complete dependency tree from which a critical chain is selected, run the following command:

$ systemctl list-dependencies graphical.target

Identify your own critical unit chain and describe each elements that introduces a delay. Usually, these have a +<time> appended after their name and completion time. Can these units be disabled or are they critical to the initialization of the system?