If you have an image URL like "/sites/default/files/styles/my_style/public/foo/bar/image.jpg?itok=gz66czQz", which is common in Drupal, then the parsing drops the itok query argument, so if the generated image doesn't exist yet, it results in a 404 page. That results in not showing the image at all, and even worse, it seems to trigger a weird condition where the fast image size detection library seems to run into a weird 60s-per-image timeout, making the amp sites very, very slow.
\Lullabot\AMP\Pass\ImgTagTransformPass::getImageUrl() needs to be extended to keep the query arguments. FWIW, I'm not sure why it even bothers to use the parsed string for relative src attributes, it could just work with the original input and check that for being root-relative.
We have a custom image formatter, I think relative URL's are currently uncommon in core due to caching issues, but eventually, the default formatter will fix this, at this point it will be a lot more common.
If you have an image URL like "/sites/default/files/styles/my_style/public/foo/bar/image.jpg?itok=gz66czQz", which is common in Drupal, then the parsing drops the itok query argument, so if the generated image doesn't exist yet, it results in a 404 page. That results in not showing the image at all, and even worse, it seems to trigger a weird condition where the fast image size detection library seems to run into a weird 60s-per-image timeout, making the amp sites very, very slow.
\Lullabot\AMP\Pass\ImgTagTransformPass::getImageUrl() needs to be extended to keep the query arguments. FWIW, I'm not sure why it even bothers to use the parsed string for relative src attributes, it could just work with the original input and check that for being root-relative.
We have a custom image formatter, I think relative URL's are currently uncommon in core due to caching issues, but eventually, the default formatter will fix this, at this point it will be a lot more common.