Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 87
Для полноты публикации не хватает этой штуки, особенно под SPA:
addyosmani.com/basket.js
Бытует мнение, что с локалстора достается быстрей чем с кеша и даже быстрей чем из Application Cache
addyosmani.com/basket.js
Бытует мнение, что с локалстора достается быстрей чем с кеша и даже быстрей чем из Application Cache
Честно говоря не пробовал и прокомментировать не могу.
Единственное что могу точно сказать — браузерным кэшем, все же, управлять корректнее.
Тут же получается что работу нативного движка перекладываем на скрипты, которые не такие быстрые (надо проверять, конечно).
Ну и как минимум такая система на первую загрузку, скорее всего, даст просадку в скорости т.к. у нас выйдет цепочка: загрузка HTML -> загрузка данного скрипта -> достаем из кеша -> запрашиваем данные.
Честно говоря, если всё грамотно организовать то выглядит сомнительно.
Единственное что могу точно сказать — браузерным кэшем, все же, управлять корректнее.
Тут же получается что работу нативного движка перекладываем на скрипты, которые не такие быстрые (надо проверять, конечно).
Ну и как минимум такая система на первую загрузку, скорее всего, даст просадку в скорости т.к. у нас выйдет цепочка: загрузка HTML -> загрузка данного скрипта -> достаем из кеша -> запрашиваем данные.
Честно говоря, если всё грамотно организовать то выглядит сомнительно.
0мс на выполнение скриптовЕсть некоторые сайты, например — OneSkyApp (переводы), у которых большая часть работы делается скриптами. Так если требуется проделать быстрые операции со множеством строк, так вся работа превращается в адское ожидание. Прямо так — клик и сидишь ждешь секунды 3-4, потом опять клик, и опять ждешь. Причем, это и в ФФ и в Хроме — одинаково.
Так что, я прошу вас, веб-девелоперы, обращайте на это внимание! Если сайт загрузился за секунду, а потом каждый клик забирает еще 5, это не делает его быстрым.
Статья ориентирована на продвинутых разработчиков!
Хотел спросить, а что тут продвинутого?
Это очень круто что оно так для вас.
По факту же оказывается что большинство не знает многих вещей и это вызывает проблемы.
По факту же оказывается что большинство не знает многих вещей и это вызывает проблемы.
Созрел ответ.
Продвинутое то, что вместо того что бы просто «перенести js в низ страницы», или «включить серверный кэш», или сделать ещё какую-либо супер оптимизацию приходит понимание за счет чего реально это оптимизация происходит.
Это примерно как действие над числами в школе. А в университете ты узнаешь почему эти числа можно вычитать, а вот эти нельзя, например. И что такое число вообще.
Начинающему специалисту, обычно, не очень интересны причины, а важен результат без полного понимания.
Как и сказал до этого — очень круто что для вас оно не является продвинутым. Судя по плюсам для многих тут так — на то это и сообщество экспертов, что тут много опытных людей.
По своей практике могу сказать что если люди сделали хоть какие то оптимизации даже без понимания, за счет чего они ускорились, это уже хорошо :-)
Продвинутое то, что вместо того что бы просто «перенести js в низ страницы», или «включить серверный кэш», или сделать ещё какую-либо супер оптимизацию приходит понимание за счет чего реально это оптимизация происходит.
Это примерно как действие над числами в школе. А в университете ты узнаешь почему эти числа можно вычитать, а вот эти нельзя, например. И что такое число вообще.
Начинающему специалисту, обычно, не очень интересны причины, а важен результат без полного понимания.
Как и сказал до этого — очень круто что для вас оно не является продвинутым. Судя по плюсам для многих тут так — на то это и сообщество экспертов, что тут много опытных людей.
По своей практике могу сказать что если люди сделали хоть какие то оптимизации даже без понимания, за счет чего они ускорились, это уже хорошо :-)
Честно говоря, лично для меня была бы более интересна серверная оптимизация. С этим у многих совсем туго.
Этим постом я хотел показать что не только «серверная оптимизация» решает. (хотя это всё можно назвать серверной оптимизацией).
Более того, серверная оптимизация это лишь 1 шаг из этих всех, и, бывает, не самый значимый.
Более того, серверная оптимизация это лишь 1 шаг из этих всех, и, бывает, не самый значимый.
Всё зависит от продукта разработки, у меня щас например основной продукт апи, там кроме серверной оптимизации и архитектуры ничего нету.
Статья хорошая, большая и с виду очень красиво смотрится.
Если используете VPS под OpenVZ с древнегреческим ядром 2.6.32, то имеет смысл увеличить размер начального окно TCP:
Ну и для свежих ядер имеет смысл его немного увеличить:
$(ip r | grep default | xargs -I interface echo ip r c interface initcwnd 20 initrwnd 20)Ну и для свежих ядер имеет смысл его немного увеличить:
sysctl net.ipv4.tcp_rmem="4096 131071 6291456"
sysctl net.ipv4.tcp_wmem="4096 131071 6291456"
Статья понравилась, но в разделе «Установка соединения» очень не хватает упоминания «keep-alive» — параметра http-соединения, отвечающего за отсрочку разрыва соединения после начала простоя. В этом разделе у вас написано, что после загрузки всех данных соединение рвется и при каждом запросе после простоя браузер тратит время на установку нового соединения. Но в реальности это не всегда так. Период «keep-alive» помогает решить существенную часть таких проблем.
Очень хорошее замечание, спасибо. Может быть применимо при неравномерной загрузке.
Но, на самом деле, когда всё уже загружено — коннекты держать ни к чему.
А пока загружается — все коннекты и так забиты :-)
Но, на самом деле, когда всё уже загружено — коннекты держать ни к чему.
А пока загружается — все коннекты и так забиты :-)
> Но, на самом деле, когда всё уже загружено — коннекты держать ни к чему.
Здесь вы, конечно, погорячились… Keep-alive используется на подавляющем большинстве сайтов. И в этом определенно есть смысл. Сайт без Keep-alive — это сегодня скорее исключение. Даже если у вас нет аякса, запускаемого после полной загрузки страницы, пользователь же может сделать второй клик и здесь keep-alive поможет. Эта опция вошла в обиход задолго до web 2.0.
Здесь вы, конечно, погорячились… Keep-alive используется на подавляющем большинстве сайтов. И в этом определенно есть смысл. Сайт без Keep-alive — это сегодня скорее исключение. Даже если у вас нет аякса, запускаемого после полной загрузки страницы, пользователь же может сделать второй клик и здесь keep-alive поможет. Эта опция вошла в обиход задолго до web 2.0.
А пока загружается — все коннекты и так забиты :-)
И что? Без keep-alive мы на каждый запрашиваемый ресурс получаем необходимость прохождения полной процедуры установления соединения. С keep-alive-ом мы так же получаем «все коннекты забиты», только вот для части запрашиваемых ресурсов ну уровне TCP уже не нужно устанавливать соединение, за счет чего можно выиграть еще немного в битве за «мгновенно открывающийся сайт».
Я некорректно выразился. Скорее имел ввиду, что если у нас для значащего контента не выстраивается очередь (потому что грузится по 1 файлу каждого типа), то для него (значащего контента) keep-alive роли играть не будет, а только на последующие клики и обновления.
Но Keep-alive нужен точно. Причины вы расписали корректно.
Но Keep-alive нужен точно. Причины вы расписали корректно.
Статья отличная, но заголовок (и вступление) отпугивает. Ощущение, что под катом реклама «самого дешевого убыстрятеля сайтов» или еще какой-нибудь спам.
P.S. если ваш сайт уже загружается достаточно быстро, можно посмотреть на него со стороны пользователей со слабым каналом (мобильные клиенты, удаленные пользователи и т.п.). С (относительно) недавнего времени для этого отлично работает throttling во все тех же Chrome Developer Tools. И не забывать включать/выключать кэш (Disable Cache) для чистоты эксперимента.
P.S. если ваш сайт уже загружается достаточно быстро, можно посмотреть на него со стороны пользователей со слабым каналом (мобильные клиенты, удаленные пользователи и т.п.). С (относительно) недавнего времени для этого отлично работает throttling во все тех же Chrome Developer Tools. И не забывать включать/выключать кэш (Disable Cache) для чистоты эксперимента.
Ещё, если хотите посмотреть на DNS resolve настоящий то стоит открывать в приватной вкладке.
При этом, для перепроверки вкладку надо закрывать и открывать вновь.
Так это это добавляет где то 1 секунду на proxy negotation.
При этом, для перепроверки вкладку надо закрывать и открывать вновь.
Так это это добавляет где то 1 секунду на proxy negotation.
Нет, почему же, лично у меня, после того, как я прочитал этот заголовок, сложилось очень основательное мнение, что главная мысль это статьи будет заключатся в том, что мы все этого хотим, но это невозможно (именно мгновенная загрузка) из-за того, того, и того. Типа перестаньте ждать хорошего и живите сегодняшним днем, ведь жизнь прекрасна) Не, серьезно. А тут прям исследование, советы действенные, определенно плюс.
Как завидую разработчикам, которые выжимают каждые 0.5 секунд при загрузке страницы… Просто приходится работать с Sharepoint, конечно его можно сделать быстрым, но обычно это стоит СТОЛЬКО, что заказчик просто не оплачивает frameword-oriented хаки. И вот получается, что на хабре читаешь про крутые оптимизации, а на работе приходится работать с сайтами, которые местами грузятся минутами (типичный пример — выгрузка аудита шарика). И не потому, что долго рендерится страница, а потому что фреймворк внутри себя переваривает такой объем данных, что вот это время «до первого байта» составляет как раз-таки эти минуты, ну а потом 1-3 секунды на передачу и отрисовку того, что получилось… А ведь шарик это не единственный такой фреймворк…
А ещё был браузер Опера ( до версии 12.17), любим был именно за то, что мгновенно рендерил контент, а потом подгружал свистелки-перделки. А потом этот браузер убили.
Может быть это не совсем к оптимизации скорости, но порой очень бесит, что сайты через 1-2 секунды после появления текста (а порой и позже) прыгают. Особенно если на странице есть ссылка, которую ты хочешь нажать быстрее, чем загрузится всё остальное.
Сюда сюда. Начитаются люди, что все скрипты надо переносить в конец, ну и переносят, при том что половина вёрстки у них зависит от js.
Какой толк от того, что сайт «загрузился», если им пользоваться нельзя…
Какой толк от того, что сайт «загрузился», если им пользоваться нельзя…
В самом начале статьи я говорил как рааз про TTI.
Ситуаций когда контент прыгает вообще не должно быть.
Почти каждое сообщение в посте и комментариях является поводом написать еще пост :)
Ситуаций когда контент прыгает вообще не должно быть.
Почти каждое сообщение в посте и комментариях является поводом написать еще пост :)
Очень часто это бывает тупо из-за больших <img> на медленном инете. Картинки сначала нет (элемент 0px высотой), а потом подгружается метаинфа и текст «уезжает». Ответ этому — принудительное указание img height.
Когда я увлекался подобными оптимизациями, то залипал на этом сервисе, может кому пригодится
www.webpagetest.org/result/151228_TV_XGX
www.webpagetest.org/result/151228_TV_XGX
Совсем за бортом остались SPDY(HTTP/2.0) их использование часто дает положительный баланс даже с учетом потерь на установку соединения — если элементов много, а соединение одно — профит очевиден.
Я ссылку в статье прикладывал. Продублирую тут: habrahabr.ru/post/242255
Большое спасибо. Это годная, я бы сказал монументальная статья.
Как ни странно, в 2015 году многие разработчики до сих пор не обращают внимание на оптимизацию скорости сайта, а зря. К тому же Гугл сейчас дает весомые плюшки продвинутым сайтам, особенно под мобильный траффик
Как ни странно, в 2015 году многие разработчики до сих пор не обращают внимание на оптимизацию скорости сайта, а зря. К тому же Гугл сейчас дает весомые плюшки продвинутым сайтам, особенно под мобильный траффик
Пожалуйста, напишите над кодом ускорения клика большими красными буквами, что трюки конкретно этого семейства надо не просто подбирать индивидуально, а вообще если и использовать, то только в динамичных играх. Ну, точнее, mousedown ещё терпимо, но ведь эти горе-разработчики аналогично «оптимизируют» touchstart, потому что ах, ужас, 300 мс. Поубивал бы.
Большую скорость малого количества данных мы рассматривать не будем, т.к. рядовой сайт, все же, занимает от 500кб.
Не очень понятна фраза, но часто можно оптимизировать время передачи данных радикальным уменьшением количества передаваемых данных путём передачи только заголовков в ответах 304 Not Modified на большинство запросов.
На некоторых сайтах даже контентные страницы получается так оптимизировать: используя If-Modified-Since и время обновления всех (или значимых) сущностей, на основании которых генерится страница (перед рендерингом html/xml/json выбираем время обновления и сравниваем с пришедшим в запросе), либо etag (после рендеринга вычисляем хеш ответа и сравниваем с пришедшим в запросе).
А уж статику так отдавать, если не используется по каким-то причинам TTL-based кэширование, просто необходимо.
Статья интересная. Автору спасибо. Хоть я и не увидел ничего нового, но кое с чем я с автором не согласен:
Я раньше много экспериментировал с оптимизацией, сжатием и http кешем и пришел к следующему выводу: в случае css лучше объединять все в 1 файл, а в случае js можно попробовать разбить на компоненты, но аккуратно
Если js не влияет на визуализацию страницы, а только на функциональность то его можно разбить на модули и вынести в отдельные файлы. Пользователь переживет если раскрывашки, автокамплит, датапикер и тд будет работать не сразу как он открыл страницу, а вот кривую верстку он не переживет.
Мм, окей. Давайте тогда объединим все-все js файлы в 1 и все-все css файлы в 1. Тогда же уместимся в лимиты любого браузера, ну и грузиться будет быстро.
На правильном пути, но это всё ещё некорректно. Вам не нужны все-все js и css файлы для начальной отрисовки страницы. Даже если часть не используется — они все равно занимают канал и процессорное время. Ну и ещё при любом изменении самого маленького файлика кэш инвалидируется и пользователю загружать всё заново.
Я раньше много экспериментировал с оптимизацией, сжатием и http кешем и пришел к следующему выводу: в случае css лучше объединять все в 1 файл, а в случае js можно попробовать разбить на компоненты, но аккуратно
- если дополнительные стили подгружать через js мы потеряем время на исполнение js кода отвечающего за загрузку стилей
- если загружать через link то потерь будет меньше, но появится проблема с очередью загрузки, ведь мы хотим что бы дополнительные стили грузились после загрузки основных данных. В случае загрузки дополнительных js модулей их можно разместить в конце html документа
- мы потеряем время на загрузку дополнительных стилей. еще запрос, ожидание, загрузка, рендор. В сумме это будет дольше чем 1 большой запрос. Для css это критично, а для js нет
- мы увеличиваем количество запросов к серверу, что может быть критично для сервера, канала и тарифного плана хостера
- в данном случае мы рассматриваем первую загрузку на холодном кеше, при следующем запросе css и js будут браться из локального кеша браузера и в этом случае будет быстрее если это будет один файл. Даже если данные запрашиваются из кеша, это все равно запрос и чем меньше запросов тем быстрее
- аргумент с изменением файлов тоже не аргумент потому что это относится к последующим запросам, а файл css или js меняется, если меняется, только после деплоя который в нормальных проектах делается не более 2 раз в неделю. Если изменения произошли в 3 файлах из 5, то мы загрузим 3 новых файла или 1 если все 5 файлов сжаты в 1. Объем больше, но запросов меньше
- вообще в случае деплоя нормально сбрасывать весь кеш и в этом случае первый пользователь после деплоя генерит не только локальных кеш, но и кеш на сервере и от этого никуда не деться
- так же не стоит забывать об обфускации css и js кода которая может дать до 40% уменьшения объема и тем самым повышение скорости загрузки
- можно еще использовать gzip компрессию уменьшив размер файлов еще на ~5%. Но я правда не знаю хранит ли браузер в локальном кеше сжатую версию или нет. Если хранит сжатую то на каждый запрос браузер будет тянуть из кеша, разжимать и применять. В этом случае сжатие будет только вредить
- реальная экономия получится только если будет загружаться 0-2 из 10 дополнительных модулей/файлов, а если таких файлов 5-15 на запрос, то выигрыша особого уже не будет
Если js не влияет на визуализацию страницы, а только на функциональность то его можно разбить на модули и вынести в отдельные файлы. Пользователь переживет если раскрывашки, автокамплит, датапикер и тд будет работать не сразу как он открыл страницу, а вот кривую верстку он не переживет.
Спасибо за развернутый комментарий. Отвечу по пунктам:
1) Дополнительные стили на то и дополнительные, что они не требуются для отображения самой страницы. Т.е. на время отрисовки отложенная загрузка любым из способов повлиять не должна.
3) Как говорил раньше — важно разделять приоритетный и вторичный контент. Приоритетный желательно объединять в один, да. Остальные для отрисовки того что на странице не требуются, и как следствие, не влияют на скорость, если не первышают ограничений.
4) Я не уверен что оптимизации глубокие такие имеют смысл на обычно хостинге. Честно говоря привык уже, как минимум, к VPS. С хостингом обычным может вылезти ещё ряд проблем/ограничений которые бы следовало рассматривать отдельно.
5) Можно замерить, ради интереса. Я думаю что там незначительная разница будет, при правильной организации порядков загрузки.
6) Ну тем не менее, если 2 раза в неделю, значит у пользователя 2 раза в неделю сайт медленно откроется :-)
7) Это зависит от политики инвалидации кеша. В некоторых ситуациях кэш генерируется заранее, возможно, даже, в процессе деплоя. для ряда страниц для неакторизованных пользователей, например.
8) Честно говоря я это вообще само-собой разумеющимся считал :-)
9) Гзип дает процентов 80, обычно, для текстов. Насчет кэша интересное замечание, честно говоря, не задумывался :-) Предполагаю что, таки, несжатую версию хранит, но не уверен.
10) Так и должно загружаться немного дополнительных. Более того их можно группировать автоматически различными способами. По 15 запросов слать плохой вариант, конечно. Ко всему надо с умом подходить.
Ну и по раскрывашкам, автокомплитам и т.п. — абсолютно верно. Можно ещё посмотреть Heatmap сайта, куда и когда кликают, и уже от этого отталкиваться при принятии решений.
1) Дополнительные стили на то и дополнительные, что они не требуются для отображения самой страницы. Т.е. на время отрисовки отложенная загрузка любым из способов повлиять не должна.
3) Как говорил раньше — важно разделять приоритетный и вторичный контент. Приоритетный желательно объединять в один, да. Остальные для отрисовки того что на странице не требуются, и как следствие, не влияют на скорость, если не первышают ограничений.
4) Я не уверен что оптимизации глубокие такие имеют смысл на обычно хостинге. Честно говоря привык уже, как минимум, к VPS. С хостингом обычным может вылезти ещё ряд проблем/ограничений которые бы следовало рассматривать отдельно.
5) Можно замерить, ради интереса. Я думаю что там незначительная разница будет, при правильной организации порядков загрузки.
6) Ну тем не менее, если 2 раза в неделю, значит у пользователя 2 раза в неделю сайт медленно откроется :-)
7) Это зависит от политики инвалидации кеша. В некоторых ситуациях кэш генерируется заранее, возможно, даже, в процессе деплоя. для ряда страниц для неакторизованных пользователей, например.
8) Честно говоря я это вообще само-собой разумеющимся считал :-)
9) Гзип дает процентов 80, обычно, для текстов. Насчет кэша интересное замечание, честно говоря, не задумывался :-) Предполагаю что, таки, несжатую версию хранит, но не уверен.
10) Так и должно загружаться немного дополнительных. Более того их можно группировать автоматически различными способами. По 15 запросов слать плохой вариант, конечно. Ко всему надо с умом подходить.
Ну и по раскрывашкам, автокомплитам и т.п. — абсолютно верно. Можно ещё посмотреть Heatmap сайта, куда и когда кликают, и уже от этого отталкиваться при принятии решений.
4) Я не имел в виду конкретно хостинг. Тот же VPS может быть с ограниченным трафиком
7) Весь кеш все равно не сгенерируешь и сервер все равно придется ждать
В общем это довольно спорный момент. Нужно пробовать оптимизировать на конкретном проекте очень аккуратно и с умом. Если делать в лоб, то можно и потерять в скорости. Основная моя мысль была в этом.
7) Весь кеш все равно не сгенерируешь и сервер все равно придется ждать
В общем это довольно спорный момент. Нужно пробовать оптимизировать на конкретном проекте очень аккуратно и с умом. Если делать в лоб, то можно и потерять в скорости. Основная моя мысль была в этом.
Мне тоже показался сомнительным этот пункт. Добавляет ряд проблем и замедляет последующие загрузки страниц. А выигрыш на большинстве проектах совсем миниатюрным (далеко не каждый проект состоит из мегатонн JS и CSS). Лично я вижу этот пункт так:
А подход описываемый автором, мне кажется, больше подходит огромным web-приложениям, где иначе попросту нельзя. Т.е. не бложеги, интернет-магазины, корпоративные сайты и пр., а что-нибудь состоящее из десятков модулей, мегатонн скриптов и пр.
- Разбивать JS на бандлы. К примеру определить, что нужно для корректной работы большинства посещаемых страниц, и собрать это в 1 банлд. Но не включать туда какие-либо редкозадействуемые большие библиотеки. Их подгружать в отдельном\ых банлдах. Чем хорош такой подход? Мы проиграем, к примеру, 10-20 ms при первоначальной загрузке, зато все последующие будут почти моментальными. По сути всё будет сводится к получению HTML. Специфические модули, требующие что-нибудь большое и тяжёлое загрузятся by demand.
- Разбивать CSS на бандлы. Исходить из его размера. Если суммарный не административный CSS-код не превышает, положим, 60 KiB, грузить его 1 файлом. Если же проект настолько большой, что CSS-кода по колено, нужно заморочиться и сгруппировать.
- CSS с datauri ресурсами грузить отдельно. Ибо они второстепенны. Страница без иконок будет выглядеть почти также как и страница с иконками. Но отобразится быстрее. Но это не касается шрифтов. Если грузить их отдельно, например, с google fonts, то привыкайте к тому, что страница может скакать по мере загрузки. Не самое приятное зрелище.
- По возможности избегать доп. шрифтов. Если же этого сделать неудаётся, стараться избегать их применения в разнородном контенте, который может включать в себя обширный набор символов. Зачем? В таком случае можно вместо полного шрифта (250+ KiB) загрузить его обрубок на 40-60 KiB, включащий только числа, символы используемых алфавитов, некоторые спец. символы, пунктуацию и пр.
А подход описываемый автором, мне кажется, больше подходит огромным web-приложениям, где иначе попросту нельзя. Т.е. не бложеги, интернет-магазины, корпоративные сайты и пр., а что-нибудь состоящее из десятков модулей, мегатонн скриптов и пр.
Спасибо, faiwer, хорошо подметил.
Последние 5+ лет я занимаюсь исключительно крупными проектами и уже забыл о маленьких :-)
Для маленьких проектов действительно достаточно всё объединить и этого уже хватит что бы укладываться в секунду.
Про бандлы: современные менеджеры зависимостей умеют автоматически объединять нужные ресурсы в бандлы и понимать какой и когда подгружать. Это тема для отдельной, очень хорошей и обстоятельной статьи.
По datauri — зависит от количества. Если там 10 иконок по 500 байт то абсолютно ничего страшного нет в загрузке сразу. Если там тяжелая графика — стоит подумать, а в правильном ли она месте находится? :-)
Последние 5+ лет я занимаюсь исключительно крупными проектами и уже забыл о маленьких :-)
Для маленьких проектов действительно достаточно всё объединить и этого уже хватит что бы укладываться в секунду.
Про бандлы: современные менеджеры зависимостей умеют автоматически объединять нужные ресурсы в бандлы и понимать какой и когда подгружать. Это тема для отдельной, очень хорошей и обстоятельной статьи.
По datauri — зависит от количества. Если там 10 иконок по 500 байт то абсолютно ничего страшного нет в загрузке сразу. Если там тяжелая графика — стоит подумать, а в правильном ли она месте находится? :-)
Про бандлы: современные менеджеры зависимостей умеют автоматически объединять нужные ресурсы в бандлы и понимать какой и когда подгружать. Это тема для отдельной, очень хорошей и обстоятельной статьи.
Не очень понял, что вы имеете ввиду. Автоматически формируемые бандлы исходя из нужд конкретной страницы? Это же перекачивать каждый раз груду уже загруженного JS. Или я не правильно вас понял? Да и вообще не представляю как такое провернуть тем же requireJS… Разве что строить карту зависимостей и скакать от неё.
По datauri — зависит от количества. Если там 10 иконок по 500 байт то абсолютно ничего страшного нет в загрузке сразу. Если там тяжелая графика — стоит подумать, а в правильном ли она месте находится? :-)Я туда пихаю всю интерфейсную графику (не использую спрайты). Получается прилично. До 200 KiB в сжатом виде. А так да. Если там всего на 10-ок KiB, то смысла разделять нет.
Например в комплексе JavascriptMVC с CanJS идет StealJS, который позволяет:
Собственно он создает наборы скриптов.
При этом контролирует что уже загружено, а что нет, и лишнее никогда не скачивает.
Конечно же, любое, даже автоматизированное решение, требует первоначального изучения и настройки.
Плюс условием использования, по сути, является AMD. Но это очень хорошее условие, на самом деле :-)
- Minifies JS, Less, CoffeeScript, and client-side templates.
- Build shared dependencies across multiple apps.
- Package modules for progressive loading.
- Create modules that work without steal.
Собственно он создает наборы скриптов.
При этом контролирует что уже загружено, а что нет, и лишнее никогда не скачивает.
Конечно же, любое, даже автоматизированное решение, требует первоначального изучения и настройки.
Плюс условием использования, по сути, является AMD. Но это очень хорошее условие, на самом деле :-)
Покликал по вашим ссылкам. То 404, то просто декларация метода. В общем, не ясно каким именно образом это работает. Для StealJS нужно собрать карту всех зависимостей, чтобы он предварительно, на этапе деплоя, сделал все возможные банлды? Очень сомнительный вариант. Или он заставляет сервер лепить их на ходу? Гхм, ИМХО, вариант не лучше. Да и в конечном счёте, для большинства проектов (не обладающих мегабайтами JS), любая реализация подобного «умного» менеджера загрузки зависимостей, будет постоянно подгружать килобайты скриптов от страницы к странице. Килобайты… Даже не десятки. В общем смысл ускользает.
Пример по ссылке работает с указанным фреймворком и пробовал я это только с ним.
Для использования необходимо корректно оформлять код — т.е. прописывать все зависимости.
На стадии сборки можно указать глубину проработки и сприпт собирает разлинчые комбинации файлов.
Там не все возможные комбинации, а, скорее, грамотные их наборы в зависимости от вашего проекта.
Как сказал ранее — генерация не на лету, а на этапе сборки.
Вполне можно настроить минимальные размеры файлов — остальные он будет объединять.
Описанных вами ситуаций не будет, и смысл не ускользает. Но только при грамотном подходе к разработке, да. Это очень не просто и умеет не так много разработчиков, как хотелось бы.
Для использования необходимо корректно оформлять код — т.е. прописывать все зависимости.
На стадии сборки можно указать глубину проработки и сприпт собирает разлинчые комбинации файлов.
Там не все возможные комбинации, а, скорее, грамотные их наборы в зависимости от вашего проекта.
Как сказал ранее — генерация не на лету, а на этапе сборки.
Вполне можно настроить минимальные размеры файлов — остальные он будет объединять.
Описанных вами ситуаций не будет, и смысл не ускользает. Но только при грамотном подходе к разработке, да. Это очень не просто и умеет не так много разработчиков, как хотелось бы.
Т.е. по сути разница с моим вариантом (когда разработчик вручную определяет что попадёт в тот или иной бандл) в том, что эта штука пытается это сделать сама? Наверное, для «грамотных наборов» ей нужно подсказывать, да? Возвращаемся к тому, с чего начали?
По-большому счёту я не вижу в ней смысла. Во всяком случае в своих проектах. Бандлы декларируются в полуавтоматическом режиме. Т.е. большая часть содержимого бандлов собирается по маскам к ресурсам. Некоторые ручные корректировки (вроде не грузить raphaelJS в основном бандле, или поместить Ckeditor в отдельный от общего админского бандла, т.к. он попросту огромен) выполняются вручную. Помимо формирования самих бандлов формировать конфиг для requirejs, чтобы оный знал какие бандлы в каких случаях подтягивать. Вот, собственно, и всё.
По-большому счёту я не вижу в ней смысла. Во всяком случае в своих проектах. Бандлы декларируются в полуавтоматическом режиме. Т.е. большая часть содержимого бандлов собирается по маскам к ресурсам. Некоторые ручные корректировки (вроде не грузить raphaelJS в основном бандле, или поместить Ckeditor в отдельный от общего админского бандла, т.к. он попросту огромен) выполняются вручную. Помимо формирования самих бандлов формировать конфиг для requirejs, чтобы оный знал какие бандлы в каких случаях подтягивать. Вот, собственно, и всё.
Это очень не просто и умеет не так много разработчиков, как хотелось бы.Дык ведь нет, вроде бы всё достаточно просто. ES6 modules, AMD и пр. виды подключения зависимостей и без того явно вынуждают разработчиков указывать все зависимости. Остальное делает «система».
Не возвращаемся. Автоматически она делает, можно донастроить по желанию.
Никаких дополнительных конфигов вообще не требуется, за редким исключением.
Зависимости надо прописывать корректно, вот и всё.
Для кого? :-) Для joonior разработчика просто?
Ну не знаю. Почему то всё просто-просто, но куда не глянешь — всё не так.
Так о том речь и была. Зависимости прописаны -> остальное делает система. Вот и всё.
Никаких дополнительных конфигов вообще не требуется, за редким исключением.
Зависимости надо прописывать корректно, вот и всё.
Дык ведь нет, вроде бы всё достаточно просто.
Для кого? :-) Для joonior разработчика просто?
Ну не знаю. Почему то всё просто-просто, но куда не глянешь — всё не так.
ES6 modules, AMD и пр. виды подключения зависимостей и без того явно вынуждают разработчиков указывать все зависимости. Остальное делает «система».
Так о том речь и была. Зависимости прописаны -> остальное делает система. Вот и всё.
автор, у вас есть хотя бы один пример реализации всего того, что вы описали в статье?
Вопрос не совсем корректный.
В зависимости от сайта ряд вещей может варьироваться. Например, как упоминали выше, если сайт маленький и там всех скриптов и стилей не больше чем 100кб то их реально можно объединить и разбивать ни к чему.
В пример можно взять гугл. DNS resolve 10мс, пинг у меня вообще до них 2мс (судя по всему стоит локальный кеш провайдера). Открывается всё очень быстро.
Если вопрос в том — есть ли у меня проект где это всё реализовано — нет, нету.
В зависимости от сайта ряд вещей может варьироваться. Например, как упоминали выше, если сайт маленький и там всех скриптов и стилей не больше чем 100кб то их реально можно объединить и разбивать ни к чему.
В пример можно взять гугл. DNS resolve 10мс, пинг у меня вообще до них 2мс (судя по всему стоит локальный кеш провайдера). Открывается всё очень быстро.
Если вопрос в том — есть ли у меня проект где это всё реализовано — нет, нету.
Ожидание очереди
Уже не очень актуально в свете SPDY/HTTP2, как минимум тут уже другая механика.
Ну начнем с того, что там тоже есть ряд проблем. Я ссылку на пост про HTTP2 давал.
Ну и да, то-то на всех сайтах вокруг внедрен HTTP2 и такая проблема нигде не встречается :-D
Ну и да, то-то на всех сайтах вокруг внедрен HTTP2 и такая проблема нигде не встречается :-D
Советую посмотреть на еще один интересный подход к проблеме — glebbahmutov.com/blog/instant-web-application
Оно позволяет моментально отрисовать тяжеловесную страницу при перезагрузке.
Вся страница помещается в localStorage.
Оно позволяет моментально отрисовать тяжеловесную страницу при перезагрузке.
Вся страница помещается в localStorage.
<оффтоп>
> Здравствуйте, меня зовут Александр Зеленин
Не ожидал, что на Хабре найдётся полный тёзка
</оффтоп>
> Здравствуйте, меня зовут Александр Зеленин
Не ожидал, что на Хабре найдётся полный тёзка
</оффтоп>
Конечно, мой ламерский коммент среди стольких профи будет выглядеть наивно, но всё же.
Полагаю, есть радикальный и простой способ ускорить браузинг — вернуться в 90-е и web 1.0. Для очень многих задач на самом деле ИМХО достаточно простого html и статичных картинок. Почему простые лёгкие сайты без свистелок сегодня практически не создаются? Устаревший дизайн? Дело на любителя, меня устроит и угловатый стиль 90-х, ну в крайнем случае добавим чуть плюшек для аккуратных градиентов и закруглений элементов. Но зачем тащить на страницы кучу прочего барахла?
Полагаю, есть радикальный и простой способ ускорить браузинг — вернуться в 90-е и web 1.0. Для очень многих задач на самом деле ИМХО достаточно простого html и статичных картинок. Почему простые лёгкие сайты без свистелок сегодня практически не создаются? Устаревший дизайн? Дело на любителя, меня устроит и угловатый стиль 90-х, ну в крайнем случае добавим чуть плюшек для аккуратных градиентов и закруглений элементов. Но зачем тащить на страницы кучу прочего барахла?
Всё зависит от сайта.
Как ты себе представляешь, например, онлайн стриминг в веб 1.0? С перезагрузкой страниц и всем прочим. Вот тут и начинаются проблемы.
На страницы не спроста лепят кучу скриптов и остальных вещей. Вовсе не для того, что бы просто навесить. Их вешают что бы у тебя были взаимодействия моментальные. Что бы ты мог лайк поставить, увидеть чужие лайки здесь и сейчас, комментарий написать и так далее.
Для ряда сайтов, конечно, самых простых, такое подойдет от части, но — если посмотришь на описание, то от самого сайта не всё зависит, но так же играет роль его расположение и т.п.
Как ты себе представляешь, например, онлайн стриминг в веб 1.0? С перезагрузкой страниц и всем прочим. Вот тут и начинаются проблемы.
На страницы не спроста лепят кучу скриптов и остальных вещей. Вовсе не для того, что бы просто навесить. Их вешают что бы у тебя были взаимодействия моментальные. Что бы ты мог лайк поставить, увидеть чужие лайки здесь и сейчас, комментарий написать и так далее.
Для ряда сайтов, конечно, самых простых, такое подойдет от части, но — если посмотришь на описание, то от самого сайта не всё зависит, но так же играет роль его расположение и т.п.
Стриминг — это да, хотя и сейчас зачастую при запуске видео на веб-странице почему-то запускается фоном Adobe Flash Player.
Лайки разве нельзя реализовать простым лёгким яваскриптом?
А вот всякие онлайн-магазны, форумы, презентации можно вполне делать лёгкими. Сейчас даже обычные форумы стали слишком умными и навороченными: кидаешь пост со ссылкой на ютуб — а эта сволочь парсит её и вставляет на страницу как видео, хотя я не просил. Ghostery находит на страницах десятки следящих скриптов.
Прямо сейчас я вот обучаю мать азам работы за компом и в инете, и все эти помогалки и свистелки проклинаю с тройной энергией, потому что они окончательно путают новичка, ломая всю логику. Чуть мышь в сторону — что-то всплывает, заслоняет, фокус ввода перехватывается и прочий ад.
Лайки разве нельзя реализовать простым лёгким яваскриптом?
А вот всякие онлайн-магазны, форумы, презентации можно вполне делать лёгкими. Сейчас даже обычные форумы стали слишком умными и навороченными: кидаешь пост со ссылкой на ютуб — а эта сволочь парсит её и вставляет на страницу как видео, хотя я не просил. Ghostery находит на страницах десятки следящих скриптов.
Прямо сейчас я вот обучаю мать азам работы за компом и в инете, и все эти помогалки и свистелки проклинаю с тройной энергией, потому что они окончательно путают новичка, ломая всю логику. Чуть мышь в сторону — что-то всплывает, заслоняет, фокус ввода перехватывается и прочий ад.
Юлмарт старый и новый — небо и земля. Сбербанк примерно в ту же сторону повернул, но ещё далеко от него.
А что лучше для сторонних библиотек, грузить их отдельно с какого-нибудь cdnjs или объединять со своими скриптами в один большой js?
Как уже писали до этого — сперва определимся насчет суммарного веса всех скриптов в gzip — если менее 100кб то грузим вместе, одним.
Объединять стоит только библиотеки, которые необходимы для отрисовки, иначе лучше отложить их загрузку.
Насчет публичных CDN — тут надо принимать решение по безопасности. Если произойдет подмена скрипта на публичном CDN на вирусный (с кейлоггером, например), то ваш сайт пострадает. Тут все зависит от сайта и от уровня паранойи :-)
Объединять стоит только библиотеки, которые необходимы для отрисовки, иначе лучше отложить их загрузку.
Насчет публичных CDN — тут надо принимать решение по безопасности. Если произойдет подмена скрипта на публичном CDN на вирусный (с кейлоггером, например), то ваш сайт пострадает. Тут все зависит от сайта и от уровня паранойи :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я хочу, чтобы сайты открывались мгновенно