Обновить

Комментарии 113

Уже кстати давненько для Firebug`a есть дополнение PageSpeed от гугла, весьма полезная штука
Российская версия для Яндекса — учитывать для ранжирования аттестацию сайта, которую проводит ФСБ.
не исключено

как хорошо что есть Гугл...)
как хорошо, что у нас не Китай с его Великим Китайским Файрволлом)
от любви до «нелюбви» один шаг ;)
В Китае тоже есть гугл. И работает он там так, как ему скажут. Не в нем дело.
*Случайно забрел сюда с поисковика*

За 5 лет все поменялось. Конечно, не как у Китая, но совсем безрадостно и бесперспективно.
НЛО прилетело и опубликовало эту надпись здесь
и персональные блоги с уникальным контентом на виртуальных хостингах отранжируются ниже, чем ресурсы более богатых копирастов на вдс или дедиках?
Или страницы, находящиеся на серверах в США, отранжируются выше, чем находящиеся на серверах в других странах, на отдалении 200-300 мс от робота?
Датацентры Google есть в разных точках земного шара.
Потом RTT далеко не самое ключевое звено в скорости загрузки сайта.

Например, если кто-то на своём сайте не заморочился на тему настройки компрессии gzip и правильного кеширования, так ведь страдают все пользователи.

Как уже было упомянуто, больше информации на code.google.com/speed/articles/

P.S. Данные по Рунету, по Top100 сайтам, их приводил Richard Rabbat на GDD:
PageSpeed: avg. page 561KB, avg. transfer 429KB (not cached), compression 40/100, img comp. 85/100
Короче, сайты Гугла будут на первых позициях. :)
Еще бы Гугл учитывал КПД сайта, соотношение полезного контента с баннерным в ранжировке.
Весьма сомнительная мера. Если мне действительно нужна информация, то скорость загрузки вряд ли будет иметь большое значение.

В любом случае, уверен, что этот показатель не будет играть решающую роль при определении позиции.
Интерпретировать надо несколько иначе.
Если есть сайты A и B, где есть информация, которая вам нужна, а
сайт A быстрее, чем B, то далее понятно.

Если B, пусть и медленный, но чуть ли не единственный, где есть эта информация, то он должен быть в топе результатов.
Хм, почему бы пользователю самому не настраивать факторы влияющие на ранжирование? Поисковик будущего?!!!
представил себе длину строки для такого поискового запроса… а оно вам надо?
Придумало ведь человечество авторизацию и меню «настройки».
Ага, платная фича — стоит 10000$ в месяц (за хранение индексов)=)
мелко берёте что-то. индекс совсем маленький будет)
Дружно ставим на свои сайты Web Optimizer :)))
Я не думаю, что степень влияния этого нового фактора на ранжирование будет слишком велика
Наверное речь идет о том, что ссылка на скачивание файла размером 500 мб будет ранжировать выше тот сайте где выше скорость.
… будет учитывать не только релевантность контента и PR...


А разве PR учитывается при поисковой выдаче Гуглом?
PR уже давно (как минимум полтора месяца) не учитывается при ранжировании. Теперь играет роль чего-то на подобии Alexa rank.
Тоесть если он и влияет на ранжирование то очень слабо.
Тогда зачем нужен PR?
Разве что как пузомерка. PR раньше оценивал количество и качество линков на сайт. Сейчас те же параметры работают в алгоритме, просто немного изменились и изменилось их влияние.
Из Google Webmaster Tools PR уже удалили.
Из комментариев гугла мне стало ясно, что в webmaster tools PR был убран именно по причине того, чтобы не быть пузомеркой.

Возможно, PR до сих пор учитывается как и прежде. Только он, конечно, не единственный фактор ранжирования.

Поэтому нет смысла выделять его отдельно в webmaster tools.
Я согласен что вполне вероятно что PR учитывается. Просто судя по интервью сотрудников гугла, которые смотрел в последнее время — PR как таковой становится все менее важным. Факторы, которые учитываются при определении PR и сейчас играют свою роль при ранжировании.
Сейчас он стает играть роль более аналитического инструмента. Тоесть наращивать PR ради PRа уже давно не имеет смысла.
А вот для определения жырности ссылок его все еще можно использовать, ведь если у страницы большой PR, это значит что у нее много бэклинков и она обладает у поисковиков определенным трастом. Соответственно с нее иметь ссылку лучше чем со страницы с теми же параметрами но с PR пониже.
P.S. среди рейтингов факторов ранжирования можно даже найти alexa rank.
Matt Cutts говорит, что PR — это лишь один из сотен сигналов, которые учитываются в рэнкинге.
Оптимизировать лишь один из сигналов было бы странным.

Так же как и скорость загрузки — один из сигналов. Данный сигнал гораздо более важный (при учёте, что контент хороший, конечно же) для владельцев сайтов, т.к. иначе посетители будут уходить.

Исследование на эту тему:
Google: увеличение latency на 400ms, на 0.6% уменьшение количества поисков
Bing: увеличение latency на 2s, на 4.3% уменьшение прибыли
en.oreilly.com/velocity2009/public/schedule/detail/8523
страничка «Hello, word!» будет в верхних строчках)))
По какому запросу?
life universe and everything
Или «Under Construction»…
По моему это тупо. Какая разница сколько весит страница, если на ней есть ценная информация?
Я думаю, будет не тупая прямая зависимость скорости загрузки.
Позиция будет зависеть от формулы, вроде этой:
скорость загрузки * n (чем выше тем хуже)
где n — количество «очков» за единицу времени — чем сложней сайт, тем меньше n. Сложность сайта должна быть в разумных пределах, конечно же. n тоже может иметь не прямо пропорциональную зависимость от кол-ва элементов на странице.
Тогда сайты лучших дизайнеров будут на последних местах?
Вообще-то дизайнер должен учитывать технологические факторы и тебования ТЗ.
хороший дизайн — не значит много картинок и прочего хлама
они будут на первых.
НЛО прилетело и опубликовало эту надпись здесь
Корпорация добра и света хочет ускорить интернет?! О неееет!
SPDY — это протокол общения браузера и сервера. для пользователей, чей браузер не поддерживает SPDY, наличие его на сервере на скорость не влияет. поэтому странно было бы ранжировать spdy-сайты выше.
Не очень хорошая затея, ведь нагрузка в разное время разная, и если робот зайдёт на сайт при высокой нагрузке естественно возможна долгая загрузка страницы, из-за этого терять PR?
Робот будет проверять ваш сайт десять раз в секунду и ранжировать в зависимости от текущей скорости загрузки. Тем самым нагрузка будет автоматически балансироваться с загруженных сайтов на более свободные и быстрые :)
роботы заходят на сайты тысячи раз в неделю. все разы в пробку попадут?
В принципе, это вполне логичный шаг, ведь какой прок с ценной информации на сайте, если страница грузится полчаса? Вполне нормально, что перед ней в результатах поиска можно показывать страницу с таким же контентом, который загружается быстрее.

Хмм… с одной стороны логично, Google и Мэтт Каттс молодцы, стараются сделать полезное людям. Но с другой стороны, много ли страниц найдется с одинаковым контентом и со значительной разницей во времени загрузке, копипаст это се таки не хорошо, и его не должно быть в выдаче. Да и в любом случае, если этот фактор и будет использоваться, то далеко не во всех случаях, и он скорей всего будет заключительным и корректирующим, после всех остальных факторов ранжирования.
А конкурентам могут забивать канал.
Это уже ДДОС.
НЛО прилетело и опубликовало эту надпись здесь
Ну может хоть примут системные меры по борьбе с ДДОСом.

Мое предложение: на всех центральных магистральных каналах, ловить ДДОСеров. При нарушении — показывать страничку, мол бросайте это дело. При последующих — бан на несколько часов.

Можно сделать, для упрощения, это на уровне сетей: если автономная система не может подавить ДДОСерский трафик из себя, временно отключать ее от сети. Так даже правильнее, и более соответствует децентрализованной структуре сети. А уж внутри сетей админы пусть сами выявляют злодеев.

А то сейчас владельцы сайтов оствлены один на один с проблемой, а хостер в лучшем случае закороет аккаунт и предложит переехать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
и правильно сделали. с такими проблемами надо бороться всем миром, иначе ничего не получится.
Никаких конфликтов небудет
Провайдеры выпускают мусор потому что им лень отслеживать аномальную активность
Будет как со спамом — провайдеры банят тех, кто шлет спам
Буду банить и за DDOS.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Тоже самое, как бывает когда отрубают за спам.
Почему? Провайдер показывает такому юзеру на любой запрос картинку с объяснением, в чем тот виноват, и предложением вылечить компьютер.

Хотя сейчас я подумал, правильнее защищаться все же на уровне хостингов, т.е. перед входом на хостинг должен стоять счетчик запросов, а владелец сайта в панели управления ставит лимиты на число коннектов с 1 IP/1 подсети, и какой-то API для того, чтбы сайт/его владелец могли банить негодяев.

Возможно, также, если атака идет преимущественно из 1 региона (подсети), динамически сужать скорость канала в тот регион (т.е ограничивать трафик на/с той подсети), в большом датацентре с десятками тысяч сайтов это бы снижало нагрузку на сервера.

Банить зомби все таки не получится, так как найдутся всякие военные, которые не позволят себя отключать, или какие-нибудь китайцы, которых миллиард человек и котрым пофиг на все абузы.
Применять Ajax — отличный способ увеличить «скорость интернета».
И если бы поисковики научились сначала аяксовые сайты индексировать, а потом уже ранжировали по скорости, было бы логичнее.
Если бы вебмастера научились писать правильные ajax-сайты, было бы намного проще. Всем.
Если бы поисковики сказали, что такое «правильные ajax-сайты», веб-мастера бы их делали такими…
Ответ ниже
Что вам мешает делать индексируемые аяксовые сайты?
В большинстве случаев это не так сложно…
<a href="/page" onclick=«ajax_load(this); return false;»>Ссылко</a>
Посмотрите в сторону плагина ajaxify для JQuery www.dom111.co.uk/blog/coding/jquery-ajaxify-update/191
И ведь тут хорошо всем — и поисковикам и параноикам без яваскрипта…
А кто Вам сказал, что мне что-то мешает?
Я говорю о СКОРОСТИ !!!
Аяксовый сайт работает быстрее, чем статический. А поисковик не видит этого.
Хуже того, он будет считать аяксовый сайт более медленным, так как он на каждую страницу грузит скрипты, необходимые для реализации аякса.

Ну и поскольку я вообще работаю с Extjs (не делаю сайты), то поисковик на моих страницах видит только пустой
у аяксового сайта загрузка первой страницы будет медленнее, чем у статического. а большинство переходов с гугла будут именно на «первую страницу». и после первой страницы пользователи уйдут. так что пользы от вашего аякса приходящим с гугла не будет.
Во-первых, аякс — не мой.
Во-вторых, при нормальном показателе отказа, с первой страницы уходит меньше 50% посетителей.
В третьих, то, что большинство переходов с гугла идет на главную — в большинстве случаев говорит о не верном подходе к оптимизации сайта. Не стоит путать «самую посещаемую страницу» и «большинство посетителей».
Ну и последнее: я не делаю сайты с содержанием, которое грузится аяксом. Не стоит персонализировать мой комментарий.
спасибо. какой кадр смотреть? :)
Все подряд :) Там все — про скорость загрузки ;) Еще лучше почитать HIgh Performance Web Sites и Even Faster Web Sites от него же
Откуда информация, что поисковик «на каждую страницу грузит скрипты, необходимые для реализации аякса»?
Конечно, эту информацию подтвердить я не могу.
Но можно подумать: если нужно определить скорость загрузки страницы, то должны учитываться и загрузка рисунков и css и javascript.
Бедные сайты на флеше :(
А разве гугл не голый хтмл (ну да, еще скрипты, который он умеет парсить) грузит себе? Да и флэш он вроде как не понимает. Или Вы просто пошутили? :)
Кажется, Вы сегодня переработали, и Вам пора отдохнуть.
Черт побери, все-то Вы знаете… :)
Не могу не согласиться.
полезность информации намного важнее скорости доступа к ней…

это полезно разве что в ситуации, когда контент клонируется — когда при попытке зайти на основной сайт приходится долго ждать, дольше, чем с сайта-копипастера… но, согласитесь, не по понятиям это ставить основной источник информации ниже копипастера только потому что у последнего скорость больше получается…
Может быть, Гугл свой вебсервер (GWS) планирует развивать или что-то новое придумает… что-то, что могло бы потеснить Apache…

а то… к чему все это… не верится, что всё это без задней мысли делается…
ага, SPDY? :)
«задняя мысль» вполне себе открыта: code.google.com/speed/

цель сделать интернет быстрее. чтобы люди больше могли поисковых запросов за день в гугл вбить
Когда я ищу рецепт яичницы, способ использования сеттеров в IE или время старта Атлантиса, мне, как пользователю, всё равно, оригинал это будет или копипаста, мне главное — чтобы сайт быстро открылся и показал нужную информацию.
Как раз сегодня так и было — в Гуглоновостях написали про запрет последней Call Of Duty. Тыкнул на первую ссылку — подождал минуты две, сайт так и не загрузился. Тыкнул вторую ссылку — через полминуты пришёл html сайта, но без CSS и картинок. Ткнул на третью (PC Games Hardware) — открылось моментально.
тогда создателям сайтов будет ещё проще и выгоднее делать контент из копипасты, чем самим — если разницы не будет…

сейчас-то как-то подразумевается, что оригинал всегда на первом месте…

этого ли мы хотим добиться?
Народ, смотрю паника тут вовсю набирает обороты.
«Повлияет» — это не «будет зависеть только от»!

Думаю, в Гугл не идиоты, и ранжирование по скорости будет зависеть от множества факторов. Я думаю от скорости будет зависеть ранжирование именно между равноценными страницами.

Конечно, нюансов, наверное, будет много, но не думаю, что все так уж плохо.
Да, идея хороша если Гугл к ней подойдет с умом. Если время загрузки — это некоторое абстрактное число, влияющее на скорость, с какой пользователь получит доступ к необходимой информации. В результате некоторые задумаются, грузить ли лишние скрипты, использовать ли спрайты, кеширование, верстать на таблицах или на дивах...)
Верно, об этом полезно задумываться (всегда :)).
А то в начале первых секунд загрузки пользователь смотрит на пустой (белый) экран.
Возьмите для сравнения сайт Amazon. Там информационные блоки отображаются достаточно бысто, а потом всё остальное загружается. И т.д.
Я вот сегодня заметил что спецификация по HTML5 (Editor: Ian Hickson, Google) активно продвигается Google. Может это тоже как-то связано? (ну в плане чтобы народ активно внедрял нативные элементы для видео и аудио, например, которые не требуют скриптовой начинки)…
я верю, что Гугл может подойти к такой проблеме грамотно
потому что
1) hello world будет выше всех? нет, она вообще не попадет в основной индекс, а будет болтаться в дополнительном
2) дорвеи… аналогично
3) клонирование контента? — они и так вполне отсеивают и определяют, где оригинал, не с клонами ранжирование идет
4) день да день не приходится? ddos? не обязательно такую статистику один день собирать, можно и среднее вычислить с откидыванием пиков

в общем, если уже идет сравнение достойных сайтов в основном индексе с похожим PR, то почему бы времени загрузки не стать решающим фактором? это же удобство пользователя!

да, еще тут было сказано, что из-за этого вперед вылезут «дорогие» сайты? я тоже не согласен. не обязательно иметь сверхдорогой сервер, можно просто хорошо оптимизировать свой код.

в общем, любое начинание может быть как позитивным, так и негативным, но пока Гуглу подобные вещи удавались, так что я только за
НЛО прилетело и опубликовало эту надпись здесь
а что мешает пользоваться CDN?
НЛО прилетело и опубликовало эту надпись здесь
полмегабайта скриптов против грамотно соптимизированых 10 килобайт не спасет даже CDN
Снова панику подняли без повода.

Почему-то многие посчитали, что гугл «забудет» о основных факторах влияющих на PR сайтов, а будет ранжировать сайты только по скорости загрузки. Всё будет по-старому, только медленных сайтов останется меньше и веб-мастеры озаботятся о оптимизации скорости загрузки.
А главное, все (пользователи, владельцы сайтов, поисковики) выйграют ;)
Спасибо тебе, Google. За то, что ты мне дал работу. Теперь наконец-то появится реальный спрос на быстыре и дорогие VPS.
Наконец, мы идём к тому, что профессия вебмастера и иже с ней будут действительно квалицифированными, тяп-ляп не прокатит.
> Мол, это может привести к ещё большему разделению веба, потому что более крупные и богатые сайты получат преимущество над остальными.

Правильно, нефиг делать сайты на Друпале с кучей модулей, на шаред хостинге.
Вот точная цитата из западных источников:
«while slow page load times won't negatively impact your rankings, fast load times may have a positive effect»
— медленная загрузка страниц не повлияет негативно на Ваш ранкинг(если конечно не настолько медленно что помешает самой индексации сайта роботом -прим.) Быстрая же загрузка сайта, я так понимаю, просто станет одним из сотен значением в алгоритме ранжирования.
Кстати, Мейли Ойи из команды Гугл еще давно говорила чтоб «seo folks» следили за скоростью загрузки страниц своих сайтов.
Ну в adWords они уже давно включили скорость загрузки сайта в набор quality scores, т.е. величины, которые влияют в конечном счете на стоимость клика. Поэтому влияние скорости загрузки сайта на ранжирование такового в SERP-е более чем ожидаемо.
изумительно ) Как же в тему тогда придется Web Optimizer
Это что же получается — использую jQuery — не видать первого места по запросу «Усть-Ордынские веники от производителя»?
Причём здесь jQuery?
Хороший плагин для Firebug Page Speed. Весь вечер сидел оптимизировал сайт на HostCMS :) Визуально стал бегать быстрее. Остался главный вопрос — как разрешить браузеру кэшировать файлы с сайта? Согласно code.google.com/intl/ru/speed/page-speed/docs/caching.html в заголовке ответа сервера должен быть атрибут Last-Modified или Expires. У меня такого нет. Значит они не кэшируются? Вроде бы грузятся каждый раз снова. Время жизни у css стоит очень маленькое. У картинок вообще нет таких параметров. Как добавить атрибуты? Просить хостера настроить Apache?
в .htaccess что-то наподобие

ExpiresActive on
ExpiresByType image/jpeg «access plus 1 month»
ExpiresByType image/gif «access plus 1 month»
ExpiresByType image/png «access plus 1 month»
ExpiresByType application/x-javascript «access plus 1 month»
ExpiresByType text/css «access plus 1 month»
ExpiresByType text/html «now»

Ну, может не у всех сработать, нужен соотв. модуль апача
Не сработало. Я заметил что у меня есть Etag там. Он не заменяет Expires?
Etag это хеш даты изменения и размера файла кажется. Если он не меняется, браузер берёт файл из кеша. Но проверка Etag'а всё равно проходит по HTTP.
А как сделать чтобы браузер не проверял пока не закончится время жизни?
или в nginx в соотвествующем локейшене для графики:
expires max;
Получается, что все флеш сайты будут терять значимость при поиске?
Логичнее было бы показывать скорость загрузки страницы в результатах поиска.
Пользователь вправе решать какое время в ожидании для него приемлемо.
Хм. Гугл отжигает своими нововведениями каждую неделю, если не каждый день
Только я не понял, надо плакать или смеяться :(
Обновлять резюме.
Пока кто-то будет париться с «загрузками», СЕОшники будуть продолжать скупать гамноссылки в САПЕ и покорять ТОПы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации