Тут недавно про безопасность рассуждали и пришли к выводу что всем пофиг.

А как на счет ошибок скриптов, битых ссылок, скорости отдачи, валидности кода? Давно вы secure и error.log смотрели? Держит ваш сайт нагрузку или вы ждете когда добрый дядя хостер намекнет, что пора взять тариф подороже?

Вот жалуетесь здесь, что продажи пропали и виноват в этом Плимус, а вы уверены что проблема не в вашем сайте?

Здравствуйте, icezone, Вы писали:

Мне недавно хостер написал, что мои MySQL-запросы используют слишком много памяти и дает несколько дней, чтобы исправить. Стал спешно искать в чем же дело, решилось добавлением mysql_free_result($result); после каждого запроса.

Здравствуйте, icezone, Вы писали:

I>Тут недавно про безопасность рассуждали и пришли к выводу что всем пофиг.

I>А как на счет ошибок скриптов,

нет скриптов

I>битых ссылок,

проверяем иногда

I>скорости отдачи,

не меряли

I> валидности кода?

пох. рендерится и ладно

I>Давно вы secure и error.log смотрели?

У нас выключен логгинг. Логи имеют тенденцию постепенно и незаметно забивать весь винт за пару лет, а я так за последние может три года в них ни разу и не смотрел.

I>Держит ваш сайт нагрузку или вы ждете когда добрый дядя хостер намекнет, что пора взять тариф подороже?

Держит сколько надо

I>Вот жалуетесь здесь, что продажи пропали и виноват в этом Плимус, а вы уверены что проблема не в вашем сайте?

не жалуюсь

I>Тут недавно про безопасность рассуждали и пришли к выводу что всем пофиг.

хз, кому как. мне не пофиг.

I>А как на счет ошибок скриптов,

нет ошибок.

I>битых ссылок,

нет

I>скорости отдачи,

нагрузка не большая. с головой хватает.

I>валидности кода?

это так важно?

I>Давно вы secure и error.log смотрели?

раз в месяц

I>Держит ваш сайт нагрузку или вы ждете когда добрый дядя хостер намекнет, что пора взять тариф подороже?

нагрузка не большая

I>Вот жалуетесь здесь, что продажи пропали и виноват в этом Плимус, а вы уверены что проблема не в вашем сайте?

не жалуюсь. вместо этого пыхчу над новыми версиями/проектами, тогда и просиданий не будет.

Здравствуйте, Sharowarsheg, Вы писали:

S>нет скриптов

Завидую. Все на статике?

I>>скорости отдачи,
S>не меряли

А она, между прочим, влияет и на выдачу поисковиков и на ресурсы сервера.

S>пох. рендерится и ладно

Тут почти согласен, хотя я не стану покупать на сайте у которого верстка поехала. А вы?

S>У нас выключен логгинг. Логи имеют тенденцию постепенно и незаметно забивать весь винт за пару лет, а я так за последние может три года в них ни разу и не смотрел.

Зря. Там есть много интересного.

S>Держит сколько надо

Как определил? Ты же логи не смотришь.

S>не жалуюсь

И это правильно!

Здравствуйте, ProgExplorer, Вы писали:

PE>Мне недавно хостер написал, что мои MySQL-запросы используют слишком много памяти и дает несколько дней, чтобы исправить. Стал спешно искать в чем же дело, решилось добавлением mysql_free_result($result); после каждого запроса.

Странно:

mysql_free_result() only needs to be called if you are concerned about how much memory is being used for queries that return large result sets. All associated result memory is automatically freed at the end of the script's execution.

Здравствуйте, icezone, Вы писали:

I>А как на счет ошибок скриптов
два сайта, один на shtml, второй использует php, тестировал, ошибок не обнаружил.

I>битых ссылок
Все внешние неправильные ссылки перенаправляю на правильные с помощью с помощью htaccess, внутренние без ощибок

I>скорости отдачи
От меня мало зависит

I>валидности кода?
Вылизано как у кота яйки

I>Давно вы secure и error.log смотрели?
Раз в неделю

I>Держит ваш сайт нагрузку или вы ждете когда добрый дядя хостер намекнет, что пора взять тариф подороже?
Нагрузка небольшая

> А она, между прочим, влияет и на выдачу поисковиков и на ресурсы сервера.

Можно подробнее? Сомневаюсь, что скорость отдачи влияет на сайты <100 страниц.

Здравствуйте, grosborn, Вы писали:

G>Можно подробнее? Сомневаюсь, что скорость отдачи влияет на сайты <100 страниц.

Если про влияние скорости на выдачу, то это из гайдов самого Гугла.
Если про влияние на сервер, то ситуции разные бывают. Апач на ВПС можно легко уложить и одним запросом.
Я, собственно, не просто так разговор завел — недавно наблюдал на одном VPS 118 процессов Апача.

> G>Можно подробнее? Сомневаюсь, что скорость отдачи влияет на сайты <100 страниц.
>
> Если про влияние скорости на выдачу, то это из гайдов самого Гугла.

Я попросил подробнеее, поскольку не встречал достоверных данных на этот счет. Написать они могут что угодно, но это не значит, что так оно и есть.
Пропорциональной зависимости, значительной зависимости для мелких сайтов, быть не может, поскольку это давало бы совершенно неправильные развесовки. Какая-то зависимость все-таки думаю есть, раз они это упоминают, но где об этом прочитать я не знаю.

Здравствуйте, AnonThisTime, Вы писали:

ATT>хз, кому как. мне не пофиг.

Брутфорсят часто? Я таки сподобился поставить нормальный файрвол.

ATT>нагрузка не большая. с головой хватает.

Время загрузки страницы тоже имеет значение.

I>>валидности кода?
ATT>это так важно?

В принципе пофиг, так до кучи спросил.

I>>Давно вы secure и error.log смотрели?
ATT>раз в месяц

Правильный подход.

ATT>нагрузка не большая

Какой тип хостинга? Шаред, дедик или ВПС?

ATT>не жалуюсь. вместо этого пыхчу над новыми версиями/проектами, тогда и просиданий не будет.

А я уже неделю сервер кручу, кто-то балуется по выходным.

Здравствуйте, Aniskin, Вы писали:

A>два сайта, один на shtml, второй использует php, тестировал, ошибок не обнаружил.

Я сам не обнаружил, зато боты помогли. Перебором долбили и посыпались PHP варнинги.

I>>скорости отдачи
A>От меня мало зависит

Неправда. Практически любой сайт можно ускорить раза в два даже на шареде.

I>>валидности кода?
A>Вылизано как у кота яйки

Завидую. Кнопки социалок много ошибок валидации дают.

I>>Давно вы secure и error.log смотрели?
A>Раз в неделю

Нифига себе.

A>Нагрузка небольшая

Почему у всех нагрузка небольшая? Я вот тоже думал, что у меня запас в несколько раз,
но Апач периодически начал выжирать всю память.
Попробуй вот эту штучку http://loadimpact.com/

Здравствуйте, grosborn, Вы писали:

G>Я попросил подробнеее, поскольку не встречал достоверных данных на этот счет. Написать они могут что угодно, но это не значит, что так оно и есть.
G>Пропорциональной зависимости, значительной зависимости для мелких сайтов, быть не может, поскольку это давало бы совершенно неправильные развесовки. Какая-то зависимость все-таки думаю есть, раз они это упоминают, но где об этом прочитать я не знаю.

Подробнее знает только Гугл. Не зря они в WMT показывают скорость загрузки и плагины для этого выпустили.

Здравствуйте, icezone, Вы писали:

I>Почему у всех нагрузка небольшая? Я вот тоже думал, что у меня запас в несколько раз,

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

I>но Апач периодически начал выжирать всю память.

на чём именно (скрипты/файлы)? у тебя nginx спереди есть? апач worker или threaded?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>в несколько раз — это как? а если напишут где и хаброэффект нагрянет? я дума., запас от текущей нагрузки должен быть раз в сто, это недорого

Хабраэффект не испытывал, но раньше держал Диггэффект, а недавно бразильцы устроили мне карнавал на вордпрессовском сайте. Все устояло.

BZ>на чём именно (скрипты/файлы)? у тебя nginx спереди есть? апач worker или threaded?

Вот тут дело темное. Энджинкса нет, все по дефолту — Апач воркер и панелька Плеск.
Ошибок PHP/MySQL нет, посещаемость обычная. Пока курю логи.
Либо кто-то балуется, либо бот тупой попался.

Здравствуйте, icezone, Вы писали:

I>Вот тут дело темное. Энджинкса нет, все по дефолту — Апач воркер и панелька Плеск.

число воркеров = keepalive (в секундах) * req/s

