Изоморфные веб-приложения: скорее нет, чем да

[tonsky]

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

Как бы нам этого ни

Comments

[ext_3034700]

Или скорее эта штука начнет нормально работать https://developers.google.com/webmasters/ajax-crawling/

[tonsky]

Как вариант - подождать пару лет, да. Пока вроде не работает, по крайней мере сайты хуже ранжируются

[lelf]

> хуже ранжируются

Есть примеры? Насколько я помню они говорили, что мол именно из-за single-page-app ранг никогда ниже не будет

[p1r4nh4]

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

[lelf]

Ну я все-таки имел в виду вариант, когда боту уже срендеренное скармливается.

[p1r4nh4]

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

[lelf]

Это какой-то тред изобретателей проблем =)

Какая сложность-то. Хотим больше велосипедов - в ручную делаем, хотим меньше - ставим на сервак один их n готовых headless движков. Та-да!

[p1r4nh4]

Как определить момент, когда уже можно хтмл отдавать?

[tonsky]

Я может глупость скажу, но у них со скоростью рендеринга DOM и исполнения JS как? Потому что если они работают со скоростью примерно Google Chrome, то можно будет отдавать 1 запрос в секунду максимум. Допустим, делаем снепшоты. Если на сервере 1000 страниц, то обновляться они будут с незавидной скоростью раз в 16 минут. Что небыстро. То есть это какое-то адское прожигание ресурсов на бесполезную работу: эмуляцию браузера. Тот же питон может рендерить тысячу страниц в секунду, например. То есть проще приложение уже два раза написать, но зато поставить один сервер вместо ста. Или я где-то неправильно посчитал?

[lelf]

> Или я где-то неправильно посчитал?

В подсчете частоты захода crawler'ов?

[tonsky]

А, то есть два пути - если краулер, то снэпшот, а если человече - то нормальное веб-приложение? В принципе, наверное, можно. Огород, конечно, но да

[tonsky]

Я не смог сейчас найти статью, но да, была совсем недавно, что пока ajax и js не очень здорово

[p1r4nh4]

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

[ermouth]

Сам HTML может быть initial-данными для приложения, мы так делали, даже простиосспади с Битриксом. Это как раз имеет смысл в рамках вашего коммента ниже - про магазин и индексацию.

Появления странички это сильно ускоряет только в случае, если вы не кэшируете данные на клиенте. Если кэшируете (IDB, localStorage) - подход с HTML гарантированно медленнее как ни крути.

[p1r4nh4]

Кстати, вообще-то это не поможет. Рендерить-то HTML на сервере всë равно придëтся.

[tonsky]

Блин, я в ссылку не заглянул, думал это то же самое что я читал, а это оказалось совет про htmlunit бгг

Вот правильная: http://googlewebmastercentral.blogspot.ru/2014/05/understanding-web-pages-better.html и я верю что когда-нибудь она заработает. А насчет скорости, гораздо разумнее положить в html закешированный json чтобы не делать первый ajax-запрос, и скорость выровняется. Или через http 2 пушить сразу с index.html