I would actually not recommend doing this if page speed or SEO matters to you since you could assume each page view would take potentially 300ms longer. Also you would not be able to use any caching (eg a wordpress caching plugin etc).

Three ideas:

1. Instead of using the PHP solution, admins could configure their servers to write the DNT (Do Not Track) header into the server logs. Log entries marked as DNT would be skipped during import. (Allow to use JavaScript tracking and Log Analytics at the same time, and merge the data / deduplicate to avoid double counting #9665) even cookie values could probably be written to the server log, so explicit cookie-based opt-in (or opt-out, which is not really GDPR-compliant) could be written to the logs as well.

2. If using the PHP solution, which can handle cookie-based opt-in more easily, then you could set up a quick script writing a log entry into a file while quickly responding with e.g. a cached CMS response. (Instead of doing a much slower request to Matomo before responding to the client.) The log write could even be done synchronously, as (if logs are rotated) this would not take long. In a second step, the existing python CLI worker would process the php-written and opt-in-filtered log, importing log entries. Matomo would only need to provide a composer package to plug into webites and CMSes, writing a log in a common format, which is pre-filtered by opt-in, augmented with desired attributes and possibly user identifiers, and used instead of the nginx/Apache log.

3. Note that PHP-FPM can also do work after the response has been sent, during shutdown. Laravel even has official support for dispatchAfterResponse(): https://github.com/laravel/framework/blob/302f201400c623a5fe09ab66fdd237dfeff21375/src/Illuminate/Bus/Dispatcher.php#L261 / https://laravel.com/docs/8.x/queues#dispatching-after-the-response-is-sent-to-browser . This means that any software running on PHP-FPM could perform its request and then performa a calm and easy matomo log during termination.