7.476s disableusb.service 

This implies you are running something in the foreground because it is not persistent so you feel there is no point in backgrounding it. However, if it takes that long to do its thing, perhaps you should fork it to background as soon as it starts instead.

The issue here is simply that it is more likely to benefit your boot time than leaving it in the foreground is, although it may not make any difference either way. However, if something else depends upon it completing (as opposed to simply completing initialization successfully, which is more applicable to a persistent service), then you should leave it as.

I see things such as: 1.736s keyboard-setup.service and 958ms kbd.service. They take almost 3 seconds.

I've never looked into it because it does not matter much to me, but I believe there is something wrong about the way the "keyboard setup" is handled on Raspbian. I've seen it run 90 seconds before being killed by systemd.

Do I need them if I am not using a keyboard? If not, how do I disable them?

I suppose not, but this may create a hassle for you if you suddenly do need a keyboard...or it might make no difference at all -- part of my suspicion is that it actually isn't accomplishing anything, since the "keyboard setup" is something that is static configuration and can be manually changed as required.

To disable a service, sudo systemd disable ....

raspi-config.service 

Odd this is still there since it is supposed to disable itself after it is run -- but that might not happen if you ignored it. That might relate to the keyboard thing. If possible you should plug in a monitor and see if it pops up post boot. In any case this is something else you might as well disable.

Here is the plot: http://www.eternal-lands.com/plot.svg

I think you should make disableusb.service After=sysinit.target.

I am running a head-less raspberrypi Zero and I could shave some seconds from it like so:

Systemd

# Don't start the Light Display Manager on headless sudo systemctl disable lightdm.service # In a headless environment you don't need the keyboard setup. sudo systemctl disable keyboard-setup.service # Checks if the country is set in the WIFI config. This is likely a regulatory precaution. sudo systemctl disable wifi-country.service # Unless you have an external joystick or something that uses `/dev/input/` sudo systemctl disable triggerhappy.service # I read that the swap file actually slows the PI down and decreases SD card lifetime. sudo systemctl disable dphys-swapfile.service # Disable Bluetooth unless you need it sudo systemctl disable hciuart.service # Unless you have a hardware button to disable the WIFI you won't need this sudo systemctl mask systemd-rfkill.service # disabling won't work # Open GL should be obsolete on a headless machine sudo systemctl disable gldriver-test.service # Only disable this one if you're not using `/etc/rc.local` sudo systemctl mask rc-local # You might to re-enable this service when making changes using `sudo raspi-config` sudo systemctl disable raspi-config.service 

Please note that systemd-analyze outputs the boot time:

Startup finished in 1.532s (kernel) + 20.862s (userspace) = 22.395s 

Minimal boot output

In boot/cmdline.txt change tty1 to tty3 and append loglevel=3 quiet logo.nologo at the end after rootwait

This saved another second for me.

Misc

This guy achieves a raspberrypi boot of 3 seconds: https://www.samplerbox.org/article/fastbootrpi

This is a good blog with some steps to reduce the boot time: http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry-pi.html

DougieLawson explains some of the raspberrpi services https://www.raspberrypi.org/forums/viewtopic.php?t=195692

In-depth tutorial as PDF

Looking at the graph, it seems clear that disabling console-setup.service won't actually speed anything up anyway. As you can see networking.service is waiting until disableusb.service completes, so a 1.6 second load time for console-setup.service run in parallel won't affect the overall boot time at all.

There's an idea in scheduling of a critical path which, when any activity in this path is delayed, causes delays to the entire project. The other activities have 'float', i.e. they are not critical, and can be delayed without affecting the final finish time.

It is this critical path which you must save time on, not the non-critical activities. systemd-analyze critical-chain will help you identify the critical activities, although you can pretty much spot them on the plot. Any marginal gain in disableusb.service would help your boot time significantly.

It might also help to understand why your services take so long. For this, Bootchart2 might be useful. It can be installed with:

apt-get install systemd-bootchart 

To actually enable it, edit /boot/cmdline.txt and set:

init=/lib/systemd/systemd-bootchart 

After booting is complete, you'll find the chart saved in /run/log as an SVG file. Then, revert init=... to its initial setting (or delete it if it wasn't there before).

See also the man page for systemd-bootchart.