Feat: HTML Post Processing

[vkazakevich]

Resolve #4

[gregpriday]

This is looking good so far. Some of my initial feedback.

So I suggest we make a single Laravel job called something like OptimizeHtml. This job would load the HTML content from the filesystem, save it to a temporary file, then pass that filename to the optimization pipeline. Once the pipeline is done, it would save the file back to the filesystem.

This reduces the responsibility of each step in the optimization pipeline. All it needs to do is perform its optimizations to the file, then pass on some information to the next step. It doesn't need to worry about the filenames and it knows it has a locally stored file to deal with.

This would make a difference if someone is using S3 to store the files and is using multiple queue workers.

A developer should be able to configure the pipeline. Choosing which steps are run, and which aren't. They should also be able to add their own optimization steps - much like they'd add HTTP Middleware.

'optimizations' => [
   \SiteOrigin\PageCache\CriticalCss::class,
   \SiteOrigin\PageCache\MinifyHtml::class,
   \SiteOrigin\PageCache\AutoImgixSrcset::class,
]

[gregpriday]

I haven't actually tested this, but I think this module handles injecting the new CSS while also deferring the existing stylesheets.

[gregpriday]

Oh wait, I see how you'd do this. So you'd create a base job class that handles setting the temporary filename, and then have all of these jobs inherit from that class. Then inside the main OptimizeHtml, you'd just create the temp file and send that to a job chain and run all the jobs synchronously to ensure they all run on the same instance with access to the temporary file.

[gregpriday]

@vkazakevich I actually removed all the CDN responsibility and replaced it with simple events. This allows other projects to handle an after-optimization event however they want. In the case of Briefer, we can hook into our existing CloudFlare service class.