если у тебя стандартный keepalive в 60 сек. и число запросов в секунду хоть изредка доходит до 10 (и держится так целую минуту), то число воркеров может доходить до 600. а каждый из них, как я понял из top, жрёт мег 20

я же говорил, что апач воркер — это несерьёзно

Здравствуйте, Sharowarsheg, Вы писали:

I>> валидности кода?

S>пох. рендерится и ладно

Главное, что бы программы не писались по принципу "компилируется и ладно"

Здравствуйте, icezone, Вы писали:

A>>два сайта, один на shtml, второй использует php, тестировал, ошибок не обнаружил.

I>Я сам не обнаружил, зато боты помогли. Перебором долбили и посыпались PHP варнинги.

У меня тоже долбят, но за два года так и не надолбили ничего.

I>>>скорости отдачи
A>>От меня мало зависит

I>Неправда. Практически любой сайт можно ускорить раза в два даже на шареде.

Как можно ускорить сайт на shtml?

I>Завидую. Кнопки социалок много ошибок валидации дают.

Согласен, но можно проверить без них, а когда ошибок нет, добавить.

A>>Нагрузка небольшая

I>Почему у всех нагрузка небольшая? Я вот тоже думал, что у меня запас в несколько раз,
I>но Апач периодически начал выжирать всю память.
I>Попробуй вот эту штучку http://loadimpact.com/

Спасибо, поиграю.

Здравствуйте, icezone, Вы писали:

S>>нет скриптов

I>Завидую. Все на статике?

Годы в копирайтах на ASP.NET.
Поддержка активации на ASP.NET.

I>>>скорости отдачи,
S>>не меряли

I>А она, между прочим, влияет и на выдачу поисковиков и на ресурсы сервера.

Выдачу смотрели, там очевидны другие проблемы

S>>пох. рендерится и ладно
I>Тут почти согласен, хотя я не стану покупать на сайте у которого верстка поехала. А вы?

У нас верстка не поехала, но и не валидируется.

S>>Держит сколько надо
I>Как определил? Ты же логи не смотришь.

На Task Manager смотрю иногда.

Здравствуйте, icezone, Вы писали:

Очень серьезно. Сайт проксируется через https://www.cloudflare.com/, он же и CDN, он же собирает весь javascript в один файл и делает его асинхронным так что он не влияет на скорость загрузки сайта, он же и за безопасность отвечает — по логам видно что отбивает спамеров и ботов. Держит нагрузку в 100 одновременных подключений на http://loadimpact.com/ больше не тестировал, потому что не нужно, но график вверх не загибался, потому и больше может. Пинги равномерно низкие со всего мира — это из-за CDN.
Сайт на Drupal, всевозможные кеши включены, оптимизации сделаны, картинки пожаты через Image Catalyst 2.0 и загнаны в CSS через DataURI.
Page Speed Grade:91%, YSlow Grade:94%
Количество запросов который посылает браузер при первой загрузке 15 (466.1K) — 2.16s, при всех последующих — 6 (23.3K) — 1.17s (потому что гружу 3 разных счетчика), и это до полной загрузки со скриптами, а до отображения (то есть то что видит человек) и того меньше — 968ms.

Верстка не валидная из-за кнопок социалок, но точно не едет даже в ie6, разве что картинки с прозрачностью хуже выглядят и кнопки на css3 попроще становятся

А теперь самое интересное — всё это на шареде http://www.ukraine.com.ua/ за 15$ в год! Больше ни за что я не плачу (ну кроме домена . Изначально тариф был 10$/год, но я докупал место, как потом оказалось лишнее, потому что старый кеш по крону не чистился

Здравствуйте, icezone, Вы писали:

G>>Я попросил подробнеее, поскольку не встречал достоверных данных на этот счет. Написать они могут что угодно, но это не значит, что так оно и есть.
G>>Пропорциональной зависимости, значительной зависимости для мелких сайтов, быть не может, поскольку это давало бы совершенно неправильные развесовки. Какая-то зависимость все-таки думаю есть, раз они это упоминают, но где об этом прочитать я не знаю.

I>Подробнее знает только Гугл. Не зря они в WMT показывают скорость загрузки и плагины для этого выпустили.

Если бы я был гуглом, я бы выпускал плагины для любой чухни, в том числе keyword density. Специально занял бы пару человек придумыванием всякого бутора, типа влияния версии вебсервера на выдачу, чтобы сеошники велись и тратили силы почем зря.

Здравствуйте, Sharowarsheg, Вы писали:

S>Если бы я был гуглом, я бы выпускал плагины для любой чухни, в том числе keyword density. Специально занял бы пару человек придумыванием всякого бутора, типа влияния версии вебсервера на выдачу, чтобы сеошники велись и тратили силы почем зря.

Зря ты так думаешь. Ты разве не согласен, что медленные сайты раздражают посетителей?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>число воркеров = keepalive (в секундах) * req/s

keepalive выключен

BZ>если у тебя стандартный keepalive в 60 сек. и число запросов в секунду хоть изредка доходит до 10 (и держится так целую минуту), то число воркеров может доходить до 600. а каждый из них, как я понял из top, жрёт мег 20

Да, примерно 11-25 мегабайт на процесс. Доходит до 118 воркеров.

BZ>я же говорил, что апач воркер — это несерьёзно

Знаю, но дружить Плеск с Энджинксом — гиблое дело. Нужен хороший бубен.

Здравствуйте, Aniskin, Вы писали:

A>Как можно ускорить сайт на shtml?

Включить сжатие на стороне сервера и склеить картинки в спрайты.
Каждый элемент страницы создает отдельный запрос к серверу, поэтому куча мелких картинок — зло.

Здравствуйте, BrutForce, Вы писали:

BF>А теперь самое интересное — всё это на шареде http://www.ukraine.com.ua/ за 15$ в год! Больше ни за что я не плачу (ну кроме домена . Изначально тариф был 10$/год, но я докупал место, как потом оказалось лишнее, потому что старый кеш по крону не чистился

У меня все тянет свой VPS, но следить за всем приходится самому.

> A>Как можно ускорить сайт на shtml?
>
> Включить сжатие на стороне сервера и склеить картинки в спрайты.
> Каждый элемент страницы создает отдельный запрос к серверу, поэтому куча мелких картинок — зло.

Нет смысла. Со статическими картинками вообще проблем нет. Те что грузятся асинхронно, практически все, их можно вообще вынести на отдельный сервер или кластеризовать на централизованно управляемых серверах провайдера. Большие картинки можно подогнать ближе к потребителю, за копейки. Но таких потребностей вообще единицы, надуманная проблема.
Разбирать спрайты на клиентской стороне, мапить или что еще там с ними делать, это как-то не очень.

Здравствуйте, grosborn, Вы писали:

G>Нет смысла. Со статическими картинками вообще проблем нет. Те что грузятся асинхронно, практически все, их можно вообще вынести на отдельный сервер или кластеризовать на централизованно управляемых серверах провайдера. Большие картинки можно подогнать ближе к потребителю, за копейки. Но таких потребностей вообще единицы, надуманная проблема.

Использовать CDN или отдельный сервер ради двух-трех десятков картинок?

G>Разбирать спрайты на клиентской стороне, мапить или что еще там с ними делать, это как-то не очень.

Ты о чем? Спрайт делается один раз прописывается в CSS. Больше ничего не требуется. Это всего пол часа работы.

Вот тебе небольшой пример — после склеивания картинок в спрайты количество хитов уменьшилось на 600.000 в месяц.

> Использовать CDN или отдельный сервер ради двух-трех десятков картинок?

Я думал ты о задаче, с большим количеством картинок, если скажем сайт картинок.
Но в таком примере CDN тоже не подходит. CDN это для корпоративных сайтов или больших сайтов со смешанными данными. Для просто библиотеки картинок самое эффективное это разложить на хостингах по 1$ в месяц/хост.


> Вот тебе небольшой пример — после склеивания картинок в спрайты количество хитов уменьшилось на 600.000 в месяц.

И что? Какие размеры? Операция отдачи картинок малозатратная, в отличие от отдачи страницы, там только файловая операция и сессия не висит, и не блокируется, и кэшируется. И если в кэш хорошо попадает, то и вообще отдается со скоростью канала.

Здравствуйте, grosborn, Вы писали:

G>Для просто библиотеки картинок самое эффективное это разложить на хостингах по 1$ в месяц/хост.

Зачем такой геморрой? Склеить один раз и все.

G>И что? Какие размеры? Операция отдачи картинок малозатратная, в отличие от отдачи страницы, там только файловая операция и сессия не висит, и не блокируется, и кэшируется. И если в кэш хорошо попадает, то и вообще отдается со скоростью канала.

