Почему именно на стороне сервера визуализации HTML быстрее, чем на стороне клиента?

Question

Почему именно на стороне сервера визуализации HTML быстрее, чем на стороне клиента?

Я работаю над большим веб-сайтом,и мы перемещаем большую функциональность на клиентскую сторону (Require.js, позвоночник и руль стека). Есть даже дискуссии о возможном перемещении всего рендеринга на клиентскую сторону.

Но читая некоторые статьи, особенно о том, что Twitter уходит от рендеринга на стороне клиента, в которых упоминается, что серверная сторона быстрее / надежнее, у меня начинают возникать вопросы. Я не понимаю, как рендеринг довольно простых HTML виджетов в JS из JSON and templates-это современный браузер на двухъядерном процессоре с 4-8 ГБ оперативной памяти, который работает медленнее, чем десятки приложений на стороне сервера. Существуют ли какие-либо реальные показатели бенчмаркинга в этой области?

Кроме того, похоже, что разбор HTML-шаблонов движками шаблонов на стороне сервера не может быть быстрее, чем рендеринг того же HTML-кода из шаблона Handlebars, особенно если это функция precomp JS?

467 3

javascript html-parsing backbone.js handlebars.js

3 ответов:

Comments

Ничего не найдено.

albattran · Accepted Answer · 2012-10-28 06:30:49

Причин много:

JavaScript является интерпретируемым языком и работает медленнее, чем серверная часть (обычно делается на компилируемом языке)

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

некоторые браузеры просто слишком медленные, особенно старый IE

Peter H. · Accepted Answer · 2012-10-28 06:53:42

производительность скомпилированного языка по сравнению с интерпретируемым javascript

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

меньше доверия к пользователям со старыми компьютерами или медленными / искалеченными браузеры

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

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

Henrik Vendelbo · Accepted Answer · 2017-04-06 15:28:32

Чтобы запустить код на стороне клиента, он сначала должен быть загружен. Код на стороне сервера загружается только при запуске сервера, в то время как код клиента потенциально должен загружаться каждый раз, когда страница загружается. В любом случае код должен быть интерпретирован при загрузке страницы, даже если файл уже кэширован. У вас также может быть кэширование деревьев JS parse в браузере, но я думаю, что они не сохраняются, поэтому они не будут жить долго.

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

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

Таким образом, у вас, вероятно, есть 50-100 мс, чтобы сделать что-то в JavaScript во время загрузки страницы, все это, общий итог, что означает, что рендеринг сложной страницы, ну, не так просто.