Вот 1С-Битрикс трубит во все трубы что благодаря композитной технологии (читай html-кеш, так оно как-то честнее) можно добиться скорости отдачи кешированных страниц в 2 мс.
А вот я мало того что не верю в такую скорость кроме как по локальной сети, так еще и не вижу ее ни на одном из сайтов заявленных в презентации как переведенные на композит.
Я взял сайты из презентации релиза 14.5 и протестировал скорость отдачи с кешем и без (добавьте любой параметр к адресу). Результат этот я ожидал и без тестирования, но имея в руках цифры как-то проще отстаивать свою позицию.
Так вот если взять за минимальную доступную скорость отдачи по нормальной сети (не локальной) скажем 40ms, то для ускорения в 100 раз страница изначально должна открываться 4 секунды. В смысле не просто открываться - генерироваться 4 секунды!
И если вы все же дочитали и мы говорим начистоту - ответьте честно на опрос, уважаемые коллеги
Попробовал найти самую нагруженную страницу на пока единственном проекте, который перенес на композит... Но там изначально все оптимизировано, компоненты не стандартные. На выводе и в кеше только нужное...
Циферки: 60ms-70ms - отдача с композитом выключаем композит: в среднем 300мс (но иногда 1.3секунды проскакивает) ini_set 64M (цифры остаются теже, за исключением что без композита максимум 2.6с)
если брать максимум и минимум, то разница x50 на отклик есть... если брать средние то x5. Но опять же можно сделать более нагруженные страницы и сделать всеже те x100 и больше...
Как выше написали, сайты то разные бывают. и на разных проектах композит будет давать разный выйгрыш (но по факту всегда будет давать выйгрышв скорости отдачи, и визуально в скорости загрузки). По крайней в голову пока не приходит - на каком проекте использование композитного кеша было бы ущербным...
ps. ну если отнять пинг до сервера до моего 30мс, до контакта 55мс Даже хваленый контакт по факту проигрывает, и сервер я сам настраивал с помощью гугла и под битрикс он в последнюю очередь оптимизирован...
Простите Алексей не хотел так начинать текс, но ваше понимание мира проистекает от незнания. Можно с пеной у рта доказывать, что земля плоская, а кто-то будет просто ездить вокруг света.
Давайте я попробую немного рассказать, что возникает от непонимания и невнимательности.
1. Тесты которые вы приводите делались без учета транспортных расходов до сервера - то есть не было последней мили (и об этом было сказано на презентации). 2. Почему вы показываете только тяжелую страницу на которой были собраны компоненты с большим временем выполнения на сервере и где страница генерировалась очень долго за счет большого количества запросов, и не показываете остальные скриншоты где показатели значительно меньше, тут уже вас можно обвинить в притягивание цифр под ваше желание. А мы специально просили сделать 3 замера различных по нагруженности страниц, чтобы показать, что ускорение будет различным для различных по сложности страниц. 3. Теперь о пользе, данная технология очень полезна для тяжёлых проектов, для проектов у которых время генерации страницы 2-3 секунды, у проектов которые хотят визуально показать клиенту, что сайт открылся мгновенно. 4. Данная технология это не html-кеш - скорей он небольшая часть этой технологии, и да, для нормальной работы технологии очень желательно корректно настроить Nginx и если он у вас не настроен или не используется, часть ускорения будет нивелировано. 5. Теперь еще раз как это работает, если на страницу хотя бы раз заходили до вас, вы увидите эту страницу фактически мгновенно, сервер ее отдаст примерно за 0,002-0,003 + время на транспорт, тут уже простите будет зависеть от того где находится ваш сервер (недаром мы перенесли Битрикс24 ближе к России, что бы уменьшить транспортные расходы) и что за провайдер у вас и как быстро он вам отдаст эту страницу, а уже вторым хитом будет обновлена та информация которая могла изменится (телефон на сайте, цены, блок с баннерами и т.п.), а вот этот хит пусть делается хоть 5 секунд. Не кто не говорил, что ускорение снизит нагрузку на сервер, но первый визуальный эффект когда страница отдается фактически мгновенно очень важен для восприятия человеком, и было сделано много исследований по этому поводу, как Яндексом так и другими компаниями, очень много докладов было на РИФ по данному поводу.
Исходя из сказанного, измерению подвергается первый хит, и время отображения страницы, и там ускорение очень значительное и зависит оно от корректности настройки вашего окружения, на котором все установлено, даже если потом ваш провайдер немного угробит эту цифру, все равно для восприятия это будет очень быстро и необычно.
Будьте внимательны к презентациям и словам, пытайтесь разбираться в том, что вам представляют, а не делать скоропалительные выводы на основание собственных пониманий. Ну или можно продолжать рассказывать, что земля плоская, а остальные пойдут исследовать и покорять круглый мир!
Юрий, я может быть излишне оптимистичен, но разве реализация моей идеи (http://idea.1c-bitrix.ru/10365/) не поможет избавить мир от подобных заблуждений? Вот мне например, тоже не совсем всё понятно (хотя на одном из проектов я уже заметил очень хороший эффект и всегда это добавляю в разговорах про композит. Просто не Х100 и это вызывает вопросы).
Меня вот кстати первый отклик (в сессии) не устраивает на моем сайте. Всем остальным доволен как слон (уж перед собой то я могу быть честен?). Как говорится, на чистоту, как и спрашивали.
Волошин Юрий, я придираюсь не к технологии. Она весьма и весьма хороша, ускорение дает. Вот только ускорение не такое как заявлено. Точнее я считаю что измерения выполнены так как было удобно тестировщику, чтобы показать красивые цифры.
Заявлено "Ускорение сайта в 100 раз". Чтобы посчитать ускорение давайте разберемся что мы называем скоростью работы сайта.
А скорость сайта (по моему мнению - если ваше отличается, объяснитесь) - время от ввода адреса в браузере до момента отрисовки страницы когда ее увидит пользователь. Учитывая что событие document.ready почти всегда следует с небольшим отставанием за этим, то с малой погрешностью можно сказать что окончание замера - событие document.ready в браузере. Именно это время я считаю корректным называть скоростью работы сайта.
Можно конечно зайти и с другой стороны: платформа не отвечает за количество скриптов/картинок/прочего хлама на странице. Соответственно когда 1С-Битрикс говорит о скорости работы сайта я вполне логично делаю допущение что речь идет о скорости с момента ввода адреса (отправки запроса) до момента получения последнего байта. Тобишь беру в качестве формулы: V = DNSLookup + SendRequest + ServerTime + ReadResponse
Вы же (коллеги из 1С-Битрикс) почему-то считаете скоростью работы сайта только ServerTime. Т.е. в идеальнйо среде с нулевыми расходами на сеть. Мы все вообще-то в вебе живем. А еще можно было вообще выкинуть из ServerTime время на передачу запроса к Nginx и тогда бы у нас единственный аргумент в формуле стремился к нуля, а ускорение получилось бы - бесконечность. Это же вообще круто!
Свою формулу я считаю более справедливой, тк расходы на обмен по сети вычитать нельзя. Сколько клиентов будут тестировать скорость по локальнйо сети? Или сформулирую по-другому - сколько фактически переведенных на композит сайтов увидят ускорение в 100 раз? - Даст бог 1% увидит. Вот и получается у нас видимость демократии.
С другой стороны Rusonyx могли бы использовать для проверки скорости свой собственный (весьма хороший кстати) сервис http://www.sitespeed.ru/ - но не использовали...
Маркетинг создает завышенные ожидания у клиентов. Клиенты прийдут и скажут - хотим ускорить сайт в 100 раз, битрикс же обещал! И что должны сказать партнеры? - А получается что партнеры должны объяснить клиенту, что все что битрикс обещал вы сможете увидеть при определенной фазе луны и только лично вы, а ваши клиенты - нет.
Соответственно данным опросом я ставил перед собой одну простую задачу - получить мнение коллег по цеху как жить с такой дезой. А технология хорошая, это даже под сомнение не ставлю. Она позволяет получить минимально возможное время отклика. Пролема лишь с циферками которые в рекламе используются. Еще бы технология не требовала BX.core и BX.ajax которые я так ненавижу за их вес... Или хотя бы дали возможность выбирать какие обработчики будут вставляться - BX или jQuery
Алексей повторюсь, ускорение есть и иногда и не в 100 раз, а более, и даже с учетом транспорта.
Все зависит от вашего проекта, на моем проекте с оптимизацией как сервера так и компонентов (уж простите мне это сделать легче), тяжелая страница у меня генерируется без кеша за 0,4 а с кешем 0,16 и включение композита может не дать и близко 100 кратного увеличения по скорости - но это на моем проекте.
и тут же
Проект партнеров, огромный магазин, главная в контракте прописана 5 секунд ПЯТЬ СЕКУНД, так как не какими оптимизациями при их нагрузках не могут сделать быстрей. Включают композит и страница вылетает за 0,3-0,5 не плохое такое ускорение, клиент не просто счастлив, он ликует.
Можно дальше обсуждать методики тестирования, можно дальше ругать маркетинг, а можно понимать где имеет смысл включать композит и его использовать, а где как в моем примере может быть и не очень.
Хотя даже у меня, доля мобильного трафика составляет 25-30% (специфика проекта), а вот на нем композит даст возможность мобильным пользователям увидеть сайт чуть быстрей, а я считаю это уже выигрыш. Меньше клиентов уйдет, я больше заработаю.
Волошин Юрий, думаю всех в этом обсуждении устроило бы если в описание технологии и соответственно в рекламу была бы добавлена пометка что под скорость понимается время отдачи контента сервером без учета сетевой задержки. И волки сыты и овцы целы, и никаких неоднозначных заявлений или обвинений в сокрытии фактов.
А про мобильный трафик и скорость - время отдачи играет меньшую роль чем время интерпретации всего что есть на странице. Я пытался общаться на эту тему с ТП, но как об стену. Раз уж Вы сейчас являетесь первопроходцем для всех новинок попробую обратить Ваше внимание: наибольшее ускорение на мобильниках можно получить за счет сокращения количества скриптов (медленные процессоры и тд). Собственно просьба была всего одна: 1. Не считать скрипты ядра такими особенными и не выкидывать их (при включенном объединении) через метод ShowHeadStrings, а выдавать как все остальные скрипты - через ShowHeadScripts. Это бы позволило переместить скрипты вниз body и ускорить момент отрисовки страницы
В связи с появлением композитной технологии хочется добавить еще одну: 2. Дать возможность разработчикам выбирать ту JS библиотеку которая будет делать замену композитных областей. Сейчас включение композитной технологии тянет за собой BX.core, BX.ajax которые весят в полтора раза больше чем jQuery. А как влияет наличие jQuery на "скорость сайта" на мобильных можете посмотреть тут http://flippinawesome.org/2014/03/10/...or-mobile/
Потестируйте, плиз, наш -- http://im24.ru Главная и страницы списка товаров (3 вида) должны быть уже в композите. Детальные страницы товаров имеют url с .html -- заработает чуть позже..
Проблема моделируется только на мобильном safari и только с включеннным композитом, было протестированно на 3х айфонах и на 5 сайтах с включенным композитом(http://flipbox.ru/, http://im24.ru/ и т.д.) Когда на сайте включен композит мы можем перемещатся по сайту стрелочками "вперед" и "назад", и если мы после этих переходов нажмем обновить страницу то мы получим пустую страницу и обновление уже не поможет, до тех пор пока не сбросится кеш браузера контента не будет видно.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».