Skip to content
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

the_post_thumbnail('medium') is serving giant images #42

Closed
andrebu opened this issue Mar 7, 2016 · 3 comments
Closed

the_post_thumbnail('medium') is serving giant images #42

andrebu opened this issue Mar 7, 2016 · 3 comments

Comments

@andrebu
Copy link
Collaborator

andrebu commented Mar 7, 2016

no bueno

  1. hurts page load
  2. hurts SEO

screen shot 2016-03-07 at 4 07 32 am

screen shot 2016-03-07 at 4 07 40 am

@andrebu
Copy link
Collaborator Author

andrebu commented Mar 7, 2016

Problem is in WordPress backend -> Settings -> Media -> Image Sizes

Solution is to define smaller image sizes and use where appropriate so that images are ideally no larger (resolution/quality )than they need to be on screen.

the_post_thumbnail('medium') should output an image 300x300 pixels.

screen shot 2016-03-07 at 4 05 52 am

@andrebu andrebu closed this as completed Mar 7, 2016
@andrebu andrebu reopened this Mar 7, 2016
@andrebu
Copy link
Collaborator Author

andrebu commented Mar 7, 2016

Didn't even realize at first, but in that image of the WordPress backend, we also see "large" is set to 1000xWhatever. Also no good. Large should be 640x640.

Full is the original image size and will come out to 1000xWhatever.

screen shot 2016-03-07 at 4 18 15 am

screen shot 2016-03-07 at 4 18 21 am

@andrebu
Copy link
Collaborator Author

andrebu commented Mar 7, 2016

Image size on front page has been drastically reduced, speeding up page load and helping to improve the preverbal "SEO score."

screen shot 2016-03-07 at 4 20 18 am

screen shot 2016-03-07 at 4 20 08 am

screen shot 2016-03-07 at 4 20 12 am

@andrebu andrebu closed this as completed Mar 7, 2016
andrebu pushed a commit that referenced this issue Mar 7, 2016
…tage re-defined and properly set

This goes along with issue #42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant