Heh, so WiFi otherwise does work well? Or did you not test it, and AP does not work because WiFi does not work at all? See the other report here: Dietpi installation on Rock4C Plus - #16 by Marco
Let’s test things carefully, with plain DietPi using ifupdown, with Bluetooth disabled at first, just WiFi. If that does not work, no need to dig into AP.
This “Boot wait for network” option has not really much effect. Should be probably clarified in the menu: It delays only the dietpi-postboot.service which anyway asynchronously triggers dietpi-update check or network time sync respectively, and executes scripts in /var/lib/dietpi/postboot.d if any are present. And it shows the pre-login banner on the local console, which requires network only since is shows the LAN IP address. However, login prompts can appear before that, and everything else. This service does not delay anything else, and it is not critical for any other service startup, SSH or other login methods, and hence also not dietpi-autostart options.
Which part of the boot you mean in particular with the 3-4 seconds, and how do you measure it? We do some adjustments to ifupdown-pre.service and ifup@.service to give the network-online.target more meaning. This can delay services that order themselves after network targets. However, systemd init runs everything asynchronously which is not explicitly ordered, and e.g. a delayed web service has no impact on login prompts etc. You can check the critical boot chain like that:
systemd-analyze critical-chain
However, e.g. login prompts are ordered only after those units:
After=basic.target sysinit.target plymouth-quit-wait.service rc-local.service system-getty.slice getty-pre.target systemd-user-sessions.service
So if you do not see any of these after (above) a network-related target or service in the critical chain, they are not delayed by it.
The other way round, NetworkManager might just be ordered into the boot procedure a way that the network.target and network-online.target are reached right after NetworkManager started, but not after it actually finished configuring the network interface. So e.g. the SSH server might start earlier, but you cannot connect earlier, since network is not up yet.