-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance issues on inlineCss
Transformer
#292
Comments
Yes, we can absolutely improve on that. I haven't noticed this yet because our default use case is the WordPress AMP plugin, where these requests are indeed cached. The main issue we have to figure out here is how to do caching in a framework- and environment-independent way... |
For reference, this is how remote requests are being routed in the AMP for WordPress plugin: https://github.com/ampproject/amp-wp/blob/6f1d2c26cba313cf70dcc36bdffee6dda78cecf1/src/AmpWpPlugin.php#L225-L232 As you can see it has local filesystem fallbacks in case the remote request fails, and the entire thing is wrapped in a caching decorator. |
I guess I could add a workaround by providing a custom A more elegant solution, maybe, could be adding the possibility of providing a sort of Maybe even having that as part of the config? $transformationEngine = new TransformationEngine(
new Configuration(['cache_store' => MyCustomCacheStore::class])
); |
Yes, that is currently the intended way of providing caching or other adaptations of the remote request interface, hence why there is an interface in the first place. I don't think we need any particular cache interface, as that can easily be wrapped around the existing interface via a decorator. What we need, though, is a default setup that works in a reasonable way when you don't provide a custom implementation. The default behavior right now just feels buggy in terms of how bad it is for performance. |
I suggest we build something like we have in https://github.com/ampproject/amp-wp/blob/6f1d2c26cba313cf70dcc36bdffee6dda78cecf1/src/RemoteRequest/CachedRemoteGetRequest.php#L27, but based on a file in stored in sys_get_temp_dir() instead of in WordPress transients. The file creation date can then be used to check for expiry. This It is not the most optimal solution for most environments, but it avoids the worst problem. You can still at any point use a more adapted custom solution for caching as needed. |
I wanted to start a discussion to see if is viable/posible to refactor the inlineCss transformer to improve the overall performance.
I found this while debugging some issues we get from time to time:
What happens is that every-time you call the
inlineCss
transformer, two external requests are made to fetch the current AMPRuntime Version
and the CSS styles.I'm wondering how often those two change? (Version and Css content), isn't that something that we could cache locally to having to make those two extra request each time?
See for reference https://github.com/ampproject/amp-toolbox-php/blob/main/src/Optimizer/Transformer/AmpRuntimeCss.php#L153
The text was updated successfully, but these errors were encountered: