это ответ на Ваши слова «Можете экстраполировать эту логику далее, что бы понять что загрузка 1 скрипта малого размера с отдельного домена в современных браузерах рояля практически не играет». Логика эстраполирована. Влияет: нам дорога каждая мелочь.
по поводу «почти не играет» я могу долго дискуссию поддерживать. Лучше всего это картинкой отобразить (по X — время загрузки в секундах, по Y — процент пользователей)
Да, у нас 58%, которые «в танке» и у которых «загрузка за 4 секунды». Но что прикажете делать с остальными 42%
в данном конкретном случае я (почти) с Вами согласен. Только скорость загрузки тоже ограничена.
Пусть в данном примере все 18 файлов имеют размер по 10 Кб. Всего 180 Кб + 20 Кб GA.
Если мы загружаем GA в самом конце — все отлично.
Если мы его загружаем асинхронно со всеми этими ресурсами, то замедление аж 10% в силу общего использования канала (от профайдера).
Да, у нас еще издержки на установление соединения, но они обычно не больше, чем издержки на загрузку. Так что 5% тут по-всякому выходит.
И это только для данного конкретного примера. Обычно на странице от 50 объектов и от 6 различных хостов.
Моя критика направлена не на подход, а на то, какое это на самом деле «улучшение».
GA сейчас и так ничего не блокирует, ибо вставляется перед </body>. Да, теперь (в некоторых браузерах с запрещенным через прокси GA) еще и индикатор загрузки не будет показываться.
Т.е. я не хочу сказать, что новый вариант подключения GA хуже. Нет. Я просто говорю, что он (почти) никак не лучше. Хотя шуму на этот счет уже много поднято.
если веб-мастера коммерческого сайта настолько (уж извините за прямоту) тупы, что не могут понять разницу между двумя кусками кода, то это уже на их совести :)
Есть и более изощренные методы подключения GA на сайте: например, в составе какой-то общей библиотеки. Так еще быстрее получится. И кэшироваться будет лучше (относительно данного сайта).
Любой браузер выделяет ограниченное число потоков (пруфлинк) на загрузку (причем, скорее всего, они делятся еще и между вкладками, надо бы проверить) сайта. Если у нас 1 поток занят, то это приводит (в зависимости от браузера) к разного рода последствиям: загрузка становится медленнее на 3-25%.
нет-нет, Вы тоже немного заблуждаетесь. async здесь означает лишь (имхо, надо бы почитать спецификацию для прояснения) только «плотность» загрузки потоков загрузки (сорри за тавтологию) в браузере и порядок выполнения скриптов. Т.е. скрипт во всех браузерах будет загружаться асинхронно, просто в некоторые «более асинхронно», чем в других
Развею несколько мифов относительно этого «улучшения»:
1) Как GA замедлял загрузку страницы, так и будет продолжать замедлять. «Из воздуха» скачиваться ничего не будет, пользовательский канал будет так же забит
2) Этот скрипт не добавляет загрузку GA после загрузки страницы. Он просто по-другому вызывает библиотеку.
3) Еще раньше (последние года два точно) GA «не замедлял» загрузку, ибо в нем нет document.write (картинка-счетчик вставляется через new Image())
4) Если раньше можно было запихнуть GA перед и забыть о нем, то теперь предлагается такое «псевдо»-улучшение. Что оно делает? Создает отдельный поток в браузере, загружающий скрипт и вставляющий его в head. Поток этот блокирует загрузку остальных ресурсов (т.е. у браузера несколько потоков, один будет занят GA вместо того, чтобы картинки, например, загружать). Если же вставлять этот код перед </body>, то он будет работать абсолютно аналогично предыдущему (тогда спрашивается, зачем вообще это «улучшение» нужно).
5) Более того, если сейчас все ломанутся вставлять этот вызов в head, то загрузка этих сайтов замедлится (в силу п.4). Т.е. такое «улучшение», на самом деле, не повысит скорость загрузки GA на сайтах, но увеличит точность счетчика (на это постоянно идет ругань, возможно, потому что GA тупо не успевает загрузиться). Но скорость загрузки страницы это понизит.
Такое вот «улучшение». Сухой остаток: либо у вас страница быстро загружается, либо точно считается при помощи внешних счетчиков. Третьего не дано (т.е. лучше всего считать внутренними серверными, конечно, но они не все могут). А еще лучше — сделать загрузку страницы настолько быстрой, что даже загрузка GA после нее будет происходить для всех пользователей.
да, но Google именно ETag использует. На больших проектах, где много статики, обычно не Apache используют. А ETag более конфигурируемый в этом плане, чем Last-Modified
если я правильно представляю логи их запросов на сайт, то сайт «просматривается» вглубь на 3-5 уровней (случайным образом). На каждого «пользователя» приходится 20-30 просмотров различных страниц (т.е. они «запускают» 10-20..-50 потоков, каждый из которых «тащит» свой набор страниц через случайные промежутки времени). IP вроде одинаковый (на каждую проверку — 50 сокетов, обычного сервера вполне хватит для 100 одновременных проверок, главное, чтобы канал позволял).
Все было бы хорошо, если бы Вы упоминали, в каких случаях эта комбинация не работает: когда мы запросили одним и тем же клиентом (например, прокси-сервером) сначала несжатую версию контента, затем сжатую — получили бы 304-ответ (при использовании If-None-Match) и отдали бы сжатую вместо несжатой. Только для статики существует Vary: User-Agent, Content-Encoding, которые данную проблему позволяют решить (в случае нормальных прокси-серверов, конечно :)
Т.е. проблема, конечно, есть, но при наличии прямых рук она на указанном окружении обходится (либо ее решение лежит уже за пределами данного окружения).
Да, у нас 58%, которые «в танке» и у которых «загрузка за 4 секунды». Но что прикажете делать с остальными 42%
Пусть в данном примере все 18 файлов имеют размер по 10 Кб. Всего 180 Кб + 20 Кб GA.
Если мы загружаем GA в самом конце — все отлично.
Если мы его загружаем асинхронно со всеми этими ресурсами, то замедление аж 10% в силу общего использования канала (от профайдера).
Да, у нас еще издержки на установление соединения, но они обычно не больше, чем издержки на загрузку. Так что 5% тут по-всякому выходит.
И это только для данного конкретного примера. Обычно на странице от 50 объектов и от 6 различных хостов.
GA сейчас и так ничего не блокирует, ибо вставляется перед </body>. Да, теперь (в некоторых браузерах с запрещенным через прокси GA) еще и индикатор загрузки не будет показываться.
Т.е. я не хочу сказать, что новый вариант подключения GA хуже. Нет. Я просто говорю, что он (почти) никак не лучше. Хотя шуму на этот счет уже много поднято.
Картинки, в среднем, меньше 30 Кб GA, так что занятие потока весьма ощутимо.
Также не забываем про IE, у которого с потоками вообще полный бардак (в версии 8 хоть немного разгребли).
Есть и более изощренные методы подключения GA на сайте: например, в составе какой-то общей библиотеки. Так еще быстрее получится. И кэшироваться будет лучше (относительно данного сайта).
Любой браузер выделяет ограниченное число потоков (пруфлинк) на загрузку (причем, скорее всего, они делятся еще и между вкладками, надо бы проверить) сайта. Если у нас 1 поток занят, то это приводит (в зависимости от браузера) к разного рода последствиям: загрузка становится медленнее на 3-25%.
asynchronous = еще один поток
1) Как GA замедлял загрузку страницы, так и будет продолжать замедлять. «Из воздуха» скачиваться ничего не будет, пользовательский канал будет так же забит
2) Этот скрипт не добавляет загрузку GA после загрузки страницы. Он просто по-другому вызывает библиотеку.
3) Еще раньше (последние года два точно) GA «не замедлял» загрузку, ибо в нем нет document.write (картинка-счетчик вставляется через new Image())
4) Если раньше можно было запихнуть GA перед и забыть о нем, то теперь предлагается такое «псевдо»-улучшение. Что оно делает? Создает отдельный поток в браузере, загружающий скрипт и вставляющий его в head. Поток этот блокирует загрузку остальных ресурсов (т.е. у браузера несколько потоков, один будет занят GA вместо того, чтобы картинки, например, загружать). Если же вставлять этот код перед </body>, то он будет работать абсолютно аналогично предыдущему (тогда спрашивается, зачем вообще это «улучшение» нужно).
5) Более того, если сейчас все ломанутся вставлять этот вызов в head, то загрузка этих сайтов замедлится (в силу п.4). Т.е. такое «улучшение», на самом деле, не повысит скорость загрузки GA на сайтах, но увеличит точность счетчика (на это постоянно идет ругань, возможно, потому что GA тупо не успевает загрузиться). Но скорость загрузки страницы это понизит.
Такое вот «улучшение». Сухой остаток: либо у вас страница быстро загружается, либо точно считается при помощи внешних счетчиков. Третьего не дано (т.е. лучше всего считать внутренними серверными, конечно, но они не все могут). А еще лучше — сделать загрузку страницы настолько быстрой, что даже загрузка GA после нее будет происходить для всех пользователей.
Т.е. проблема, конечно, есть, но при наличии прямых рук она на указанном окружении обходится (либо ее решение лежит уже за пределами данного окружения).