[TASK] Do not process the 1x image twice per tag - #101
Merged
Conversation
buildSingleTag() processes the image once to build the tag, then hands the same instruction array to addRetina(), which processes it again to get the 1x URI. Same instructions and same file, so the second call returns the same ProcessedFile and the same URI - it only costs another processed file lookup. For a source tag the result is not even used, because addRetina() falls back to it only when the tag carries no srcset, and a source tag always does. addRetina() takes the URI as an optional fourth argument now and only resolves it when a caller does not pass one, so overrides and external callers keep working unchanged. That is a third of all image processing on a page with many images. It shows up most where the processed files do not exist yet: every variant then writes the sys_file_processedfile row, which flushes the runtime cache of that original, so the next variant of the same image queries again. Measured on a page with 128 image tags: 384 processing calls before, 256 after.
bmack
approved these changes
Sep 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
buildSingleTag() processes the image once to build the tag, then hands the same instruction array to addRetina(), which processes it again to get the 1x URI. Same instructions and same file, so the second call returns the same ProcessedFile and the same URI - it only costs another processed file lookup. For a source tag the result is not even used, because addRetina() falls back to it only when the tag carries no srcset, and a source tag always does.
addRetina() takes the URI as an optional fourth argument now and only resolves it when a caller does not pass one, so overrides and external callers keep working unchanged.
That is a third of all image processing on a page with many images. It shows up most where the processed files do not exist yet: every variant then writes the sys_file_processedfile row, which flushes the runtime cache of that original, so the next variant of the same image queries again. Measured on a page with 128 image tags: 384 processing calls before, 256 after.