Using the per-revision bisect providing the bisect results,
Good build: 55.0.2853.0 (Revision: 416812).
Bad build: 55.0.2854.0 (Revision: 417283).

You are probably looking for a change made after 417244 (known good), but no later than 417245 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/bdbc597424976a0b2f23b38b0c3630b636347ad2..581fd42e219de5510f0fd7729e7b00a411ff68a8

@hiroshige -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.
Thank You.

Thank you for reporting!

This is because the page uses transitionshow.js to switch the image on the right-bottom corner, and transitionshow.js re-creates <img> element when switching the image.
Previously, the image remained on MemoryCache (because the total size used by Resources was below pruning threshold, and/or the image had high position in the LRU list and thus was unlikely to be evicted), and thus re-creating <img src="http://..."> hit the MemoryCache and its image size is immediately available.

However, after my CL (WeakMemoryCache), sometimes the image (ImageResource) is garbage collected and is not in the MemoryCache (e.g. after GC occurs), because my CL makes MemoryCache not to have strong references to Resources, and no one in the HTML/JavaScript retains strong references to the image persistently.
In such case, when transitionshow.js re-creates <img> element, Blink sends a request to the browser process and then gets response (typically from the Disk Cache), i.e. the image size is not available for a short period of time between request and response.
This causes the size of whole document to change, and thus causes the flickering.

Potential fixes might be:

1. Keep the image longer in MemoryCache such that we can always (or at least very likely) get the image from MemoryCache.
However, if we keep the concept of WeakMemoryCache ("MemoryCache shouldn't extend the lifetime of Resource to simplify loading and memory management"), how can we extend the lifetime of ImageResource?

1a. Fix transitionshow.js.
Previously, it works fine because the image is in the MemoryCache, but it is not guaranteed (just likely).
Fixing transitionshow.js such that we hold strong references to the images (e.g. make |preloadimages| globally persistent?) might a good way to make the code more robust.
cons: there might be other sites failing due to WeakMemoryCache for a similar reason, and fixing all sites might be not reasonable.

1b. Revert WeakMemoryCache.
cons: many CL depends on WeakMemoryCache and thus it will be a large revert and not possible.

2. Avoid flickering by e.g. not re-layouting while we are waiting responses from dis k cache?
(I'm not familiar with layouting etc. though)

Added loading/WeakMemoryCache-related people. Any ideas?

I think we should try not to do (1) or (1b).

The cons of (1a) assumes that many sites might be broken under WeakMemoryCache. If this is indeed the case then I think we should think of a more general solution. I hope most sites will not have a user-visible problem like this, given that persisting unused resources seems unintuitive for a dev.

I am very interested in something like (2) as a general purpose optimization. We have been thinking about how to avoid layout thrashing in reload cases in general.

Adding a Release block label, so that it gets fixed before M55 is pushed to stable.

Please undo or remove if not the case.

kouhei@ suggested closing this as WontFix because the script has chances to have inappropriate intermediate states (i.e. Image being loaded when switched) observed, and it is not guaranteed (by spec etc.) that such states are not observed.
We might be able to create a fix, but it would make the issue just less likely.