Support » Plugin: The SEO Framework » Featured image issue with Twitter, if above 5mb

  • Resolved freshcreate

    (@freshcreate)


    I’m having an issue with images sometimes showing up blank on Twitter.

    It appears the common link between the posts that don’t work is that the featured images for those posts are above 5mb. Having a look at Twitter’s documentation, they restrict images above 5mb: “Our web crawler will typically download up to 5MB images.”

    I could start uploading smaller images, but that would make the workflow for posting more cumbersome. The original size is never used on the site, rather one of large/medium/thumbnail. Is there a way to default the “Social Media URL” field to the Featured Image, but the large/medium/thumbnail version, instead of original?

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Sybre Waaijer

    (@cybr)

    Hello!

    We do not control the size of the images posted via means other than the social image uploader within The SEO Framework. Unfortunately, there is no way for us to determine the file size of the reformatted image preemptively.

    Working around this corner case would impose a negative performance impact on most sites that don’t face this problem. This is because we currently rely on cached image metadata from the database (or completely bypass checks when the image is unrecognized), instead of reading and parsing the image files from disk. This straightforwardness is one of the many reasons we got TSF this performant.

    Moreover, it could be that the theme (or another plugin) you’re using is disabling the default compression methods in WordPress. This may cause your images to be uploaded at printing quality, instead of being processed into web-display quality. We’re not going to hijack that for holistic reasons, and unfortunately, with the method we use for our custom social image uploader (wp_crop_image()), we cannot directly set a desired quality.

    Please keep in mind that the cropper we use isn’t invoked when you manually enter an image URL. When you use the “Select Image” button underneath, then the image will be processed for social sharing. But again, the compression can be altered without us knowing.

    Now, with general web performance in mind, it’s best to upload files that are fit to display, while you retain most of the image-quality. For instance, via compression, you can get a vibrant 4K jpeg image well under 5MB this way. I understand that offloading everything to WordPress will help you work faster, so I recommend checking out the Smush plugin.

    There’s some more good work being done in the background. For instance, from WordPress 5.3, there are stricter image guidelines imposed–although these can still be overwritten and disabled without users knowing. See: https://make.wordpress.org/core/2019/10/09/introducing-handling-of-big-images-in-wordpress-5-3/

    Lastly, in the latest update (TSF v4.0.2), we also added an automatic lookup for smaller images when the image used is over 4K.

    I hope this information, the suggested workarounds, and upcoming functionality will prove useful to you. Cheers!

    Hello, thanks for your thoughtful and detailed response. Please see my clarifications below:

    The theme is custom, and indeed I do have Smush already implemented. Images rendered on the site itself are never the original, but rather one of the large/medium/thumbnmail versions. This way, if a contributor has an image at around 8000×6000 (common in stock photography), they don’t have to fuss over resizing/compressing in a photo editor – the theme handles that for them. This makes the post creation process foolproof and simplified. I suspect that this way of going about things isn’t so much a corner case, but I wouldn’t know for sure. Perhaps it is indeed atypical that a theme would allow larger images, ignoring the actual original.

    You mentioned the “select image” feature, but I wasn’t referring to that. I was referring to the fact that the “Social Image URL” field defaults to the Featured Image url, in original size. The fact that it defaults there is really handy, as it takes a step away from the post creation workflow. But as you can see in my use case, since I am otherwise relying on the resized versions, the fact this plugin defaults to the original size poses a problem if the original happens to be huge.

    At any rate, I wanted to clarify in case I was misunderstood in some way.

    Plugin Author Sybre Waaijer

    (@cybr)

    Hi again!

    Thank you for the helpful insights.

    Yes, when the featured image is used, TSF can read the image data and may be able to find a better alternative when the image is over the 4096px threshold. Alas, it won’t test for the image size.

    Could you provide a URL of the page where you find this issue occurring? We may discover that some vivid and vibrant images may exceed this limit, even when compressed and downsized to 4096px. That’d be a cause for action. We may also find that TSF somehow won’t be able to use the “smushed” images, or somehow ignores other critical environmental details.

    If you’d rather keep the link private, then feel free to share it with me via our contact page.

    A sidenote: I found that WordPress tries to work with “stored” attachment filesizes at one (of very few) points, but WP doesn’t populate that field anywhere. We might want to highlight that in a WP Core Trac ticket.

    Cheers!

    Excellent, I appreciate you continuing to look into this. I’ve gone ahead and sent some details in your contact form. Note that the original dimensions are actually less than 4096px, but stands at 9.5mb before resizing/compression.

    Plugin Author Sybre Waaijer

    (@cybr)

    Following up on this issue here: https://github.com/sybrew/the-seo-framework/issues/485.

    Related Core Trac ticket: https://core.trac.wordpress.org/ticket/47459

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.