Discovery: Optional/experimental transformers

[kmyram]

Feature description

Identifying and determining issues from non-standard transformers when establishing feature parity between Go and PHP versions of optimizer libs.

Transformers differ in scope across versions with local variance. In Go, some transformers have split up same functionality over multiple tasks providing the same functionality in the end but with different process. The goal is parity of functionality but providing this with low complexity and a robust framework for PHP.

Derived from #958
Relates to #4214, #4215, #4216

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Listing optional/experimental transformers
• Determine importance/priority of each of these
• Provide brief description of possible implementation in PHP

Implementation brief

• N/A

QA testing instructions

• N/A

Demo

• N/A

Changelog entry

• First draft

[westonruter]

I've filed one issue related to this, but it's for a transformer that doesn't exist yet: #4439

[schlessera]

Discovery result document: https://docs.google.com/document/d/1O_YJPtDQX5BSOi01PuKSjhXgGOHjA1nqE5JXvgDd2mU/edit?usp=sharing

[schlessera]

Conclusion

[Extract from the above document]

My recommendation is based on the following assumptions:

• The optimizer should be optional for generating valid AMP. This entails that changes that are required for valid AMP will have to go into the Sanitizer instead.
• We want to focus on new functionality and deprioritize transformers that would provide functionality that is currently already covered by logic in the plugin itself.
• We want to prioritize transformers that have a noticeable impact on frontend performance on a typical WordPress site.

Given these assumptions, here is a numbered list of tasks to include for the next release, sorted by priority:

1. ServerSideRendering transformer with the following functionality:
   • Rewrite media, sizes, and heights attributes for SSR
2. Minify transformer with the following functionality:
   • Minify HTML
   • Strip comments
   • Trim whitespace in body text nodes
3. BrowserHints transformer with the following functionality:
   • Preload images
4. BlurredPlaceholders transformer
   • Add blurred placeholders for images and video posters

All other transformers/functionalities are either high-cost/low-benefit or already provided by the plugin and only needed for 2.0 (assuming that’s when we split out the optimizer library into a separate package).

cc/ @westonruter, @amedina

[westonruter]

I agree with your prioritization.

• The optimizer should be optional for generating valid AMP. This entails that changes that are required for valid AMP will have to go into the Sanitizer instead.

Perhaps we should divide the Optimizer's transformers into two sets: required and optional. The required ones we can always invoke to avoid having to duplicate the logic in the sanitizers. But given that the Optimizer is an optimizer, are there any transformers used for generating valid AMP? Yes, I suppose transformers like AutoExtensionImporter, AddMandatoryTags, and AmpScriptCsp.

As part of the modularization effort, we should be migrating the existing sanitizers into a new standalone PHP package. Should the scope of Optimizer be increased to be an AMP Processor? One class of transformers would be for optimization, another would be for conversion (e.g. img to amp-img) and another for sanitization/validation. This seems to be where the AMP Toolbox Optimizer is going as well. Note that the Optimizer has already moved into this territory already by implementing a Markdown transformer. I can imagine the AMP Toolbox Optimizer would at some point be able to take an arbitrary HTML page and do similar conversions/sanitizations that the AMP plugin is doing as well. Perhaps this would be a key area to collaborate on a common spec for how such auto-conversions are done (and also for oEmbed handling) and then we can have a Node.js implementation and a PHP implementation.

/cc @sebastianbenz

[westonruter]

All this to say, then the PHP Optimizer AMP Processor would no longer be optional. It would be required, but some of the transformers that purely handle optimization would be optional.

[sebastianbenz]

Agree with @westonruter. Having a common spec for transformers (with an easy to use test suite) would be a good thing to have.

[westonruter]

Closing as I believe the discovery has been completed.