Comments 19
а где рабочий прототип / ссылка на демо?
А как это всё будет индексироваться поисковиками?
Если представлять вот в таком виде, то должно индексироваться так же, как и обычный HTML
<parent>
<child1>
...
<child11>...</child11>
...
</child1>
<child2>...</child2>
...
</parent>
Идея вам для велосипеда: можно собирать из вашего JS файла как из шаблона (а ля Smarty и им подобных) средствами сервера — HTML документы и поисковикам отдавать…
Кстати, как насчет вывода комментариев пользователя вашим ESS? Будут сложности в безопасности? Помню был такой сервис форумов a.borda.ru верстка как раз через JS, в поисковиках продвигают WAP версию форумов и гостевых. Так вот там куча дыр была как раз из-за JavaScript.
Кстати, как насчет вывода комментариев пользователя вашим ESS? Будут сложности в безопасности? Помню был такой сервис форумов a.borda.ru верстка как раз через JS, в поисковиках продвигают WAP версию форумов и гостевых. Так вот там куча дыр была как раз из-за JavaScript.
Я вот понять не могу, вы преследуете цель экономии трафика или скорости отображения? Если первое, то полагаю это для мобильных устройств, но в этом случае растет нагрузка на клиента, что может быть критично. На других устройствах трафик, как правило безлимитный.
Скорее второе, но как следствие уменьшения трафика – чем больше запомнит браузер пользователя, тем лучше. С одной стороны хочется при безлимитном трафике получать страницу как можно быстрее, а с другой – мобильные версии все больше похожи на приложения и такая оптимизация позволит сохранить в кеш всю визуальную часть, а значит ее можно сделать еще более продвинутой и при этом снизить трафик. Нагрузка на клиента сильно зависит от того, как разбивать JS скрипты и в скольких файлах хранить HTML шаблоны – их же тоже можно подгружать, а значит она должна быть приемлемой.
Демо будет в следующем посте, с подробным разбором и тестами.
Демо будет в следующем посте, с подробным разбором и тестами.
Тэг «novosti» просто убил.
Для ESS есть документация
Сайт едет по швам. У меня в хроме везде scrollbar'ы и куда-то съехавший текст.
Модальные окна убили.
Пожалуйста, сделайте удобоваримый сайт с человеческой докой, примерами и т.п., сейчас это нечитабельно.
напомнило Web Components ;)
Можете сравнить свой вариант с использованием require.js + любой клиентский шаблонизатор?
Там тоже можно разбить на мелкие файлы, которые грузятся по требованию и кэишруются + с сервера грузятся только данные без разметки (например, в json).
Там тоже можно разбить на мелкие файлы, которые грузятся по требованию и кэишруются + с сервера грузятся только данные без разметки (например, в json).
Пост целиком не читал, поэтому не буду объяснять почему подход автора слишком наивный и велосипедный. Но в Яндексе везде где можно используется отложенная загрузка и кэширование. И главная страница Яндекса с отключенным кэшем у меня грузит 390кб и стартует за 0.75с, а с кэшем 60кб и 0.56с. Большая часть из этих 390кб реально нужна сразу.
А теперь нам надо поменять html…
Я подобное велосипедил, только на основе XML+XSLT.
Всё же все оптимизации должны использовать правильную цель. В вашем случае вы ориентируетесь на время конца загрузки всех ресурсов, но оно не показательно.
Насколько мне известно, в Яндексе ориентируются на метрику «пользовательское счастье» — время, когда пользователь увидит то, зачем пришел на страницу. Это время не равно времени загрузки всех ресурсов. Как правило, оно равно времени загрузки html и css, указанного в теге head. Померить стандартными средствами это время невозможно. В Яндексе для этого используют Шуттилку, подробнее о которой можно посмотреть тут — www.slideshare.net/yandex/yasubbotnik-spb-decstepanova
Насколько мне известно, в Яндексе ориентируются на метрику «пользовательское счастье» — время, когда пользователь увидит то, зачем пришел на страницу. Это время не равно времени загрузки всех ресурсов. Как правило, оно равно времени загрузки html и css, указанного в теге head. Померить стандартными средствами это время невозможно. В Яндексе для этого используют Шуттилку, подробнее о которой можно посмотреть тут — www.slideshare.net/yandex/yasubbotnik-spb-decstepanova
Спасибо, полностью с вами согласен, метрика «пользовательское счастье» это гораздо более объективная оценка полезности оптимизации. Значит надо уменьшать время загрузки и обработки HTML:
И того, что указано в теге head. Собственно для этого я и решил попробовать разбить JS файлы на более мелкие, иначе время задержки остается огромным даже при кешировании (судя по показателям инспектора). Сейчас вот в поисках того, на чем можно это попробовать, что бы были конкретные цифры, как там на слайдах.
И того, что указано в теге head. Собственно для этого я и решил попробовать разбить JS файлы на более мелкие, иначе время задержки остается огромным даже при кешировании (судя по показателям инспектора). Сейчас вот в поисках того, на чем можно это попробовать, что бы были конкретные цифры, как там на слайдах.
Твиттер откзался от подобного подхода. Рендеринг контента на стороне клиента на практике выходит слишком прожорливым.
Sign up to leave a comment.
Кеширование всего HTML и подключение JS «на ходу»