Объяем трафика не меняется, но сервер может обслужить большее количество клиентов, а страница загружается на секунду быстрее.
Чем отличается отдача страницы в 20 килобайт от картинки того же размера? Как поможет кеш при первом визите?

Здравствуйте, icezone, Вы писали:

S>>Если бы я был гуглом, я бы выпускал плагины для любой чухни, в том числе keyword density. Специально занял бы пару человек придумыванием всякого бутора, типа влияния версии вебсервера на выдачу, чтобы сеошники велись и тратили силы почем зря.

I>Зря ты так думаешь. Ты разве не согласен, что медленные сайты раздражают посетителей?

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

> G>Для просто библиотеки картинок самое эффективное это разложить на хостингах по 1$ в месяц/хост.
>
> Зачем такой геморрой? Склеить один раз и все.

Не читаешь. Я же написал не про склейку картинок темы оформления сайта.
Или же ты предлагаешь склеивать все картинки на сайте? Ну это как-то совсем уже нетрадиционно.

> Объяем трафика не меняется, но сервер может обслужить большее количество клиентов, а страница загружается на секунду быстрее.
> Чем отличается отдача страницы в 20 килобайт от картинки того же размера? Как поможет кеш при первом визите?

Ну я не знаю, в каждом случае зависит от контента. Если shtml там разница небольшая. Если динамика php, то разница может быть в сотни раз.

Здравствуйте, grosborn, Вы писали:

G>Не читаешь. Я же написал не про склейку картинок темы оформления сайта.

Читаю. Как раз картинки от темы и склеивают.

G>Или же ты предлагаешь склеивать все картинки на сайте? Ну это как-то совсем уже нетрадиционно.

Скриншоты нет смысла клеить.

G>Ну я не знаю, в каждом случае зависит от контента. Если shtml там разница небольшая. Если динамика php, то разница может быть в сотни раз.

Тушка Апача в 15-25 мегабайт в зависимости от контента. Даже однобайтовая картинка требует время на коннект и ожидание ответа от сервера.
А если еще и keepalive включен...

Здравствуйте, Sharowarsheg, Вы писали:

S>Одно другому не мешает. Тот факт, что медленные сайты раздражают посетителей, никак не отменяет того, что гуглю выгодно заниматься дезинформацией сеошников. Мои сайты достаточно быстрые, чтобы не раздражать меня, и я на этом достижении прекратил бороться за скорость. Оптимизировать можно вечно, и гугль, кажется, успешно занял этим много народу

Как-то совсем по-детски. То же самое можно сказать про умывание по утрам и чистку зубов

Здравствуйте, icezone, Вы писали:

S>>Одно другому не мешает. Тот факт, что медленные сайты раздражают посетителей, никак не отменяет того, что гуглю выгодно заниматься дезинформацией сеошников. Мои сайты достаточно быстрые, чтобы не раздражать меня, и я на этом достижении прекратил бороться за скорость. Оптимизировать можно вечно, и гугль, кажется, успешно занял этим много народу

I>Как-то совсем по-детски. То же самое можно сказать про умывание по утрам и чистку зубов

А как ты предлагаешь определять, в какой момент прекратить оптимизацию по скорости загрузки?

Здравствуйте, Sharowarsheg, Вы писали:

S>А как ты предлагаешь определять, в какой момент прекратить оптимизацию по скорости загрузки?

Да я не от том, а о причинах. Мол все это Гугл из вредности делает.

Здравствуйте, icezone, Вы писали:

S>>А как ты предлагаешь определять, в какой момент прекратить оптимизацию по скорости загрузки?
I>Да я не от том, а о причинах. Мол все это Гугл из вредности делает.

Не из вредности, а чтобы облегчить работу тем, кто делает алгоритм поиска. Denial and deception — дешево и эффективно, и глупо было бы с их стороны этого не делать. Даже мои конкуренты догадались в википедии в формуле поменять + на -, чтобы следующему было веселее разбираться, а уж в гугле и подавно должны сообразить.

Здравствуйте, Sharowarsheg, Вы писали:

S>Не из вредности, а чтобы облегчить работу тем, кто делает алгоритм поиска.

Как ускорение загрузки страницы поможет алгоритму поиска?

Здравствуйте, icezone, Вы писали:

I>Здравствуйте, Sharowarsheg, Вы писали:

S>>Не из вредности, а чтобы облегчить работу тем, кто делает алгоритм поиска.

I>Как ускорение загрузки страницы поможет алгоритму поиска?

