It's not a requirement in any way and your SEO might turn out just fine using different subdomains. My suggestion is not just made up from my imagination, but advice from a Google employee since this have been a real problem for us. By serving the same image from multiple subdomains, from the same page the image can end up in a kind of "limbo" where google can't decide which image to use.
Also, as I understand it, canonical headers are currently only supported for web search and not image search from reading this doc https://support.google.com/webmasters/answer/139066?hl=en . Again, this might not even be relevant for your case, Dennis :) ~ Nikolaj On Mon, May 11, 2015 at 9:40 AM Lucas Rolff <[email protected]> wrote: > It's not really required to serve it from the same sub-domain always. > The most optimal solution would be to add the canonical link header when > serving using domain sharding. > > But from a caching perspective, keeping the sharding consistent is indeed > beneficial (you can use crc32 on the image name e.g. this will always > return the same hash, and based on this do the domain sharding), but from a > SEO perspective, it doesn't matter if you just do it right with canonical > link. > > Nikolaj Schomacker <[email protected]> > 11 May 2015 08:49 > > And a last thing you should be aware of if it applies to your case is SEO. > Using multiple domains for images is perfectly fine in the eyes of Google, > but be sure the same images is always served from the same subdomain. Also > be sure to have all of the subdomains added to the same webmasters account > as your main site. > > ~ Nikolaj > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx > > Lucas Rolff <[email protected]> > 9 May 2015 20:24 > > What you should do, to increase the concurrent amount of requests, is to > use domain-sharding, since as Paul mentioned, browsers have between 4 and 8 > (actually) simultaneous connections per domain, meaning if you introduce > static1,2,3.domain.com, you will increase your concurrency. > > But at same time you also need to be aware, that this can have a negative > effect on your performance if you put too many domains, there's no golden > rule on how many you need, it's all a site by site case, and it differs. > Also take into account your end-users connection can be limiting things > heavily as well if you put too much concurrency (thus negative effect) - if > you have a high number of concurrent requests being processed it will slow > down the download time of each, meaning the perceived performance that the > user see might get worse because it feels like the page is slower. > > - Lucas > > Paul Smith <[email protected]> > 9 May 2015 20:03 > On Sat, May 9, 2015 at 11:37 AM, Dennis Jacobfeuerborn > > I am not an expert but I believe that most browsers only make between > 4 to 6 simultaneous connections to a domain. So the first round of > requests are sent and the response received and then the second round > go out and are received back and so forth. Doing a search for > something like "max downloads per domain" may bring you better > information. > > Paul > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx > Dennis Jacobfeuerborn <[email protected]> > 9 May 2015 19:37 > Hi, > I'm trying to find out how to effectively deliver pages with lots of > images on a page. Attached you see opening a static html page that > contains lots of img tags pointing to static images. Please also note > that all images are cached in the browser (hence the 304 response) so no > actual data needs to be downloaded. > All of this is happening on a CentOS 7 system using nginx 1.6. > > The question I have is why is it that the responses get increasingly > longer? There is nothing else happening on that server and I also tried > various optimizations like keepalive, multi_accept, epoll, > open_file_cache, etc. but nothing seems to get rid of that "staircase" > pattern in the image. > > Does anybody have an idea what the cause is for this behavior and how to > improve it? > > Regards, > Dennis > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
