Denechka

Рейтинг
59
Регистрация
29.10.2018
WebSeo:
я делюсь советами, какими то решениями, намеками - которые очень важно уметь понять

Да Вы, прямо, как БГ.

WebSeo:
У меня есть несколько работников - им пока мозг не включишь ничего не получается. Но эти хоть немного понимают, до них было около десятка других, совсем пустых. Если не получается, неумеют - не я в этом виноват

Как любил говаривать Сент-Экзюпери - "мы в ответе. за тех, кого приручили".

Вы видели своим опытным глазом, кого Вы набираете.

Если Вы не смогли промотивировать/обучить еффективной работе - это только, лишь Ваш бок. Ведь люди надеялись на Вас, если вы им давали какие-либо гарантии.

Вообще в этом случае нормальный "завод" гораздо эффективнее такого горе-манагера.

AlexStep:
И что, если общее время загрузки страницы будет в районе 2000 мс?)) Насколько это важно?

Ну, можете считать это моим бзиком, но мне кажется, что:

  • Чем выше скорость, тем веселе гуглобот обходит страницы, т.к. имеет собственный лимит на время обхода. (Краулерный бюджет, помоему называется, или как то так)
  • Удалённому пользователю с хилым канальчиком быстрые страницы ИМХО приятнее получать
  • Самому приятнее отлаживать, вносить изменения

Про ассемблер, конечно, больше теория, чем практика, но я об этом и писал. Для себя кое-что пишу, но денег это не приносит, так, как хобби пока.

AlexStep:
на шаред хостинге и время загрузки html - 200 мс

То же самое шаред хостинг на ZendFramework - 80 мс

Dreammaker:
а потом криво проставленный или не проставленный индекс по полю в БД, всю эту красивую оптимизацию ломает

Так за БД тоже отдельный разговор, её тоже желательно полностью контролировать и тогда на полумилионных таблицах в >1G запросы выполняются <10мс.

На WordPress такого лично у меня не получалось.

ИМХО очень важна система кеширования. Применительно к тому же WordPress на litespeeed, мне лично очень нравится LiteSpeed Web Cache. Скорость получается соизмерима со стат. файлами.

SergejF:
Я пришел узнать, было ли у Гугла кардинальное изменение в поисковой выдаче в январе

ИМХО не было никаких кардинальных изменений ни в январе, ни в декабре, ни в феврале, ни в ноябре, ни в марте, ни в октябре, ни в апреле.

Ядро алгоритма сформировано довольно давно. Просто периодически полируют коэффициенты матрицы ранжирования.

Изменение одного коэффициента на 0,001 может один сайтик притопить, другой приподнять немного.

В общей выдаче, по теории больших чисел особо рояля не сыграет.

SergejF:
I came to know was whether Google's radical change in the search results in January

IMHO there have been no fundamental changes either in January or in December or in February or in November or in March or in October or in April.

The core of the algorithm is formed for a long time. Just occasionally polish coefficients ranking matrix.

Changing one factor 0.001 can saytik one countersunk, another lift slightly.

The total issue, particularly large numbers of the piano will not play on the theory.

mekling:
Подкиньте пару тем нормальных, с нормальной скоростью.

ИМХО не в темах дело (если, конечно Вы имеете в виду темы WordPress)

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

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

  • Ассемблер (быстро в работе - очень геморно в разработке, мало кто сейчас практически занимается, в практике работающих приложений ПОКА нет, но есть типа лабораторных, курсовых, дипломный проектов)
  • С - ближе к реальной разработке, но тоже очень геморно (не получилось ПОКА создать, приносящее денег приложение) + любой безусловный переход негативно влияет на конвеер процессора (чаще всего кэш конвеера просто обнуляется), но остаётся, конечно прогноз переходов.
  • С++ - ещё ближе к реальной разработке, можно вводить ООП, но, по-моему, любой CPU общего назначения не имеет ни малейшего понятия об ООП -> тоже очень геморно (тоже, пока, разработок в промышленной эксплуатации нет)
  • НТТP сервер (apache, ngincs, lifespeed c системой кеширования) + статические файлики (реально имеется опыт, реально работало). Из минусов - сделать изменения = писать отдельный проект
  • НТТP сервер (apache, ngincs, lifespeed c системой кеширования) + самописный php, python, jawa проект с ассемблерными вставками, если требуется производительность реального времени
  • НТТP сервер (apache, ngincs, lifespeed c системой кеширования) + фреймворк (ZEND, Laravel, yii и т.п.) реально уменьшается время разработки, время отклика сопоставимо с выше перечисленными пунктами
  • НТТP сервер (apache, ngincs, lifespeed c системой кеширования) + какая-нибудь СMS (но, без левых плагинов) - время ответа уже может увеличиться
  • НТТP сервер (apache, ngincs, lifespeed c системой кеширования) + какая-нибудь СMS со всякой белибердой (в, основном плагины)- время ответа реально увеличивается
  • НТТP сервер (apache, ngincs, lifespeed без кеширования) + какая-нибудь СMS со всякой белибердой (в, основном плагины)- время ответа реально увеличивается в разы

+ к этому всему (софтовому) добавляется:

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

Так шо, как любил говаривать Кузьма Прутков - "зрите в корень"
Практичекски реальная оптимизация получается при закладке проектов по 5,6,7п.

Мой сайтик 01.02.20 подрезало не хило, сейчас выбираемся из ямы.

My saytik 02/01/20 undercut not sickly, Now get out of the pit.

Sportmas, Так, значит эксперимент удался. Поздравляю.

Спс, за наглядные результаты.

Ловко и показательно утёрли нос, тем, кто недооценивал скорость, как фактор ранжирования.

Только теперь вопрос, в каком русле двигать дальше?

lkm, Благодарю за чёткий, содержательный ответ

Всего: 493