робот будет меньше ждать загрузки страницы,
обойдет больше страниц за меньшее время
профит? (сомнительный, но все же)

Здравствуйте, шароварная желочь, Вы писали:

ШЖ>робот будет меньше ждать загрузки страницы,
ШЖ>обойдет больше страниц за меньшее время
ШЖ>профит? (сомнительный, но все же)

С какого перепугу? Зачем роботу ждать загрузки картинок?

Здравствуйте, icezone, Вы писали:

I>Здравствуйте, шароварная желочь, Вы писали:

ШЖ>>робот будет меньше ждать загрузки страницы,
ШЖ>>обойдет больше страниц за меньшее время
ШЖ>>профит? (сомнительный, но все же)

I>С какого перепугу? Зачем роботу ждать загрузки картинок?

Для поиска по картинкам. Картинку нужно грузить хотя бы для того, чтобы узнать ее размер.

Здравствуйте, icezone, Вы писали:

I>Как ускорение загрузки страницы поможет алгоритму поиска?

Не столько алгоритму поиска, сколько алгоритму ранжирования. Чем быстрее и доступнее сайт тем он выше в выдаче.

Здравствуйте, icezone, Вы писали:

S>>Не из вредности, а чтобы облегчить работу тем, кто делает алгоритм поиска.
I>Как ускорение загрузки страницы поможет алгоритму поиска?

Не алгоритму поиска, а программерам, которые пишут алгоритм поиска.
Сеошники, вместо того, чтобы заниматься делом (спамом), будут заниматься ускорением страниц.
Спама станет меньше, и спам станет менее разнообразным.
Соответственно гугловским программерам будет легче работать.

Здравствуйте, iconix, Вы писали:

I>Для поиска по картинкам. Картинку нужно грузить хотя бы для того, чтобы узнать ее размер.

Сама идея спрайтов появилась из-за ограничений бразуеров.
Боту пофиг на ограничения браузеров — он может скачать как захочет и когда захочет.

Здравствуйте, Miroff, Вы писали:

M>Не столько алгоритму поиска, сколько алгоритму ранжирования. Чем быстрее и доступнее сайт тем он выше в выдаче.

Меня с начала топика убеждают, что это вранье. Попробуете аргументировать?

Здравствуйте, Sharowarsheg, Вы писали:

S>Сеошники, вместо того, чтобы заниматься делом (спамом), будут заниматься ускорением страниц.
S>Спама станет меньше, и спам станет менее разнообразным.
S>Соответственно гугловским программерам будет легче работать.

Ты похоже не очень разбираешься в теме. На ускорение страниц можно потратить максимум один день в году. Как это повлияет на количество спама?
К тому же ты смешал в кучу сразу несколько профессий — админов, сеошников, верстальщиков и копирайтеров.

Здравствуйте, icezone, Вы писали:

S>>Сеошники, вместо того, чтобы заниматься делом (спамом), будут заниматься ускорением страниц.
S>>Спама станет меньше, и спам станет менее разнообразным.
S>>Соответственно гугловским программерам будет легче работать.

I>Ты похоже не очень разбираешься в теме. На ускорение страниц можно потратить максимум один день в году. Как это повлияет на количество спама?

Миллион спамеров на один день = миллион человеко-дней. Кроме того, в массе случаев одним днем не обошлось. Это когда ты уже знаешь, что такое CSS sprite, CDN, где взять халявную CDN, и проча, то можно уложиться в один день. Кроме того, я бы со нашими примерно 20-30 разными шаблонами сайтов не рискнул бы укладываться в день. Масса народу тратит на эту самую скорость недели и месяцы. Даже мы с тобой уже час потратили на трёп, а еще человек десять по пять минут на чтение каждый. И так в мировых масштабах, а всё потому, что кто-то из гугля написал "мы будем использовать скорость в ранжировании".


I>К тому же ты смешал в кучу сразу несколько профессий — админов, сеошников, верстальщиков и копирайтеров.

В большинстве случаев там, где поисковый спам, это всё одно и то же лицо.

> Сама идея спрайтов появилась из-за ограничений бразуеров.
> Боту пофиг на ограничения браузеров — он может скачать как захочет и когда захочет.

Боту не пофиг. Для гугла большая проблема отсканировать весь интернет, причем тормоза как со стороны ботов, так и с клиентской стороны. Конечно гуглу бы хотелось, что бы все быстренько отвечали своими страничками. Вот и пытаются простимулировать. Но снижать сайт в выдаче только потому, что по каким-то причинам начал тормозить хостинг, это портить выдачу. Существует масса тормозящих топовых сайтов. В том числе сами гугловские сайты тормозят безбожно. Интересно, себя они тоже в выдаче снижают?

А еще сайты, которые гугл сканирует ночью, будут подниматься в выдаче, а дневные падать. Может по этой причине и так много претензий к панде?

Здравствуйте, grosborn, Вы писали:

G>Боту не пофиг. Для гугла большая проблема отсканировать весь интернет, причем тормоза как со стороны ботов, так и с клиентской стороны.

Ты вообще понимаешь о чем разговор? Спрайты ничем боту не помогут, даже помешают.

> Ты вообще понимаешь о чем разговор? Спрайты ничем боту не помогут, даже помешают.

Это ты вещаешь что-то на своей волне и не читаешь, что тебе пишут.

Здравствуйте, Sharowarsheg, Вы писали:

S>Даже мы с тобой уже час потратили на трёп, а еще человек десять по пять минут на чтение каждый.

И о верно...

S>В большинстве случаев там, где поисковый спам, это всё одно и то же лицо.

Ты про школоту?

Здравствуйте, grosborn, Вы писали:

G>Это ты вещаешь что-то на своей волне и не читаешь, что тебе пишут.

Я начал разговор и представляю о чем речь.
Объясни на пальцах как спрайты помогут боту — очень интересно послушать.

Здравствуйте, icezone, Вы писали:

S>>Даже мы с тобой уже час потратили на трёп, а еще человек десять по пять минут на чтение каждый.
I>И о верно...

S>>В большинстве случаев там, где поисковый спам, это всё одно и то же лицо.
I>Ты про школоту?

Да нет вроде, я сам лет десять так работал. Сам себе кодер, писатель, вебмастер, админ, и всё остальное. Нормально справлялся вроде.

Здравствуйте, Sharowarsheg, Вы писали:

S>Да нет вроде, я сам лет десять так работал. Сам себе кодер, писатель, вебмастер, админ, и всё остальное. Нормально справлялся вроде.

А, ты в этом смысле. Тоже вроде все сам делал, но админ из меня никакой, писатель тоже так себе.

Здравствуйте, icezone, Вы писали:

I>Меня с начала топика убеждают, что это вранье. Попробуете аргументировать?

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

> I>Меня с начала топика убеждают, что это вранье. Попробуете аргументировать?
>
> Смысла аргументировать, любой программист может проверить эту гипотезу за полчаса. Пишем простой скрипт, который запрашивает сайты в выдаче какого-нибудь высокочастотного запроса и считаем корреляцию между позицией в выдаче и скоростью отдачи/размером страницы. Повторяем для разных запросов, пока не получаем бан от гугла. Обнаруживаем, что корреляция хоть и слабая, но статистически достоверная.

Если за полчаса, тогда зачем здесь эти ничем не обоснованные фантазии? Давай результаты.

Здравствуйте, grosborn, Вы писали:

G>Если за полчаса, тогда зачем здесь эти ничем не обоснованные фантазии? Давай результаты.

История учит нас, что единственный способ переубедить неверующего это дать ему возможность собственноручно "вложить персты".

Даже если я дам свои результаты, ты все равно найдешь тысячу и одну причину их оспорить. Проведем простой эксперимент:
вот статья с результатами. Достаточно убедительно?

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

ГЫ Твое предположение, если принять его на веру, приводит к очень забавным выводам. Например, что наполнение страницы HTML-кодом само по себе поможет для продвижения в выдаче. Корреляция же есть? Ага. Давайте пихать туда код.

Здравствуйте, grosborn, Вы писали:

G>Если чего-то не понимаешь в этих цифрах, лучше спроси, вместе разберемся.

Ты просишь доказательств, тебе привели цифры. Так кто из вас в этих цифрах чего-то не понимает?

G>ГЫ Твое предположение, если принять его на веру, приводит к очень забавным выводам. Например, что наполнение страницы HTML-кодом само по себе поможет для продвижения в выдаче. Корреляция же есть? Ага. Давайте пихать туда код.

Как? Ну как из утверждения что скорость загрузки страницы влияет на выдачу можно сделать такой вывод?

