I've handled this in a few different ways depending on what was "required" and what was "nice to have" in order to develop. As you've identified, sometimes you just don't care to spin up all the different parts and pieces to stand up the app so you can check a CSS fix. How you handle it depends on your environment.
Configuration to Use Existing Services
If you have a stable dev/test environment with the required services, it can be easy to just change your config file to use those services. Why turn on your own version of the API that hasn't changed in months when you can use the identical version on the dev server? This is predicated on the stability of such things and having access to use those services. Some services won't be available in such a way, so this may not work.
Another option would be to install IIS / Apache / etc locally and set up the appropriate services to just be ready all the time. So you never have to worry about starting them up every time you want to develop. They are just there waiting for you whenever you need them.
If you can't use existing services, if you have good dependency injection you can leverage that. Once we had to do some testing of a shopping cart web page. And we wanted to run automated tests that would have had to hit the payment gateway API just to get a response so the code could move on. But our CI server was silo-ed in such a way that we couldn't access those APIs. So we used some configuration and DI tricks to use some testing/mock payment API classes. (Since testing the 3rd party API wasn't the important part of the test, this was fine.) We just stubbed out a class that would return some "good enough" response for our code. If possible, you might be able to just stub out a mock authentication access service that just always returns a good response for development only.
Make Standing Everything Up Easier
On other projects, mocking things with DI wasn't a viable option and there weren't really good options for using test/dev server services. In those instances we spent some time making setting everything up easier. On one project we set up a Docker container that we could start up that would start up all the little services we needed. One quick shell command, wait a bit for it to all start up and BAM, everything we needed. On another project, we just wrote a shell script to just start up the appropriate projects/websites/exes. This is the brute-force type of solution for where there just isn't a better alternative. It works when you can't leverage other techniques.