Twitter возвращается к генерации страниц на сервере

    Twitter объявил об очередной смене архитектуры: генерация страниц теперь будет осуществляться на стороне сервера, а не на стороне клиента.

    После прошлой модернизации в сентябре 2010 года весь рендеринг UI и логику переложили на JavaScript на клиентской стороне. Браузеры напрямую обращались к Twitter REST API, как и мобильные клиенты. Хотя такой подход помог реализовать ряд преимуществ, но разработчики потеряли возможности оптимизации, которые доступны при серверно-ориентированном подходе. В результате, пользователи начали жаловаться на субъективное «подтормаживание» страниц twitter.com.

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

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

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

    Кстати, как можно заметить, из статичных ссылок исчезли хэшбэнги (#!), это одно из последствий оптимизации. С браузера сняли часть работы по выполнению JavaScript, распознаванию пути, скачиванию и рендерингу контента для указанного URL.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 45

      0
      Интересно, они используют rails для рендеринга?
        +7
        Скорее всего нет. В последнее время они плотно занимаются разработкой на Scala.
        • UFO just landed and posted this here
            +4
            А зачем им тогда люди со знаниями Руби , значит еще не совсем усшли с него…
            • UFO just landed and posted this here
              –3
              Поддерживать старый код.
              0
              очень хочется напомнить вот этот комментарий
              • UFO just landed and posted this here
            +32
            субъективное «подтормаживание» страниц

            Нифига себе субъективное! Там разворот Conversation'а тормозит вообще безбожно, а если их около 4х развернуть — то вообще, пиши пропало.
            • UFO just landed and posted this here
                +3
                Мир web 2.0
                +49
                ааа. новые технологии, уникальные возможности, прирост скорости в разы — просто генерируйте страницу на сервере
                  +1
                  скорее «новая старая» технология. Интересно, какие преимущества им дал рендер страниц на клиенте (кроме разгрузки серверов)
                    +4
                    Трудоустроил сотню человек на год :)
                      +2
                      Кривая реализация. Сотня кодеров с кривыми руками могут убить любую идею.
                • UFO just landed and posted this here
                    +3
                    Время генерации появилось. До возврата к серверной генерации HTML, клиент просто получал данные и добавлял элементы с этими данными прямо в DOM.

                    То, что имеется в виду в цитате, которую вы привели, — это что пользователь видит готовую страницу в пять раз быстрее. По крайней мере, я так понял.
                    • UFO just landed and posted this here
                      • UFO just landed and posted this here
                    +5
                    Похоже всё таки ещё рановато для разработки REST Full приложений.
                      +16
                      Её просто нужно грамотно делать. А то напихали метр JavaScript'а и потом внезапно обнаруживают, что оно тормозит.
                        0
                        сейчас попытался открыть через developer tools чудесный полутораметровый t1-hogan-more-кактотам.js
                        девтулза залипла наглухо…
                      +5
                      хорошо что есть смелость признавать свои ошибки
                        +4
                        наконец-то!
                          0
                          Ну не знаю, у меня на клиенте щаблоны генерятся шустро.
                          Мне кажется тут либо плохой шаблонизатор либо просто страница была сильно перегружена скриптом.
                            +5
                            Грустно, что для загрузки одного твита (140 символов) требуется 1,65 мегабайта скриптов.©
                            наверно, еще рано для этого =)
                              +2
                              1. Изначально страницу генерим на сервере.
                              2. Изначально загружаем ядро скриптов. Это примерно 60Кб(в ужатом виде). Остальное подгружаем по-необходимости.
                              3. При последующих переходах(аяксовых) с сервера приходят только данные, шаблон собирается на клиенте.
                            +13
                            «xxx: я всё больше подозреваю, что четырех-ядерный процессор мне понадобится не из-за игр, а для комфортного чтения твиттера» (с) bash.im.
                              +3
                              На этой неделе новую архитектуру выкатили для статичных ссылок (пермалинков). Как показали тесты, скорость загрузки страницы в браузер пользователя выросла в среднем в пять раз...

                              Ха-ха-ха, насмешили. Ну конечно же скорость выросла в пять раз, ведь раньше при открытии ссылки на отдельный статус (даже скопированной вручную в новый таб) было невооружённым глазом видно, что сначала грузилась вся обычная лента и только через пару секунд поверх неё уже выводился слой с отдельным статусом =)
                              • UFO just landed and posted this here
                                  +3
                                  А если перейти по ссылке на фотографию — сначала мелькала своя лента, потом пустая лента, потом пустая лента другой ширины, потом заготовка под страницу с фотографией, потом собственно фотография с описанием. Итого 2-5 секунд от загрузки страницы до появления фотографии, вне зависимости от скорости интернета.
                                  Вебдваноль такой вебдваноль, да.
                                  +5
                                  Самый тормозной сайт современного большого интернета потеряет своё лидерство… Странно, неужто существующее решение невозможно оптимизировать до приемлимого уровня. Идея-то неплохая для высоконагруженного сервиса.
                                    +1
                                    Может там всем рулят менеджеры?
                                    Думаю, грамотный технический специалист с большим авторитетом в компании сумел бы отстоять позицию, что всё переделывать не стоит, а надо заняться оптимизацией.
                                    А вообще интересно было бы почитать, что думают технические специалисты twitter по этому поводу, какая неразрешимая проблема на пути встала.
                                    0
                                    А я то думаю, почему каждый раз при заходе на внутренние страницы вначале рендериться главная лента, а потом то что нужно…
                                      0
                                      Генерировать HTML на стороне сервера в сотни раз дешевле аналогичного на стороне клиента. Это можно было предсказать не занимаясь фигней с переводом всего проекта на «новые» технологии.
                                        0
                                        Ничего подобного, зависит от того как делать. Я в свободное время, делаю аналог phpMyAdmin, как раз в стиле одностраничного приложения (будет загружаться только индексная страница, всё остальное только JS). Так вот страница с простым запросом выдающим 50 строк таблицы, генерится в моем случае в 20 раз быстрее, чем в phpMyAdmin.
                                        Но конечно я не юзаю метр JS-кода, и код тщательно профилируется.
                                          +7
                                          Я одностраничное приложение сделал еще 5 лет назад. Первый вариант был как раз с активным использованием JS. Так как данные были весьма разнообразные, вывод их требовал довольно большого количества HTML-темплейтов или JS-обработчиков. Код усложнялся с каждой итерацией модификаций. Стоимость внесения изменений росла по экспоненте. Через время начались проблемы со скоростью отображения в IE. Замена динамических таблиц на статические дали прирост почти на порядок.

                                          Почему генерировать HTML на стороне клиента дорого? JS умеет работать с содержимым старницы только в двух режимах — модификация при помощи DOM-методов и innerHTML. DOM-методы не то, чтобы не предназначены для темплейтирования, они и в обычном коде используются только для примитивных вещей. innerHTML требует работы со строками через regexp или множественными split'ами, replace'ами, и так далее. Было бы гораздо легче, если бы JS умел выплевывать сгенерированный текст в stdout, как это делает любой серверный язык, но, к сожалению, такая функциональность не предусмотрена в силу специфики среды исполнения.

                                          Темплейтирование же на стороне сервера облегчено наличием готовых темлейт-систем на любой вкус и цвет. Мало того, готовый HTML или другой контент легко кешировать в статику, т.е. браузеру не нужно будет каждый раз создавать темплейт наново. Вы скажете, что можно использовать LocalStorage для хранения готовых отрендеренных кусочков, но он не безразмерный, все хранить там не получится.

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

                                          А вот теперь подумайте, наставили минусов моему предыдущему комментарию заслуженно, или не разобравшись в проблеме?
                                            +1
                                            >Мало того, шансов на масштабирование почти нет, если контент генерируется на стороне клиента.
                                            А что это означает?:)
                                              +2
                                              Это означает, что вы не сможете обновить пользователю его компьютер, чтобы нарастить скорость работы. И использовать более одного компьютера для рендеринга тоже не получится. В отличие от сервера, где вы вольны делать любые изменения в архитектуре и подключать любые мощности для формирования ответа.
                                              +2
                                              Не судите все приложения/технологию, существует множество сайтов которые прекрасно работают (могли бы работать) с генерацией HTML на стороне клиента, где рендеринг страницы завершался бы раньше загрузки готовой страницы (особенно на узком канале клиента). Где введенные пользователем данные отображаются мгновенно, без ожидания ответа сервера с готовым HTML.
                                              К тому же можно использовать частичную генерацию (часть на сервере, часть на клиенте).

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

                                              > Было бы гораздо легче, если бы JS умел выплевывать сгенерированный текст в stdout, как это делает любой серверный язык
                                              Не понял к чему это и зачем.

                                              Каждый способ генерации HTML имеет свои плюсы и минусы.
                                              Вообщем, как говориться: «выбирать инструмент по задаче».
                                                0
                                                Это все теория. На практике все гораздо мрачнее, прозаичнее, меркантильнее. Основная задача любого продукта — приносить пользу. Чем быстрее ПО обновляется и начинает удовлетворять потребностям рынка, тем оно полезнее. И при выборе технологий для продукта нужно следовать балансу между красотой архитектуры и скоростью разработки.

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

                                                По поводу stdout пояснять не буду, это слишком долго, если интересно — в приват.

                                                С последним согласен. Но добавлю, что не стоит идеализировать технологии и доводить их использование до маразма. Все должно быть экономически целесообразным в первую очередь.
                                          +1
                                          Все-таки генеринг страниц, а не рендернг. А то заголовок создает впечатление, что браузер подгружает скриншоты страниц.
                                            +7
                                            Нынешний вес сайта с сообщениями в 140 символов.

                                            image

                                            Only users with full accounts can post comments. Log in, please.