> G>Если чего-то не понимаешь в этих цифрах, лучше спроси, вместе разберемся.
>
> Ты просишь доказательств, тебе привели цифры. Так кто из вас в этих цифрах чего-то не понимает?
>
> G>ГЫ Твое предположение, если принять его на веру, приводит к очень забавным выводам. Например, что наполнение страницы HTML-кодом само по себе поможет для продвижения в выдаче. Корреляция же есть? Ага. Давайте пихать туда код.
>
> Как? Ну как из утверждения что скорость загрузки страницы влияет на выдачу можно сделать такой вывод?

Ребята, я понимаю конечно, что этот форум не для сильно умных, но на бытовом уровне вы же должны понимать, что если событие произошло одновременное с другим, это совсем не значит, что вследствие того события.
Ты считаешь, что показатель корреляции доказательство. Но с позицией выдачи коррелирует и объем HTML кода, по вашей логике увеличивая объем кода (скажем вставляя DIV), мы будем продвигать сайт. Так понятнее написал?
Все конечно может быть, пути гугля неисповедимы, но оснований так считать у меня пока нету. Даже наоборот, у меня есть все основания считать это редкостной ахинеей.
Показатель корреляции ни разу не доказательство зависимости позиции выдачи от скорости загрузки страниц.

Здравствуйте, grosborn, Вы писали:

G>Ребята, я понимаю конечно, что этот форум не для сильно умных

За такие слова бъют киянкой.

G>Ты считаешь, что показатель корреляции доказательство. Но с позицией выдачи коррелирует и объем HTML кода, по вашей логике увеличивая объем кода (скажем вставляя DIV), мы будем продвигать сайт. Так понятнее написал?

В каком месте ты увидел что увеличение объема кода улучшает на позиции? Все совсем наоборот. Контент первичен.

G> Все конечно может быть, пути гугля неисповедимы, но оснований так считать у меня пока нету. Даже наоборот, у меня есть все основания считать это редкостной ахинеей.
G>Показатель корреляции ни разу не доказательство зависимости позиции выдачи от скорости загрузки страниц.

Ты продолжай считать, а мы пока пооптимизируем.

> G>Ребята, я понимаю конечно, что этот форум не для сильно умных
>
> За такие слова бъют киянкой.

Ага, только научись сначала отвечать за свои слова.

> G>Ты считаешь, что показатель корреляции доказательство. Но с позицией выдачи коррелирует и объем HTML кода, по вашей логике увеличивая объем кода (скажем вставляя DIV), мы будем продвигать сайт. Так понятнее написал?
>
> В каком месте ты увидел что увеличение объема кода улучшает на позиции? Все совсем наоборот. Контент первичен.

Так все-таки показатель корреляции доказательство или нет? Ты назвал доказательством, а теперь отказываешься от своих слов.

> G> Все конечно может быть, пути гугля неисповедимы, но оснований так считать у меня пока нету. Даже наоборот, у меня есть все основания считать это редкостной ахинеей.
> G>Показатель корреляции ни разу не доказательство зависимости позиции выдачи от скорости загрузки страниц.
>
> Ты продолжай считать, а мы пока пооптимизируем.

Оптимизируй. А я лучше контентом займусь.

Здравствуйте, grosborn, Вы писали:

G>Ага, только научись сначала отвечать за свои слова.

Причем здесь мои слова если ты оскорбил разом всех участников форума? Кто из нас глупость про увеличение объема HTML кода ляпнул?

G>Оптимизируй. А я лучше контентом займусь.

Я тебе уже неоднократно говорил что оптимизация занимает считанные минуты.
Ты просто не понимаешь о чем идет речь, но продолжаешь спорить из принципа.
Если сразу все сделать правильно, то и оптимизировать ничего не надо.

> G>Оптимизируй. А я лучше контентом займусь.
>
> Я тебе уже неоднократно говорил что оптимизация занимает считанные минуты.
> Ты просто не понимаешь о чем идет речь, но продолжаешь спорить из принципа.
> Если сразу все сделать правильно, то и оптимизировать ничего не надо.

Я что, где-то спорил и возражал против оптимизации? Внимательнее нужно быть. Говорю же совершенно не читаешь, что тебе пишут.

> G>Ага, только научись сначала отвечать за свои слова.
>
> Причем здесь мои слова если ты оскорбил разом всех участников форума? Кто из нас глупость про увеличение объема HTML кода ляпнул?

Ты ляпнул, что корреляция является доказательством, я уже устал тебе это объяснять. Неделями простые вещи объяснять приходится.