Идея (без реализации) не стоит ничего, тыщу раз уже говорили.
Отличная идея — использовать термоядерный синтез для получения энергии. Ну-ка, кто купит?
Ну, скажем, Deferred — это не jQuery, это паттерн для работы с асинхронными вызовами, очень хорошо бы вам его использовать не зависимо от используемых библиотек. Но передавать в кеширующий слой (localCache) правильнее именно данные (как у вас сейчас и сделано), т.к. в реализации, описанной в stackoverflow, нельзя выбрать место хранения этих данных (jqXHR/deferred нельзя, например, «сохранить» в localStorage или на другом сервере).
Нет. Если еще раз внимательно прочитаете описанную вами схему, то поймете, что в вашем примере клиент никогда не знает до момента отправки запроса, изменились данные или нет, то есть он всегда спрашивает сервер, соответственно, ваша схема допускает только серверное управление политикой кеширования.
Про соотношение времен:
В вашем случае проверка «как там дела» производится в момент запроса данных, и если данные не изменились, то проверка в любом случае отнимет время на установление соединения, то есть получим минимальное время реакции, равное времени установления соединения, а это может быть много и не поддаваться оптимизации («последнюю милю», например, никто не отменял).
В случае с реализацией собственного механизма кеширования можно, например, пушем отправлять сигналы типа «такие-то данные изменены». То есть на момент попытки доступа будет заранее известно, надо отправлять запрос или нет. Таким образом минимальное время реакции будет очень близко к нулю (и существенно меньше времени в первом случае).
Про push: во-первых, не все данные бывают нужны в момент их инвалидации, во-вторых, никто не мешает реализовать кеш таким образом, чтоб данные сразу обновлялись при пуше, и к моменту запроса там они будут уже готовые лежать — таким образом, время реакции еще сократится. При этом, кстати, не потребуется модифицировать код, получающий доступ к этим данным.
Не спорю, в большинстве случаев, стандартные механизмы HTTP-кеширования работают вполне удовлетворительно. Но есть случаи, когда их возможностей не хватает. Это, кстати, написано в топике.
Ключевое отличие предложенного автором варианта (да и вообще всех клиентских реализаций кеша) от описанного вами HTTP-кеширования — возможность управлять политикой кеширования на клиенте. То есть когда не сервер решает, у каких данных истек срок годности, а клиент. В таком случае предложенный вами механизм не работает.
Например, давно уже успешно используются всевозможные PUSH-технологии, в таком случае сервер сам может сообщать о невалидности кешированных данных и необходимости запросить свежие.
Как справедливо указал автор, время установления соединения в определенных случаях может быть сильно больше времени генерации ответа сервера, тогда отказ от установления лишних соединений (для проверки «как там дела») может привести к существенному снижению времени реакции клиента на действия пользователя.
Кроме того, данный механизм, как опять же указано автором, можно применять не только в случае с HTTTP-запросами.
Вывод — текст не читай@комментируй вы не правы в части наличия всех необходимых механизмов кеширования в браузере.
Отсутствие такой возможности сейчас не говорит, что надо отказаться от таких желаний, и не говорит о том, что SEO есть благо.
К тому же попытка оправдаться в стиле «если я это не буду делать, то кто нибудь другой точно будет, потому срублю-ка бабла по быстрому» выглядит несколько неубедительно.
Вы либо путаете теплое с мягким, либо занимаетесь подтасовкой фактов. То, что так обстоят дела с рекламой в реале, не говорит о том, что это хорошо (большинство людей не любит рекламу, например).
Ну и не находите, что сортировка выдачи «как мне лучше» и сортировка товаров по качеству/цене с учетом личных предпочтений — то, что всем пользователям/покупателям хотелось бы видеть в поисковиках и магазинах?
robots.txt — еще пойдет, а нормальные ответы движка сайта — это как бы и не SEO, это правильная реализация HTTP, гарантия, например, того, что сайт будет правильно работать через всякие прокси. Часть требований в нормальных студиях.
На самом деле, не так много работы в том, чтоб сайт нормально и адекватно индексировался (=«помочь поисковику»). Там особо специально и делать ничего не нужно (Google, вон, даже AJAX индексирует). Много работы в том, чтоб его вывести на первое место по определенным запросам, это — главная (да и единственная) задача поисковой оптимизации.
И вы, даже своими благими намерениями вывода в топ только «хороших» сайтов, добавляете работы другим оптимизаторам, а так же снижаете вероятность выхода просто хорошо сделанных сайтов, у которых тексты просто человеческие, а не «продающие и оптимизированные», например. То есть, как я уже говорил, снижаете релевантность выдачи, препятствуете улучшению алгоритмов поиска по человеческим текстам, и склоняете других тоже тратить деньги на оптимизацию, и тем самым кормите, в том числе, и школоту-дорвейщиков, которые даже по вашему мнению являются злом. Так что нет, хорошего вы ничего не делаете, и пользы человечеству не приносите.
Хотите пользу принести? Попробуйте продвигать сайты без учета поисковых запросов вообще, докажите всему миру, что SEO — нерентабельное зло.
А до тех пор смиритесь с народной нелюбовью =)
1. То есть, вы на полном серьезе считаете, что между баблом, потраченным на рекламу, и баблом, потраченным на производство товара/услуг — всегда прямая зависимость? МММ, например, достаточно много тратили на рекламу, да.
2. Реклама по адвордс показывается на четко обозначенных местах, с подписями, что это реклама, там четко видна зависимость между потраченным баблом и позицией. Чтоб понять, что мне впаривают определнный товар/услугу — не надо открывать, и даже читать объявление (пока я не захочу, чтоб мне впарили).
В выдаче не обозначено, что это — реклама или нет. Чтоб понять, впаривают мне или нет — надо потратить внимание, время, трафик и пр. Мне (и не только мне) это не нравится, и это нифига не адекватный компромисс.
Вот просветите, в качестве ликбеза, что вы делаете такого с сайтом, что первоочередно связано с поисковыми системами (т. е. семантичную верстку сюда приплетать не нужно, например)?
Надо стремиться к просто нормальным текстам (без учета запросов и ключевых слов), к просто нормальной верстке, к просто нормальным, человеческим (т. е. сделанным для человека) сайтам. Правильный путь не в оптимизации сайтов под поисковики, правильный путь в оптимизации поисковиков под сайты и людей.
> Но все дело в том, что детская порнография уже есть,
> и в ближайшее время, похоже, никуда не денется.
> Поэтому, как я уже неоднократно писал здесь, может
> лучше приложить усилия к тому чтобы сделать детскую
> порнографию цивилизованной?
Шутка, конечно, но хорошо показывает, что «делать цивилизованней» порочную практику — порочная практика. Задача SEO — обмануть (изначально ПС, но в конце концов пользователей ПС), выдать желаемое за действительное. Это, как и любая другая реклама, требует некоторых знаний, творческого подхода и т.п., и, естественно, приносит деньги. Возможно хорошие, возможно нет. Но меня искренне умиляет желание оптимизаторов быть любимыми обществом — глупо ожидать любви, потому как никто не любит, когда его пытаются обмануть.
И не надо притворяться (и убеждать себя), что делаете мир лучше — не делаете, взгляните правде в глаза. Хотите принести пользу человечеству — перестаньте заниматься оптимизацией.
В этом и беда. Вместо того, чтоб приближать день, когда поисковики будут максимально точно определять релевантность страниц, написанных нормальным человеческим языком, SEO-оптимизатор:
а) вносит искажения в исходные данные, пытаясь в меру своего умения подогнать текст под существующий алгоритм поиска
б) отнимает часть сил команд разработки поисковых машин на разработку фильтров против поискового спама.
Если нет оптимизации, то качество выдачи зависит от механизма ранжирования страниц. Если оптимизация присутствует — качество выдачи начинает зависеть и от алгоритмов фильтрации. Оптимизировать два алгоритма сложнее, чем один. Потому любая «оптимизация» исходных данных — зло в долгосрочной перспективе.
Это как взять данные эксперимента и подправить их, чтоб совпадали с расчетными, вместо того, чтоб поискать ошибки в теории.
Есть сайт на IIS с Windows Authentication и имперсонализацией, есть, например, MS SQL с Windows Authentication (или другой сайт/сервис с WA). В случае FF удостоверение клиента не передается SQL-серверу, хотя IE и Chrome работают нормально. Не знаю, поправили ли в свежем, в 3.6 еще было — а такая схема работы достаточно популярна в корпоративных системах.
Мне кажется, что почти все описанное относится к веб-стандартам, и создано не для поисковиков, а для всех клиентов с ограниченными возможностями (например, мобильные, текстовые, голосовые или еще какие браузеры), и для автоматической обработки (в том числе, конечно, и для роботов поисковиков). Потому это либо верстальщик должен учесть, либо программист должен, например, предусмотреть соответствующие поля в CMS, а контент-менеджер должен их адекватно заполнять. Специфичное для «Search Engines» тут только «description», пожалуй.
Я вас умоляю! О какой оптимизации деятельности при переходе на другой браузер может идти речь, если приложения, в которых работают через браузер, официально не поддерживают ничего, кроме IE?
Таким образом мы имеем некоторое количество дополнительной работы IT-персонала, потенциально приводящей к конфигурации, не поддерживаемой производителем ПО и добавляющая некоторых сложностей в поддержке за счет менее тесной интеграции в инфраструктуру MS — отличная оптимизация, я считаю.
Отличная идея — использовать термоядерный синтез для получения энергии. Ну-ка, кто купит?
Про соотношение времен:
В вашем случае проверка «как там дела» производится в момент запроса данных, и если данные не изменились, то проверка в любом случае отнимет время на установление соединения, то есть получим минимальное время реакции, равное времени установления соединения, а это может быть много и не поддаваться оптимизации («последнюю милю», например, никто не отменял).
В случае с реализацией собственного механизма кеширования можно, например, пушем отправлять сигналы типа «такие-то данные изменены». То есть на момент попытки доступа будет заранее известно, надо отправлять запрос или нет. Таким образом минимальное время реакции будет очень близко к нулю (и существенно меньше времени в первом случае).
Про push: во-первых, не все данные бывают нужны в момент их инвалидации, во-вторых, никто не мешает реализовать кеш таким образом, чтоб данные сразу обновлялись при пуше, и к моменту запроса там они будут уже готовые лежать — таким образом, время реакции еще сократится. При этом, кстати, не потребуется модифицировать код, получающий доступ к этим данным.
Не спорю, в большинстве случаев, стандартные механизмы HTTP-кеширования работают вполне удовлетворительно. Но есть случаи, когда их возможностей не хватает. Это, кстати, написано в топике.
Например, давно уже успешно используются всевозможные PUSH-технологии, в таком случае сервер сам может сообщать о невалидности кешированных данных и необходимости запросить свежие.
Как справедливо указал автор, время установления соединения в определенных случаях может быть сильно больше времени генерации ответа сервера, тогда отказ от установления лишних соединений (для проверки «как там дела») может привести к существенному снижению времени реакции клиента на действия пользователя.
Кроме того, данный механизм, как опять же указано автором, можно применять не только в случае с HTTTP-запросами.
Вывод —
текст не читай@комментируйвы не правы в части наличия всех необходимых механизмов кеширования в браузере.К тому же попытка оправдаться в стиле «если я это не буду делать, то кто нибудь другой точно будет, потому срублю-ка бабла по быстрому» выглядит несколько неубедительно.
Ну и не находите, что сортировка выдачи «как мне лучше» и сортировка товаров по качеству/цене с учетом личных предпочтений — то, что всем пользователям/покупателям хотелось бы видеть в поисковиках и магазинах?
На самом деле, не так много работы в том, чтоб сайт нормально и адекватно индексировался (=«помочь поисковику»). Там особо специально и делать ничего не нужно (Google, вон, даже AJAX индексирует). Много работы в том, чтоб его вывести на первое место по определенным запросам, это — главная (да и единственная) задача поисковой оптимизации.
И вы, даже своими благими намерениями вывода в топ только «хороших» сайтов, добавляете работы другим оптимизаторам, а так же снижаете вероятность выхода просто хорошо сделанных сайтов, у которых тексты просто человеческие, а не «продающие и оптимизированные», например. То есть, как я уже говорил, снижаете релевантность выдачи, препятствуете улучшению алгоритмов поиска по человеческим текстам, и склоняете других тоже тратить деньги на оптимизацию, и тем самым кормите, в том числе, и школоту-дорвейщиков, которые даже по вашему мнению являются злом. Так что нет, хорошего вы ничего не делаете, и пользы человечеству не приносите.
Хотите пользу принести? Попробуйте продвигать сайты без учета поисковых запросов вообще, докажите всему миру, что SEO — нерентабельное зло.
А до тех пор смиритесь с народной нелюбовью =)
1. То есть, вы на полном серьезе считаете, что между баблом, потраченным на рекламу, и баблом, потраченным на производство товара/услуг — всегда прямая зависимость? МММ, например, достаточно много тратили на рекламу, да.
2. Реклама по адвордс показывается на четко обозначенных местах, с подписями, что это реклама, там четко видна зависимость между потраченным баблом и позицией. Чтоб понять, что мне впаривают определнный товар/услугу — не надо открывать, и даже читать объявление (пока я не захочу, чтоб мне впарили).
В выдаче не обозначено, что это — реклама или нет. Чтоб понять, впаривают мне или нет — надо потратить внимание, время, трафик и пр. Мне (и не только мне) это не нравится, и это нифига не адекватный компромисс.
> и в ближайшее время, похоже, никуда не денется.
> Поэтому, как я уже неоднократно писал здесь, может
> лучше приложить усилия к тому чтобы сделать детскую
> порнографию цивилизованной?
Шутка, конечно, но хорошо показывает, что «делать цивилизованней» порочную практику — порочная практика. Задача SEO — обмануть (изначально ПС, но в конце концов пользователей ПС), выдать желаемое за действительное. Это, как и любая другая реклама, требует некоторых знаний, творческого подхода и т.п., и, естественно, приносит деньги. Возможно хорошие, возможно нет. Но меня искренне умиляет желание оптимизаторов быть любимыми обществом — глупо ожидать любви, потому как никто не любит, когда его пытаются обмануть.
И не надо притворяться (и убеждать себя), что делаете мир лучше — не делаете, взгляните правде в глаза. Хотите принести пользу человечеству — перестаньте заниматься оптимизацией.
а) вносит искажения в исходные данные, пытаясь в меру своего умения подогнать текст под существующий алгоритм поиска
б) отнимает часть сил команд разработки поисковых машин на разработку фильтров против поискового спама.
Если нет оптимизации, то качество выдачи зависит от механизма ранжирования страниц. Если оптимизация присутствует — качество выдачи начинает зависеть и от алгоритмов фильтрации. Оптимизировать два алгоритма сложнее, чем один. Потому любая «оптимизация» исходных данных — зло в долгосрочной перспективе.
Это как взять данные эксперимента и подправить их, чтоб совпадали с расчетными, вместо того, чтоб поискать ошибки в теории.
Таким образом мы имеем некоторое количество дополнительной работы IT-персонала, потенциально приводящей к конфигурации, не поддерживаемой производителем ПО и добавляющая некоторых сложностей в поддержке за счет менее тесной интеграции в инфраструктуру MS — отличная оптимизация, я считаю.