Найти - Пользователи
Полная версия: Серверная шаблонизация + клиентская
Начало » Web » Серверная шаблонизация + клиентская
1 2
o7412369815963
При открытии, на страницу выводятся объекты (1-я пачка книг), далее при скроле вниз, выводятся 2-я, 3-я пачка книг и т.д.

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

1) Для сервера и клиента свои шаблоны.
-5 дублирование html.
2) Рендерим все на сервере, через json отправляем 2-ю страницу в html виде, на клиенте выводим и биндим.
-1 летит больше трафика
-1 нагрузка на сервер (рендеринг)
* амазон/кинопоиск/… используют такой подход
3) node.js для рендеринга
- 7 тормозное решение (имитация DOM, angular и пр.), + лишний костыль.
4) Заюзать mustache.js, на клиенте после рендеринга делать биндинг (angular)
-2 Не очень хороший шаблонизатор (по фичам), имхо.
5) Сделать серверный шаблонизатор понимающий основы angular (условия, вывод, циклы), т.к. рендеринг и биндинг через angular.
- Ещё нужно написать, хотя может получится интересное решение.

Пока склоняюсь к 2 варианту. Может ещё какие варианты есть?
Lexander
o7412369815963
Решил рендерить 1-ю пачку книг на сервере, для моментального отображения. (И для seo хорошо)
Можно для роботов рендерить все пачки на сервере, чтобы SEO полноценно работало.
Если визуальных отличий от версий для роботов и пользователей не будет, то санкций к сайту применять тоже не будут.

o7412369815963
Рендерим все на сервере, через json отправляем 2-ю страницу в html виде, на клиенте выводим и биндим.
Если готовые блоки html, зачем же их прятать в json?
Полученный с сервера блок просто добавляем к родительской ноде на странице - это самый быстрый способ построения страницы на клиенте.

o7412369815963
-1 летит больше трафика
Минус json, плюс сжатие html (убрать пробелы и пр.)
В любом случае, у меня возникает вопрос: больше - это сколько в цифрах?
Может быть там кот наплакал.

o7412369815963
-1 нагрузка на сервер (рендеринг)
А кеширование? Его ведь даже на уровне web-сервера делать можно, ничего ручками писать не нужно.

По поводу нагрузки на сервер.
Какие тайминги этапов обработки запроса на получение следующих пачек:
1. латенси ожидания подключения (мерять на клиенте),
2. запросы к БД,
3. генерация ответа,
4. получение ответа (мерять на клиенте),
5. рендеринг страницы (мерять на клиенте)?
Если блоки простые и время подготовки информации непосредственно на сервере существенно больше времени генерации готовой страницы, можно слать json и рендерить на клиенте.
Иначе - нет смысла, клиент начнет тормозить и помочь ему, например, кешированием особо не получится. Даже с локальным хранилищем (плюс доп. работа для организации локального кеша).

Что касается клиентской части, посмотрите, может быть будет достаточно Riot.js (он еще не вышел на мажорный релиз, но пользоваться уже можно), Ractive.js или canJS.
o7412369815963
Lexander
Можно для роботов рендерить все пачки на сервере, чтобы SEO полноценно работало.
Сейчас так и работает, через “_escaped_fragment” но bing на него “забивает” хотя официально якобы поддерживает.
Но это все не из-за seo, а как раз из-за скорости.

Lexander
Если готовые блоки html, зачем же их прятать в json?
Там ещё полетят некоторые данные что-б можно было на логику завязатся ангуларом, хотя их можно и в html завернуть.

Lexander
В любом случае, у меня возникает вопрос: больше - это сколько в цифрах?
Может быть там кот наплакал.
Да, я думаю не существенно, особенно если учесть остальной трафик (html, img) + частота использования “пагинации”. Поэтому всего-лишь “-1”. Тоже самое с рендерингом, не очень существенно, + доп. нагрузки на БД нет (все равно они будет впоследующих запросах) - чуть что можно размазать по серверам.

2) Страница, над которой я сейчас “пляшу”, делает 5 запросов к БД по индексам, по профайлеру каждый отрабатывает менее 1мс, хотя, позже, я это ещё заоптимизирую немного. Я уже часть на сервер перевел.
1) DNSlookup (100-300мс, не всегда) + 80ms connecting (не всегда) + 0ms sending + 90ms wating + 1-10ms reciving.
Пинг 80мс.
3) 10мс (бывают скачки 30мс или более, так же заметил проблемы на сервере, бывает прерывается до секунды виртуалка Hetzner, пока считаю что это ОС проводит манипуляции с памятью/кешем, но это другая история)
4) 100 - 250мс
5) Рендеринг “моментальный”

