Serving Mobile Device Specific Post Image Size in WordPress is Very Difficult and Either Conflicting Results Come in Hand or SEO Compromised. Removing WordPress Post Image Link was quite easy – just a filter. Actually, we are using the filter – you can see, this post image is not hyperlinked. But the current topic – serving mobile device specific post image size in WordPress is very difficult.
Mobile Device Specific Post Image Size in WordPress : What The WordPress Crap Plugins Offer
WordPress has some bigger saying about number of Plugins. But, unfortunately, over 50% are real craps. They are functionally a way to either make money or get back links. Very few, limited number of Plugins are great and regularly updated. Plugin offerings are not good at the time of publishing this post. Either they harm the on page SEO by rebuilding oddly named newly sized images or they can not be used on Nginx PHP5-FPM setup or adds Javascript at header which can not be asynchronously delivered or are uploaded to third party server/cdn.
What basically AdSense Responsive Ad does? It serves image and media file, based on screen size (it is extracted logic, not the script) :
---
|
1 2 3 4 5 6 7 8 |
if(screen.Width < 800) { document.write( $this); } else { document.write($this); } |
But, that Javascript library is not Open Source. It is directly related to Google’s patented products. This thing Google Says as Responsive, but it is not Responsive – it is Adaptive. This is one of the problem of responsive design – we are using CSS style to push a 2000px x 5000px image on a mobile device and CSS is resizing it. Logically, we should serve a 200px x 500px image to a smaller mobile device. It was great if there was a filter available, which could detect the screen size and server a thumbnail instead of the post image. But there are hundreds of problems. What Google Plus does is telling the browser that go to this page :
|
1 2 |
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://example.com/mobile/page-1" > |
and the mobile device specific page has this stuff :
|
1 |
<link rel="canonical" href="https://example.com/page-1" > |
That, unfortunately requires a tweak in XML Sitemap :
|
1 2 3 4 5 6 7 8 |
<url> <loc>https://example.com/page-1/</loc> <xhtml:link rel="alternate" media="only screen and (max-width: 640px)" href="https://example.com/mobile/page-1" /> </url> </urlset> |
That probably not supported by WordPress SEO. XML Sitemaps of Yoast WordPress SEO needs much improvement. There is a conflict with W3 Total Cache in CDN setup too. Otherwise, it works great on Nginx setup.
It is fully impossible to serve mobile device specific post image size in WordPress, you need to install this plugin first :
|
1 |
https://wordpress.org/plugins/mobble/ |
Then logically filter :
|
1 2 3 4 5 |
if (is_mobile()) { the_post_thumbnail('medium'); } else { // do this } |
and combine with Removing WordPress Post Image Link tutorial. It is a pathetic way, because – WordPress with 5K+ posts can fail to deliver thumbnail. Instead of echoing return $content; directly, we need to filter the $content;. We have not tested, but logically it should work. Also, you need to work on the Image Width and Image Height.
It is difficult to say, how Google will think about the webpage – because the content is changing without any declaration.
Mobile Device Specific Post Image Size in WordPress : Nginx Has Better Offer
Nginx has lot of features including image_filter and virtual directory support. Kaspars Dambis did a great work by first adding a viewport snippet (in Theme or Child Theme’s function.php file)
|
1 |
http://kaspars.net/blog/wordpress/adaptive-images-viewport-cookies |
and then adding/modifying this block :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
location ~ \.(jpg|jpeg|gif|png)$ { expires max; if ( $cookie_viewport ~ ^800|600|400$ ) { return 418; } error_page 418 = @viewport_image; } location @viewport_image { internal; expires max; add_header X-Viewport $cookie_viewport; image_filter resize $cookie_viewport -; image_filter_jpeg_quality 90; error_page 415 = /empty; } location = /empty { internal; empty_gif; } |
You should carefully edit the file. It not only serves the basic problem, the image served is optimized and cached. You should test it on dev setup first.
