Вот тут и нафантазировали. Под "compressed bytes" на site-perf.com понимается количество сэкономленных байт. Размер HTML кода по этому числу достоверно назвать нельзя (ориентировочно — 250 килобайт плюс-минус 30%).
И что?
Ну будет больше, но никак не 32 минуты. Даже минута вряд ли получится :)
Картинки и большая часть остального начинают подгружаться без ожидания окончания загрузки основного кода. Кстати, про 170 кБ вы опять нафантазировали ;)
Ну а тут скорее согласен, чем нет :)
Eric Enge Interviews Google's Matt Cutts:
Переводить не надо? ;)
Кгхм, странная у вас интерпретация результатов с site-perf.com. 1933 секунды - это суммарное время ожидания для всех объектов страницы — их очень много, но ждут они параллельно. Полное время загрузки страницы — 17.7 секунды.
Внизу результатов поиска есть ссылка "See all my SearchWiki notes" — там можно увидеть список наклацанного и почистить его при необходимости.
Ippi добавил 26.12.2009 в 15:47
Кроме википоиска, есть ещё и "web history", которую гугл неоднократно обещал учитывать при поиске. Для верности её лучше отключить в настройках своего эккаунта.
Как раз такой сценарий был описан в самом первом посте об этом теге на гуглблоге. Собственно, основной смысл хинта rel=canonical изначально был в том, чтобы указать канонический урл страницы, если он доступна несколькими разными способами, давая поисковику понять, что это не дублированный контент, а один и тот же.
Ippi добавил 26.12.2009 в 15:27
Минуточку! Страницы с разной сортировкой имеют разный контент. Я бы на месте поисковика их тоже не склеивал :)
Именно туда и поставить — тогда в псевдодублях тоже появится этот тег. Именно для таких случаев его и придумывали.
Однако, даёте :)
Specify your canonical, 12 февраля 2009 года.
В декабре же была официально подтверждена работоспособность кросс-доменной версии этого хинта.
301-й редирект на основной сайт.
Ippi добавил 15.12.2009 в 19:00
... или сайт перенести на виртуальный хост апача или что там у вас.
Зачем же "у всех"? Достаточно "у некоторых" :)
