Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 113
Уже кстати давненько для Firebug`a есть дополнение PageSpeed от гугла, весьма полезная штука
Российская версия для Яндекса — учитывать для ранжирования аттестацию сайта, которую проводит ФСБ.
и персональные блоги с уникальным контентом на виртуальных хостингах отранжируются ниже, чем ресурсы более богатых копирастов на вдс или дедиках?
Или страницы, находящиеся на серверах в США, отранжируются выше, чем находящиеся на серверах в других странах, на отдалении 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
Потом 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
Короче, сайты Гугла будут на первых позициях. :)
Еще бы Гугл учитывал КПД сайта, соотношение полезного контента с баннерным в ранжировке.
Весьма сомнительная мера. Если мне действительно нужна информация, то скорость загрузки вряд ли будет иметь большое значение.
В любом случае, уверен, что этот показатель не будет играть решающую роль при определении позиции.
В любом случае, уверен, что этот показатель не будет играть решающую роль при определении позиции.
Хм, почему бы пользователю самому не настраивать факторы влияющие на ранжирование? Поисковик будущего?!!!
Дружно ставим на свои сайты Web Optimizer :)))
Я не думаю, что степень влияния этого нового фактора на ранжирование будет слишком велика
Наверное речь идет о том, что ссылка на скачивание файла размером 500 мб будет ранжировать выше тот сайте где выше скорость.
… будет учитывать не только релевантность контента и PR...
А разве PR учитывается при поисковой выдаче Гуглом?
PR уже давно (как минимум полтора месяца) не учитывается при ранжировании. Теперь играет роль чего-то на подобии Alexa rank.
Тоесть если он и влияет на ранжирование то очень слабо.
Тоесть если он и влияет на ранжирование то очень слабо.
Тогда зачем нужен PR?
Разве что как пузомерка. PR раньше оценивал количество и качество линков на сайт. Сейчас те же параметры работают в алгоритме, просто немного изменились и изменилось их влияние.
Из Google Webmaster Tools PR уже удалили.
Из Google Webmaster Tools PR уже удалили.
Из комментариев гугла мне стало ясно, что в webmaster tools PR был убран именно по причине того, чтобы не быть пузомеркой.
Возможно, PR до сих пор учитывается как и прежде. Только он, конечно, не единственный фактор ранжирования.
Поэтому нет смысла выделять его отдельно в webmaster tools.
Возможно, PR до сих пор учитывается как и прежде. Только он, конечно, не единственный фактор ранжирования.
Поэтому нет смысла выделять его отдельно в webmaster tools.
Я согласен что вполне вероятно что PR учитывается. Просто судя по интервью сотрудников гугла, которые смотрел в последнее время — PR как таковой становится все менее важным. Факторы, которые учитываются при определении PR и сейчас играют свою роль при ранжировании.
Сейчас он стает играть роль более аналитического инструмента. Тоесть наращивать PR ради PRа уже давно не имеет смысла.
А вот для определения жырности ссылок его все еще можно использовать, ведь если у страницы большой PR, это значит что у нее много бэклинков и она обладает у поисковиков определенным трастом. Соответственно с нее иметь ссылку лучше чем со страницы с теми же параметрами но с PR пониже.
P.S. среди рейтингов факторов ранжирования можно даже найти alexa rank.
Сейчас он стает играть роль более аналитического инструмента. Тоесть наращивать 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
Оптимизировать лишь один из сигналов было бы странным.
Так же как и скорость загрузки — один из сигналов. Данный сигнал гораздо более важный (при учёте, что контент хороший, конечно же) для владельцев сайтов, т.к. иначе посетители будут уходить.
Исследование на эту тему:
Google: увеличение latency на 400ms, на 0.6% уменьшение количества поисков
Bing: увеличение latency на 2s, на 4.3% уменьшение прибыли
en.oreilly.com/velocity2009/public/schedule/detail/8523
страничка «Hello, word!» будет в верхних строчках)))
По моему это тупо. Какая разница сколько весит страница, если на ней есть ценная информация?
Я думаю, будет не тупая прямая зависимость скорости загрузки.
Позиция будет зависеть от формулы, вроде этой:
скорость загрузки * n (чем выше тем хуже)
где n — количество «очков» за единицу времени — чем сложней сайт, тем меньше n. Сложность сайта должна быть в разумных пределах, конечно же. n тоже может иметь не прямо пропорциональную зависимость от кол-ва элементов на странице.
Позиция будет зависеть от формулы, вроде этой:
скорость загрузки * n (чем выше тем хуже)
где n — количество «очков» за единицу времени — чем сложней сайт, тем меньше n. Сложность сайта должна быть в разумных пределах, конечно же. n тоже может иметь не прямо пропорциональную зависимость от кол-ва элементов на странице.
Не очень хорошая затея, ведь нагрузка в разное время разная, и если робот зайдёт на сайт при высокой нагрузке естественно возможна долгая загрузка страницы, из-за этого терять PR?
В принципе, это вполне логичный шаг, ведь какой прок с ценной информации на сайте, если страница грузится полчаса? Вполне нормально, что перед ней в результатах поиска можно показывать страницу с таким же контентом, который загружается быстрее.
Хмм… с одной стороны логично, Google и Мэтт Каттс молодцы, стараются сделать полезное людям. Но с другой стороны, много ли страниц найдется с одинаковым контентом и со значительной разницей во времени загрузке, копипаст это се таки не хорошо, и его не должно быть в выдаче. Да и в любом случае, если этот фактор и будет использоваться, то далеко не во всех случаях, и он скорей всего будет заключительным и корректирующим, после всех остальных факторов ранжирования.
А конкурентам могут забивать канал.
Это уже ДДОС.
Ну может хоть примут системные меры по борьбе с ДДОСом.
Мое предложение: на всех центральных магистральных каналах, ловить ДДОСеров. При нарушении — показывать страничку, мол бросайте это дело. При последующих — бан на несколько часов.
Можно сделать, для упрощения, это на уровне сетей: если автономная система не может подавить ДДОСерский трафик из себя, временно отключать ее от сети. Так даже правильнее, и более соответствует децентрализованной структуре сети. А уж внутри сетей админы пусть сами выявляют злодеев.
А то сейчас владельцы сайтов оствлены один на один с проблемой, а хостер в лучшем случае закороет аккаунт и предложит переехать.
Мое предложение: на всех центральных магистральных каналах, ловить ДДОСеров. При нарушении — показывать страничку, мол бросайте это дело. При последующих — бан на несколько часов.
Можно сделать, для упрощения, это на уровне сетей: если автономная система не может подавить ДДОСерский трафик из себя, временно отключать ее от сети. Так даже правильнее, и более соответствует децентрализованной структуре сети. А уж внутри сетей админы пусть сами выявляют злодеев.
А то сейчас владельцы сайтов оствлены один на один с проблемой, а хостер в лучшем случае закороет аккаунт и предложит переехать.
Никаких конфликтов небудет
Провайдеры выпускают мусор потому что им лень отслеживать аномальную активность
Будет как со спамом — провайдеры банят тех, кто шлет спам
Буду банить и за DDOS.
Провайдеры выпускают мусор потому что им лень отслеживать аномальную активность
Будет как со спамом — провайдеры банят тех, кто шлет спам
Буду банить и за DDOS.
Почему? Провайдер показывает такому юзеру на любой запрос картинку с объяснением, в чем тот виноват, и предложением вылечить компьютер.
Хотя сейчас я подумал, правильнее защищаться все же на уровне хостингов, т.е. перед входом на хостинг должен стоять счетчик запросов, а владелец сайта в панели управления ставит лимиты на число коннектов с 1 IP/1 подсети, и какой-то API для того, чтбы сайт/его владелец могли банить негодяев.
Возможно, также, если атака идет преимущественно из 1 региона (подсети), динамически сужать скорость канала в тот регион (т.е ограничивать трафик на/с той подсети), в большом датацентре с десятками тысяч сайтов это бы снижало нагрузку на сервера.
Банить зомби все таки не получится, так как найдутся всякие военные, которые не позволят себя отключать, или какие-нибудь китайцы, которых миллиард человек и котрым пофиг на все абузы.
Хотя сейчас я подумал, правильнее защищаться все же на уровне хостингов, т.е. перед входом на хостинг должен стоять счетчик запросов, а владелец сайта в панели управления ставит лимиты на число коннектов с 1 IP/1 подсети, и какой-то API для того, чтбы сайт/его владелец могли банить негодяев.
Возможно, также, если атака идет преимущественно из 1 региона (подсети), динамически сужать скорость канала в тот регион (т.е ограничивать трафик на/с той подсети), в большом датацентре с десятками тысяч сайтов это бы снижало нагрузку на сервера.
Банить зомби все таки не получится, так как найдутся всякие военные, которые не позволят себя отключать, или какие-нибудь китайцы, которых миллиард человек и котрым пофиг на все абузы.
Применять Ajax — отличный способ увеличить «скорость интернета».
И если бы поисковики научились сначала аяксовые сайты индексировать, а потом уже ранжировали по скорости, было бы логичнее.
И если бы поисковики научились сначала аяксовые сайты индексировать, а потом уже ранжировали по скорости, было бы логичнее.
Если бы вебмастера научились писать правильные ajax-сайты, было бы намного проще. Всем.
Что вам мешает делать индексируемые аяксовые сайты?
В большинстве случаев это не так сложно…
<a href="/page" onclick=«ajax_load(this); return false;»>Ссылко</a>
Посмотрите в сторону плагина ajaxify для JQuery www.dom111.co.uk/blog/coding/jquery-ajaxify-update/191
В большинстве случаев это не так сложно…
<a href="/page" onclick=«ajax_load(this); return false;»>Ссылко</a>
Посмотрите в сторону плагина ajaxify для JQuery www.dom111.co.uk/blog/coding/jquery-ajaxify-update/191
И ведь тут хорошо всем — и поисковикам и параноикам без яваскрипта…
А кто Вам сказал, что мне что-то мешает?
Я говорю о СКОРОСТИ !!!
Аяксовый сайт работает быстрее, чем статический. А поисковик не видит этого.
Хуже того, он будет считать аяксовый сайт более медленным, так как он на каждую страницу грузит скрипты, необходимые для реализации аякса.
Ну и поскольку я вообще работаю с Extjs (не делаю сайты), то поисковик на моих страницах видит только пустой
Я говорю о СКОРОСТИ !!!
Аяксовый сайт работает быстрее, чем статический. А поисковик не видит этого.
Хуже того, он будет считать аяксовый сайт более медленным, так как он на каждую страницу грузит скрипты, необходимые для реализации аякса.
Ну и поскольку я вообще работаю с Extjs (не делаю сайты), то поисковик на моих страницах видит только пустой
у аяксового сайта загрузка первой страницы будет медленнее, чем у статического. а большинство переходов с гугла будут именно на «первую страницу». и после первой страницы пользователи уйдут. так что пользы от вашего аякса приходящим с гугла не будет.
Во-первых, аякс — не мой.
Во-вторых, при нормальном показателе отказа, с первой страницы уходит меньше 50% посетителей.
В третьих, то, что большинство переходов с гугла идет на главную — в большинстве случаев говорит о не верном подходе к оптимизации сайта. Не стоит путать «самую посещаемую страницу» и «большинство посетителей».
Ну и последнее: я не делаю сайты с содержанием, которое грузится аяксом. Не стоит персонализировать мой комментарий.
Во-вторых, при нормальном показателе отказа, с первой страницы уходит меньше 50% посетителей.
В третьих, то, что большинство переходов с гугла идет на главную — в большинстве случаев говорит о не верном подходе к оптимизации сайта. Не стоит путать «самую посещаемую страницу» и «большинство посетителей».
Ну и последнее: я не делаю сайты с содержанием, которое грузится аяксом. Не стоит персонализировать мой комментарий.
Читаем здесь: stevesouders.com/docs/amazon-20091030.pptx (или вообще книги Souders'а) и не позоримся
Откуда информация, что поисковик «на каждую страницу грузит скрипты, необходимые для реализации аякса»?
Бедные сайты на флеше :(
полезность информации намного важнее скорости доступа к ней…
это полезно разве что в ситуации, когда контент клонируется — когда при попытке зайти на основной сайт приходится долго ждать, дольше, чем с сайта-копипастера… но, согласитесь, не по понятиям это ставить основной источник информации ниже копипастера только потому что у последнего скорость больше получается…
это полезно разве что в ситуации, когда контент клонируется — когда при попытке зайти на основной сайт приходится долго ждать, дольше, чем с сайта-копипастера… но, согласитесь, не по понятиям это ставить основной источник информации ниже копипастера только потому что у последнего скорость больше получается…
Может быть, Гугл свой вебсервер (GWS) планирует развивать или что-то новое придумает… что-то, что могло бы потеснить Apache…
а то… к чему все это… не верится, что всё это без задней мысли делается…
а то… к чему все это… не верится, что всё это без задней мысли делается…
ага, SPDY? :)
«задняя мысль» вполне себе открыта: code.google.com/speed/
цель сделать интернет быстрее. чтобы люди больше могли поисковых запросов за день в гугл вбить
цель сделать интернет быстрее. чтобы люди больше могли поисковых запросов за день в гугл вбить
Когда я ищу рецепт яичницы, способ использования сеттеров в IE или время старта Атлантиса, мне, как пользователю, всё равно, оригинал это будет или копипаста, мне главное — чтобы сайт быстро открылся и показал нужную информацию.
Как раз сегодня так и было — в Гуглоновостях написали про запрет последней Call Of Duty. Тыкнул на первую ссылку — подождал минуты две, сайт так и не загрузился. Тыкнул вторую ссылку — через полминуты пришёл html сайта, но без CSS и картинок. Ткнул на третью (PC Games Hardware) — открылось моментально.
Как раз сегодня так и было — в Гуглоновостях написали про запрет последней Call Of Duty. Тыкнул на первую ссылку — подождал минуты две, сайт так и не загрузился. Тыкнул вторую ссылку — через полминуты пришёл html сайта, но без CSS и картинок. Ткнул на третью (PC Games Hardware) — открылось моментально.
Народ, смотрю паника тут вовсю набирает обороты.
«Повлияет» — это не «будет зависеть только от»!
Думаю, в Гугл не идиоты, и ранжирование по скорости будет зависеть от множества факторов. Я думаю от скорости будет зависеть ранжирование именно между равноценными страницами.
Конечно, нюансов, наверное, будет много, но не думаю, что все так уж плохо.
«Повлияет» — это не «будет зависеть только от»!
Думаю, в Гугл не идиоты, и ранжирование по скорости будет зависеть от множества факторов. Я думаю от скорости будет зависеть ранжирование именно между равноценными страницами.
Конечно, нюансов, наверное, будет много, но не думаю, что все так уж плохо.
Да, идея хороша если Гугл к ней подойдет с умом. Если время загрузки — это некоторое абстрактное число, влияющее на скорость, с какой пользователь получит доступ к необходимой информации. В результате некоторые задумаются, грузить ли лишние скрипты, использовать ли спрайты, кеширование, верстать на таблицах или на дивах...)
Верно, об этом полезно задумываться (всегда :)).
А то в начале первых секунд загрузки пользователь смотрит на пустой (белый) экран.
Возьмите для сравнения сайт Amazon. Там информационные блоки отображаются достаточно бысто, а потом всё остальное загружается. И т.д.
А то в начале первых секунд загрузки пользователь смотрит на пустой (белый) экран.
Возьмите для сравнения сайт Amazon. Там информационные блоки отображаются достаточно бысто, а потом всё остальное загружается. И т.д.
Я вот сегодня заметил что спецификация по HTML5 (Editor: Ian Hickson, Google) активно продвигается Google. Может это тоже как-то связано? (ну в плане чтобы народ активно внедрял нативные элементы для видео и аудио, например, которые не требуют скриптовой начинки)…
я верю, что Гугл может подойти к такой проблеме грамотно
потому что
1) hello world будет выше всех? нет, она вообще не попадет в основной индекс, а будет болтаться в дополнительном
2) дорвеи… аналогично
3) клонирование контента? — они и так вполне отсеивают и определяют, где оригинал, не с клонами ранжирование идет
4) день да день не приходится? ddos? не обязательно такую статистику один день собирать, можно и среднее вычислить с откидыванием пиков
в общем, если уже идет сравнение достойных сайтов в основном индексе с похожим PR, то почему бы времени загрузки не стать решающим фактором? это же удобство пользователя!
да, еще тут было сказано, что из-за этого вперед вылезут «дорогие» сайты? я тоже не согласен. не обязательно иметь сверхдорогой сервер, можно просто хорошо оптимизировать свой код.
в общем, любое начинание может быть как позитивным, так и негативным, но пока Гуглу подобные вещи удавались, так что я только за
потому что
1) hello world будет выше всех? нет, она вообще не попадет в основной индекс, а будет болтаться в дополнительном
2) дорвеи… аналогично
3) клонирование контента? — они и так вполне отсеивают и определяют, где оригинал, не с клонами ранжирование идет
4) день да день не приходится? ddos? не обязательно такую статистику один день собирать, можно и среднее вычислить с откидыванием пиков
в общем, если уже идет сравнение достойных сайтов в основном индексе с похожим PR, то почему бы времени загрузки не стать решающим фактором? это же удобство пользователя!
да, еще тут было сказано, что из-за этого вперед вылезут «дорогие» сайты? я тоже не согласен. не обязательно иметь сверхдорогой сервер, можно просто хорошо оптимизировать свой код.
в общем, любое начинание может быть как позитивным, так и негативным, но пока Гуглу подобные вещи удавались, так что я только за
Снова панику подняли без повода.
Почему-то многие посчитали, что гугл «забудет» о основных факторах влияющих на PR сайтов, а будет ранжировать сайты только по скорости загрузки. Всё будет по-старому, только медленных сайтов останется меньше и веб-мастеры озаботятся о оптимизации скорости загрузки.
Почему-то многие посчитали, что гугл «забудет» о основных факторах влияющих на PR сайтов, а будет ранжировать сайты только по скорости загрузки. Всё будет по-старому, только медленных сайтов останется меньше и веб-мастеры озаботятся о оптимизации скорости загрузки.
Спасибо тебе, Google. За то, что ты мне дал работу. Теперь наконец-то появится реальный спрос на быстыре и дорогие VPS.
> Мол, это может привести к ещё большему разделению веба, потому что более крупные и богатые сайты получат преимущество над остальными.
Правильно, нефиг делать сайты на Друпале с кучей модулей, на шаред хостинге.
Правильно, нефиг делать сайты на Друпале с кучей модулей, на шаред хостинге.
Вот точная цитата из западных источников:
«while slow page load times won't negatively impact your rankings, fast load times may have a positive effect»
— медленная загрузка страниц не повлияет негативно на Ваш ранкинг(если конечно не настолько медленно что помешает самой индексации сайта роботом -прим.) Быстрая же загрузка сайта, я так понимаю, просто станет одним из сотен значением в алгоритме ранжирования.
Кстати, Мейли Ойи из команды Гугл еще давно говорила чтоб «seo folks» следили за скоростью загрузки страниц своих сайтов.
«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 — не видать первого места по запросу «Усть-Ордынские веники от производителя»?
Хороший плагин для 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»
Ну, может не у всех сработать, нужен соотв. модуль апача
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»
Ну, может не у всех сработать, нужен соотв. модуль апача
или в nginx в соотвествующем локейшене для графики:
expires max;
expires max;
Получается, что все флеш сайты будут терять значимость при поиске?
Логичнее было бы показывать скорость загрузки страницы в результатах поиска.
Пользователь вправе решать какое время в ожидании для него приемлемо.
Пользователь вправе решать какое время в ожидании для него приемлемо.
Хм. Гугл отжигает своими нововведениями каждую неделю, если не каждый день
Только я не понял, надо плакать или смеяться :(
Только я не понял, надо плакать или смеяться :(
Пока кто-то будет париться с «загрузками», СЕОшники будуть продолжать скупать гамноссылки в САПЕ и покорять ТОПы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скорость загрузки страниц повлияет на ранжирование