Все тормоза в сети, один только jquery летит от 200 - 500мс даже от CDN (и видимо это норма если посмотреть топовые сайты), после того как браузер пережует JS - отправляет за json. В итоге 1 - 1,5 сек. Хотя заказчик говорит, что у него ещё медленней.

Если рендерить на сервере, будет 20..60мс на ответ + 200мс в среднем на сеть. Будет заметно быстрее.
Да и вообще, это не веб-приложение, а веб страница.
o7412369815963
Lexander
Что касается клиентской части, посмотрите, может быть будет достаточно Riot.js (он еще не вышел на мажорный релиз, но пользоваться уже можно), Ractive.js или canJS.
Riot.js — The 1kb client-side MVP framework
Riot.js зависит от jQuery, поэтому 1кб не отделаться.
В общем случае они не дадут особого преимущества, это только если весь js перетряхнуть и выбросить jQuery (оставить для совместимости) и все равно будет медленнее, хотя может будет достаточно по скорости.
bismigalis
o7412369815963
1-я пачка книг
эта пачка для всех одна или юзер специфичная?
o7412369815963
bismigalis
эта пачка для всех одна или юзер специфичная?
у каждого пользователя свои книги, причем у каждого своя сортировка (дата добавления к себе на “стену”) + флажок есть ли эта книга у меня.
+ на клиенте есть возможность переключать фильтр по “жанру” книг с изменением урла (не хеша), - кусочек веб-приложения :)
Lexander
o7412369815963
Если рендерить на сервере, будет 20..60мс на ответ + 200мс в среднем на сеть. Будет заметно быстрее.
Вот и ответ.

jQuery брать с крупного общего CDN (типа Google или того, который используется на сайтах, куда ходит ваша аудитория) пробовали?
Получаете его асинхронно?

Какой адрес страницы сейчас? Может что еще увижу.
bismigalis
а что если в страницу вставлять первую порцию JSON?
o7412369815963
bismigalis
а что если в страницу вставлять первую порцию JSON?
Хм, думал написал про эту оптимизацию выше,
да, она избавит от первого json запроса = -200 мс
o7412369815963
Lexander
jQuery брать с крупного общего CDN (типа Google или того, который используется на сайтах, куда ходит ваша аудитория) пробовали?
У меня ещё есть knockout.js в роли рендер + биндинг, который не так популярен.
$ time wget http://cdnjs.cloudflare.com/ajax/libs/knockout/2.3.0/knockout-min.js
real    0m0.545s
$ time wget http://cdnjs.cloudflare.com/ajax/libs/knockout/2.3.0/knockout-min.js
real    0m0.449s
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=48 time=51.6 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=48 time=50.2 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=48 time=50.0 ms

Lexander
Получаете его асинхронно?
Асинхронно между js и js, или js и html? второе - нет.

Кстати я ошибся на счет "5) Рендеринг “моментальный”, похоже он все же не такой моментальный - chrome timeline:
Evaluate Script - Details
Duration	34.639 ms (at 536 ms)
Self Time	33.741 ms
CPU Time	34.899 ms
Aggregated Time	1.158 ms33.741 ms
Script	jquery-1.7.2.min.js:1
Used Heap Size	7.9 MB (+988 KB)
это только jquery, сам “ренднринг” 105мс, суммарно для “Evaluate Script” вышло около 230мс, у меня core i5 M450 (не особо слабый ноут)

Lexander
Какой адрес страницы сейчас? Может что еще увижу.
У меня там сейчас каша, стыдно показывать :)

Вообщем ясно, ускорять есть куда, но тут все равно ещё нужно рендеринг (немного) перепилить (было сделано под веб-приложение), неохота терять время, вдруг не оправдается.
Да и за серверный рендеринг есть абстрактные плюсы: возможность переписать красиво (спорный факт), опробовать метод - подключение клиентского приложения к нарендеренному на сервере, разделение веб станиц и веб приложений друг от друга.

А вы почему так против серверного/за клиентский рендеринг?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB