Опубликованы результаты изучения производительности различных методов извлечения коллекции ресурсов, используя для обращения к серверу протоколы HTTP/1.1, HTTP/2 и HTTP/2 + Server Push. В исследовании также оценено влияние на производительность нахождение запрашиваемых данных к кэше браузера и манипуляции ресурсами на уровне логики работы приложения (сведение ресурсов в единый JSON-блок)...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52129
>чем оптимизация выполняемого в браузере клиентского кода.так webassembly не нужен?
Он никогда и не был нужен ; )
Он для других задач.
для каких? для почёсывания разработчиками собственного величия?
Для отвязки от языка это раз. Для ускоренной передачи и выполнения два. Причём первое самое важное ибо жс должен умереть.
Вебмакак пристроить к делу вместо настоящих программистов.
Скорее, чтобы нормальные программисты могли и под браузер писать уже наконец, не используя вебмакачьи инструменты. Хотя если сильно хочется - собирают чем-нибудь типа emscritpten'а, но это изврат - JS веьма плохой эрзац ассемблера.
> Скорее, чтобы нормальные программисты могли и под браузер писать уже наконец, не
> используя вебмакачьи инструменты. Хотя если сильно хочется - собирают чем-нибудь типа
> emscritpten'а, но это изврат - JS веьма плохой эрзац ассемблера.Ну вот смотри, анон:
- придумали для программистов Жабу, дабы писать интерактивное для клиента — программисты крутили носом и кричали «фу»;
- придумали для программистов Флеш, дабы писать интерактивное для клиента — программисты крутили носом и кричали «фу»;
- придумали для программистов Дотнет, дабы писать интерактивное для клиента — программисты крутили носом и кричали «фу».
А жлобоскрипт им — сплошное ми-ми-ми! Что ж это за программисты такие — раз им столь мил худший ЯП всех времён и народов?
Я уж не хочу в стопицотый раз заводить разговор о том, что веб-браузер — это программа для просмотра веб-страничек, а не среда выполнения приложений.
> - придумали для программистов Жабу, дабы писать интерактивное для клиента — программисты
> крутили носом и кричали «фу»;Потому что индусы оказались ленивыми, в рантайм и обвес пришлось засунуть все что можно и нельзя. Програмисты и охренели от того что hello world полчаса стартует и занимает весь ксеон единолично своим JITом. Вот если кэши погреть, все дела... но так только индусскому коду для энтерпрайза катит.
> - придумали для программистов Флеш, дабы писать интерактивное для клиента — программисты
> крутили носом и кричали «фу»;Потому что хотя адоб и сделал эффективные структуры данных, открытых тулсов для разработки не срослось, JS стал обгонять action script по скорости, а это еще и с остальной вебстраницей не интегрируется вообще никак.
Ну вот например, решительно невозможно прислать гиперссылку на часть флешового мувика. Можно как максимум сказать: зайти туда, нажать next, 4, 7, "yes", "submit". Но это убивает весь смысл веба - навигация уровня шлепания сетап визарда под виндой. Ну и фирма адоб так лихо всех прокатывала, желая за ARM версию флеша денег, что с пришествием мобильных устройств они сами себя выписали в obsolete. Нет флеша на вон тех миллиардах устройств - и это большой сегмент рынка. Потому что эпл и гугл жаба давит адобе платить. Собственно, адоб вообще не о том чем макромедия, они думали что тут как с фотошопом, прибрал тул раз в 10 лет и порядок. Оказалось что все иначе.
> - придумали для программистов Дотнет, дабы писать интерактивное для клиента — программисты
> крутили носом и кричали «фу».Потому что нативные программы - работают быстрее. Потому что не совместимо ни с чем кроме винды. Потому что после установки или апдейта насилует машину полдня. Потому что под вебсервера на этом кодить - адилище. Потому что MS сделал штуки четыре рантаймов. Не особо совместимых между собой, не считая сервиспаков выпускаемых как динамит в толпу. Задвинув в этом даже питонистов.
А так как круто энтерпрайзным програмерам, когда они только отвалились спать после того как наконец со всеми мучениями накодили через полгода простую вебморду - так ведь нет счастья: утром MS выпускает новый дотнет или сервиспак, у клиентуры все сдохло.
MS сделал дотнет ... неизвестно для кого. Маркетинг решил что это круто. Для чего именно круто - они не уточнили, поэтому шпарили на своей волне, пытаясь насильно впихнуть это всем. Непонятно зачем.
> А жлобоскрипт им — сплошное ми-ми-ми! Что ж это за программисты такие — раз
> им столь мил худший ЯП всех времён и народов?Как раз жлобоскрипт - голимая штука. Зато есть везде. А еще довольно быстрый. И таки не требует супер-рантайм как у дотнета/явы и лучше интегрируется с html в отличие от флеш. А wasm нужен как раз затем чтобы тяжеловесные штуки на таком УГ как JS все же не делать.
> веб-браузер — это программа для просмотра веб-страничек, а не среда выполнения приложений.
Этот мир решил иначе... хотя возможно вы предпочитаете на выбор два варианта, приложения "для андроид" и "для эпл"? Нет, винда там уже не фигурирует как вариант :)
Сдается мне Вы немного не разбираетесь в ньюансах:
java - практически лишена адекватных инструментов для интерактивности с клиентом, да и те менялись несколько раз за время жизни кофемашины. Удаленного GUI через браузер - нет.flash/silverlight - тут скорее наоборотб хоть мульфильм ваяй, хоть инди игру, да и куча их было, но Стив Джобс увидел, что флеш не хорошо, а магизин приложений - это самое оно.
dotNet - вещь настолько кросплатформенная, что гуй для мобильного и для обычного Дотнета были абсолютно разные, что говорить про Веб.
javascript - единственное, что работает в браузере с пользователем, помимо html и css. Так сказать за неимением лучшего.
> Я уж не хочу в стопицотый раз заводить разговор о том, что веб-браузер — это программа для просмотра веб-страничек, а не среда выполнения приложений.
Нужен.
yashints.dev/blog/2019/12/17/tfjs-wasm
https://habr.com/ru/post/281879/
> Еще раз: JavaScript на клиенте не лагает. Лагает медленный DOM (точнее манипуляции с DOM). Не важно чем вы будете менять DOM — джава-скриптом или ассемблером. DOM все равно будет притормаживать. Именно из-за тормознутости DOM, JavaScript стал считаться медленным языком. Это историческая несправедливость и от нее давно пора избавиться.
> В этой связи у многих существуют неоправданные ожидания от прихода WebAssembly. Дескать, придет WebAssembly порядок наведет и мы наконец-то откажемся от «тормознутого» JS. Во-первых, даже после прихода WebAssembly работа с DOM останется за JavaScript. Да, какие-нибудь фреймворки (типа AngularJS) получат возможность перенести тяжелую логику на C/C++, но суммарный прирост от этого будет минимальным. Во-вторых, когда WebAssembly сможет напрямую манипулировать DOM'ом, минуя JS, прироста по скорости не будет, т.к. тормозит DOM, а не JS.
Ну то есть как писали на PHP сайты, так можно и продолжать писать, так каквсе эти новомодные штуки вроде Server Push никакого влияния существенно нет. А бороться за копейки будут единицы сайтов. ОДним словом побаловались и можно продолжать использовать HTTP/1
при чем тут php?
Внятно написанный сайт на php таки может быть и быстрым, и красивым, и модным-молодежным.
Но еси вы считаете, что h2 дает копейки, то это точно не про вас.
Ну посмотрите уже на графики, конкретно — на самую типовую ситуацию, 90% cached. h2 реально копейки даёт.
Копейки... замедления в ряде случаев.
Интересно, у кого это 90% cache hit типовой? У домашней страницы Васи Пупкина? Так ее время загрузки никого и не волнует.
На самом деле сильно зависит от приложения. Только тестить...Я уже как-то писал что как минимум одно приложение из мне доступных под HTTP1 + Bundling грузится на ~5% процентов быстрее чем HTTP2 + Bundling (хотя говорят что для HTTP2 он необзателен, но это не совсем так).
Холодный старт... без кеша.
Вероятно, вы не совсем корректно представляете, чем принципиально "все эти новомодные штуки" отличаются от HTTP/1.1
Доклад об ASGI: https://www.youtube.com/watch?v=HGcv9WAKkPM
Для HTTP/1 было разработано семейство стандартов FastCGI, WSGI и т.д. Общая тенденция: запрос -- ответ. Эти стандарты не позволяют задействовать "все эти новомодные штуки".
Для решения проблемы обязательной синхронности HTTP был реализован ASGI, и подробнее о нём в докладеА "все эти новомодные штуки" в первую очередь должны поддерживаться приложением. FastCGI/WSGI приложение, если ему подсунуть server push, попросту не задействует его.
Ровно как добавление в инфраструктуру redis при приведёт к кэшированию в нём данных
Смешались в кучу - люди, кони... Что за набор слов вы написали? причем тут вообще протокол взаимодействия веб-сервера и питонячьего бекенд-приложения если речь идёт об отдаче фронтенда и контента клиенту?. Мда, дилетанты никогда не упустят момента показать свою глупость публике.
> Мда, дилетанты никогда не упустят момента показать свою глупость публике.Сколько пафоса. Упырьте мел, сударь, и найдите комментарий, на который я дал ответ
PUSH вообще-то вешается для статики на уровне веб-сервера, все остальное от лукавого
> PUSH вообще-то вешается для статики на уровне веб-сервера, все остальное от лукавогоПожалуйста, найдите сообщение, на которое я дал ответ
Со статикой не так всё просто. никто руками прописывать её в конфиг не будет. push должна поддерживать нода (нужна для сборки бандла)
Server Push само по себе ересь.
Альтернативы (заваливание сервера запросами проверки обновлений) еще хуже: реже проверка - хуже юзер экспириенс, чаще проверка - выше нагрузка.Да и, черт возьми, логчно, что если браузер должен реагировать на события на сервере, то сервер должен отправлять нотификации браузеру.
Это не тот пуш.> HTTP/2 Server Push allows an HTTP/2-compliant server to send resources to a HTTP/2-compliant client before the client requests them. It is, for the most part, a performance technique that can be helpful in loading resources preemptively.
> HTTP/2 Server Push is not a notification mechanism from server to client. Instead, pushed resources are used by the client when it may have otherwise produced a request to get the resource anyway; this can result in wasted bandwidth if said pushed resources go unused by the client, however.
Т.е. клиент не может сказать - не надо мне твоего рекламного баннера на 100 Мб, ведь сервер скажет: всё равно лови, а то знаю я вас - сначала отказываются, а потом GET'ы шлют!Т.е. клиент не может сказать - не надо мне твоего логотипа на 100 Мб, он у меня уже закеширован! А сервер скажет: всё равно лови, сам же потом спасибо скажешь!
Именно поэтому используется HTTP/2 cache-aware server push aka CASPer.
Так что нет, не так.
Хе... напомнило, как в "Острове сокровищ" Киевнаучфильма Джим сунул пирату в руки ракету, а тот послушно её взял.
Вы спутали с вебсокетами
Полностью поддерживаю ибо есть Apple Push Notification Service.
Я его использую и плюсы вижу в следующем:1.
Я собрал со всего сайта все используемые скрипты и стили в два соответствующих файла all-script.js и all-css.css (по 80 kb в сжатом виде получилось) и отдаю их именно http/2 server push-ем
2.
Да при первом посещении сайта грузится больше данных чем используется на странице. Но при дальнейшей навигации по сайту когда у посетителя в браузере всё закэшировалось - всё летает. ИМХО с точки зрения юзабилити это правильно.
Грузить 80 кил не прикольно. Особенно если это какой-нибудь поезд и там GPRS лагучий. И вклин взаимодействия до начала загрузки, особенно на медленном соединении - не есть правильно.
Да, не прикольно (тем более что не 80 а два файла по 80 kb) - но повторюсь ИМХО лучше один раз при первой загрузке перетерпеть а потом всё летать будет.Ну а то что до начала загрузки пушатся файлы так в этом же и есть ускоряющая фича.
Энное количество юзеров просто забодается и уйдет. И никогда уже не вернется, запомнив что этот сайт - хреновый.А так автор w3schools показал как делать непозорную верстку одним CSS'ом. Весьма минимальным по сравнению с например twitter bootstrap. Вот это я понимаю - профи веба показал как надо было.
Как страшно жить ! (С) :)Ну вот не вижу большое кол-во отказов на своём сайте.
Давайте не будем теоретизировать а прислушаемся к практику (то есть ко мне :) ).
И каков выигрыш по сравнению с загрузкой двух файлов из index страницы? Особенно при втором посещении?
Для двух файлов овчинка выделки не стоит. Правильно это так: загрузить разом весь фейсбук при обращении к его логотипу на страничке авторизации - все одно пользователь рано или поздно перейдет. :)
> Для двух файлов овчинка выделки не стоит.Вы точно внимательно прочитали что это за два файла ?
> Я собрал со всего сайта все используемые скрипты и стили в два
> соответствующих файлаПо поводу "результатов" - тяжело выделить "ускорение" именно от пуша - ибо внедрено столько разных фич и сайт настолько быстр :)
>Вы точно внимательно прочитали что это за два файла ?Какая разница - один запрос или три (от нуля до трех включая 304)? Сколько миллисекунд?
Сервер пуш, это когда можно не объединять файлы, а сразу их отправить не склеивая. Так сказать для ленивых. Серверу да проще - меньше нагрузки, клиенту без разницы.
> Сколько миллисекунд?https://webpagetest.org/result/200110_7P_6bbe1626e5c0fbd5e83...
из Амстердама до Москвы
>Когда важнее упрощение логики и простой API, имеет смысл использовать раздельную обработку ресурсов.Какая вообще разница, простая логика или сложная, если
0. сложная даёт какую-нибудь выгоду
1. нет уязвимостей и бэкдоров в самом протоколе
2. нет уязвимостей и бэкдоров в реализации
3. реализация протокола вынесена в shared library, имеет нормальное API, пригодное для использования с нормальной документацией (а не г**** вроде API bouncycastle), используется всеми приложениями (сторонние каналы передают привет)?
Там не про 1 vs 2, а про compound. Одной библиотекой это не решить.Ну а HTTP/2 сам по себе выгоды не даёт, как видно из графиков.
Вы на какие графики смотрите? h1, no cache у вас за поле зрения выпадает?
Далеко не всегда получится сделать то, что тут названо compaund. Для веба это изначально вообще не камильфо.
Я помню времена, когда страница открывалась, а потом медленно подгружались картинки, насколько скорости модема хватало. НО! Страница была читабильна и по мере добавления картинок просто украшалась.
Теперь пытаются делать то же самое, но не столько из соображений ограниченой скорости канала, сколько из соображений скорости отрисовки тормозящих яваскриптов. В реальности это получается сделать крайне редко.
> Вы на какие графики смотрите? h1, no cache у вас за поле зрения выпадает?Не хочу вас огорчать, но практически все современные браузеры поддерживают кэширование.
Если посмотреть работу большинства топовых сайтов, они уже давно все на HTTP/2. Кэширование это прекрасно, конечно, но тогда и сайт получается ни к чему: пользователь все уже закэшировал, зачем ему вообще на сайт заходить?
Разница в том что чем сложнее реализация тем больше в ней будет ошибок и уязвимостей.
О плохой работе http2 говорят только админы локалхостов.
Уедьте за границы спб или мск, где интернет в лучшем случае 3g, и ощутите скорость загрузки.
Протестить можно например здесь - https://http2.akamai.com/demo
Т.е. ты хотел написать наоборот: чем хуже инет, тем хуже работает HTTP/2 по сравнению с HTTP/1
Чем кривее руки, тем меньше h2 тебе сможет помочь.
Если на странице одна миниатюрка версит мегабайт, то стоит ли жаловаться на узкий канал?
А вот когда накладные расходы на транспортировку сравнимы с размером всего контента страницы, тогда h2 будет полезен независимо от ширины канала.
> А вот когда накладные расходы на транспортировку сравнимы с размером всего контента страницы, тогда h2 будет полезен независимо от ширины канала.Что-то в приведённых исследованиях полезность h2 не доказана.
полезность НАМ - вполне доказана.
А проблемы поуехавших куда-то там от какой-то там Масквы - но, видимо, так и не доехавших каких-то 800 километров до финской границы нас совершенно не колышут, так как денег с них - хрен да нихрена.Проблемы ваших личных хостингов,это, понятно, дело совсем другое - мы их вам создадим еще, гарантируем.
Побольше жлобоскрипта пихай в страничку — ещё и не так тормозить будет.
"Авторы исследования также отметили, что оптимизация серверной части оказывает более существенное влияние на производительность, чем оптимизация выполняемого в браузере клиентского кода."Дык, а смысл кровати двигать? Нужно куртизанок менять.
А так можно было?
Можно. Но не на кого менять.
Короче, склихасофский. Кто победил?
>...Кто победил?Маркетолухи.
Победила дружба!
Головной мозг прямым рукам не враг. они не воюют.
Смотри, думаай и делай.
ie 6.0
Эти товарищи при тестировании забыли обращать внимание на то, сколько пожирает ресурсов каждй браузер под такой нагрузкой, и насколько отзывчивым он оказывается, мне, как мользователю это гораздо важнее.
/*как пользователю
Они исследовали конкретный вопрос. Хотите исследовать другой вопрос — никто не запрещает, но и указывать другим, что им ещё надо для вас бесплатно сделать, как-то не очень красиво.
Красота - понятие субъективное. Кому-то красиво одно, кому-то другое, вот с моей стороны, выглядит не очень красивым, когда кто-то начинает влезать со своим авторитетным мнением по поводу красоты того или иного, но я, будучи человеком скромным и тактичным, всегда оставляю свои понятия красоты при себе и никогоне поучаю в таком аспекте жизненного восприятия, но это я, остальные вольны делать что угодно.
>указывать другим, что им ещё надо для вас бесплатно сделатьЗанятно, по каким причинам производятся подобные выводы?!...
Меня всегда поражала вот эта вот уверенность в данном аспекте.
> Занятно, по каким причинам производятся подобные выводы?!...Человек потребляет бесплатное, и возмущается тем, что перламутровые пуговицы не того оттенка. Если мы зададим вопрос "зачем он публично возмущается?", то мы увидим за этим мотив "указать другим, что им делать". Я не вижу никакого другого здравого мотива, который мог бы стоять за таким поведением. Можно предположить, что человек психически нездоров, и может быть его поведение -- это его способ завлекать инопланетян в волчью яму, но это маловероятно.
Ну, свиньи всегда будут жрать бесплатное говно. И некоторым из них это даже будет нравиться.
Бывает, что найдутся небезразличные люди, которые скажут "но если ваши бургеры делать не из говна, то они будут лучше!". На что свиньи завизжат "нашёлся выскочка! чеговозмущаешься! спервадобейся! намытакхорошо! сделайлучшыамыпосмотрим! отгоршкадвавершка! неуказывай!"
Ну и сидят в говне. А потом их софт людям инсталлируют.
(перефразируя народных героев)
Сейчас идёт речь не о потреблении софта, а о потреблении результатов исследования. Автор исследования исследовал то, что ему интересно. Соответственно для этого он выстроил методику сбора данных и обработки их. Если тебе интересно было бы сделать какие-то ещё выводы -- попробуй связаться с автором, может он тебе выдаст сырые данные, может быть они собраны были таким образом, что они позволяют посчитать то, что тебе интересно. Либо у тебя есть вариант провести интересное тебе исследование самостоятельно.Фишка в том, что про абсолютно любое исследование можно сказать, то, что сказал аноним выше. К измерению высоты Эвереста можно предъявить претензию, что оно не меряет глубину Марианской впадины.
> Ну, свиньи всегда будут жрать бесплатное говно.
О да, "и тут выхожу я весь в белом".
Погорячился, конечно, малость, но приведённая метафора пригодна практически для любой предметной области. К счастью, людям свойственно не только деградировать, стагнировать, но и учиться и совершенствоваться. Соответственно, случается, что и продукты их тоже улучшаются. )> О да, "и тут выхожу я весь в белом".
Да я-то вообще в красном :D
>> Другим выводом является то, что браузерный кэш при использовании HTTP/2 не оказывает значительного влияния на производительность обработки запросов (полное выполнение 501 запроса оказалось медленнее выполнения 51 запроса при 90% наполнении кэша всего в 1.2 раза в Firefox и 2.3 раза в Chrome).Как задолбали эти тесты в песочнице. Когда уже они выйдут в реальный мир, где далеко не у всех 1 Гб инет?
Я с клаудфлейром после перехода на http/2 поимел эдак двухкратное ускорение и уменьшение примерно трафика в полтора раза. Текст-онли, правда, и данные всегда новые (миллионы запросов), в одной сессии. Я бы списал на разницу в загруженности, но эффект выглядел 100% воспроизводимым.
Если сопоставлять с тем, что приведено в новости, вывод напрашивается очевидный — CF притормаживает HTTP/1 примерно в два раза.
Возможно, у них просто серверные мощности под h2 изолированы от мощностей h1 и меньше нагружены.
> CF притормаживает HTTP/1 примерно в два раза.Если действительно смотреть на данные, то напрашивается другой вывод: CF притормаживает HTTP/2, причём на порядок.
Миллионы запросов, данные всегда новые, значит надо брать второй график и сравнивать ситуации no cache.
угу, слов про "уменьшение траффика" мы ж не видим, и видеть не хотим(тем более - думать, а с чего ж это оно). Молодец, раб, пойдешь на холодец не в первых, а во вторых рядах!
> про "уменьшение траффика" мы ж не видимНе знаю как вы, а я вижу. Но в графиках выше про объёмы трафика не сказано, понятно, что ускорение скорее всего коррелирует с тем, что меньше байт надо гонять по сети, но это качественное соображение. Но первая часть фразы, на которую я среагировал, содержала в себе слова про ускорение, а вот о времени в графиках нарисовано.
Короче, склифосовский, я скажу тебе вот что: высокий социальный статус гарантированно приводит к потере моральных ориентиров и снижению интеллектуальных способностей. Про потерю ориентиров даже замеряли в экспериментах. Снижение интеллекта не замеряли (или я не слышал об этом), но его можно легко наблюдать на глаз: достаточно взять любую выборку начальников и посмотреть на них. 9 из 10 окажутся дебилами.
Это я к тому, что тебе лучше уходить из класса рабовладельцев и присоединяться к нашему тёплому кружку рабов -- может интеллект и восстановится за пару лет.
С точки зрения эволюции, экстремально высокий интеллект не является решающим. Чуть умнее гиббона - и ладно. А кто у нас судья, как не эволюция? Так что резона наращивать его не вижу
> А кто у нас судья, как не эволюция?Какое тебе дело до эволюции? Ты хочешь сказать, что твоя система ценностей построена поверх идеи следования законам эволюции? То есть, ты всеми силами распространяешь свои гены? Сколько детей уже удалось настругать? Сотня-то набралась?
ГДЕ НОВОСТИ ПРО ХАРД?
Эта ботва не интересна. Где базар про нанометры?
Это ты ващще о чём?
gRPC значительно проседает на http2
Вывод: Кэш браузера не эффективен.Ну на конец то тесты показали то, что пользователь видит своими глазами...
Во времена pure http это было видно по логам (сниффера/прокси), что браузер при обновлении страницы перезапрашивает (ждет и получает) картинки, даже если они лежат в его кэше на локальном диске больше 1 секунды.
Может быть, да очень даже может быть, нет ну очень даже может быть, что, а то, что макаки они такие макаки, и на свою .раную картинку выставляют время запланированного устаревания в 0,5 секунды. И что Вы хотите, что бы браузер не перекачивал через секунду?!?!?!? Да Вы что!? Тогда ведь макаки начнут брызгать слюной, что браузер их не слушается :( Ай, ай, ай, всех браузеров в угол ;)
Не имеет значения.
Даже если заголовки (Age, Cache-Control, Date, Pragma, Max-Age, etc) выставлены корректно браузеры перезакачивают (часть) контент.Проблема "седалища вместо головы" у разработчиков браузеров известная настолько хорошо, что пришлось придумывать даже особый ответ со стороны сервера - "http code 304".
Заслуги ваших родичей, макак, не велики. Вы пришли позже, уже на все готовое.
> заголовки (Age, Cache-Control, Date, Pragma, Max-Age, etc) выставлены корректносмешал в кучу все, о чем краем уха слышал, и чего обычно грязными руками вообще не следует трогать, про единственный заголовок, который на самом деле следовало - не, не слышал (конечно, сейчас суматошно погуглит, и будет врать что имел его в виду) - но виноваты -
> браузеры перезакачивают (часть) контент.
> Проблема "седалища вместо головы" утебя дружище, у тебя. Нет, и код 304 тоже ты не понимаешь как работает и зачем нужен (был, до ненужноhttp2).
У меня вот браузер перезапрашивает только то, что на самом деле следует. Кэширование - работает. Я, в отличие от тебя, это не по логам mitm изучаю. Надо заметить, что что именно следует, а что нет - вовсе не всегда очевидно людям вроде тебя.
> Может быть, да очень даже может быть, нет ну очень даже может быть, что, а то,
> что макаки они такие макаки, и на свою .раную картинку выставляют время
> запланированного устаревания в 0,5 секунды.к сожалению - нет, они вообще никакое не ставят - потому что ниасилили, как и ваш крикливый оппонент, разобраться, как это работает, и что, на самом деле, следует выставлять и почему.
Зато вот про ?v=1234567889009098765433 - они обязательно прочитали, в журнале мерзилка, для альтернативно-одаренных разработчиков, не сомневайтесь.Да, разработчики браузеров в 80е тоже постарались максимально запутать простые вещи, и сейчас уже ничего не поменять - все сломается, но разобраться, как на самом деле работает, а не как кому-то кажется правильным - несложно.
В http2 все сложнее, ну так его не для людей делали, его владельцы интернета для себя, любимых, придумали.
"Авторы исследования также отметили, что оптимизация серверной части оказывает более существенное влияние на производительность, чем оптимизация выполняемого в браузере клиентского кода. "
Что за бред ???
Код генерируется относительно быстро. Тот же вордпресс генериует страницы не так долго. за 100-200мс как правило он управляется, из тяжёлого разве что фукомерц, но php 7ой версии стал генерировать как минимум в 1,5-2 раза шустрее, а во вторых ооочень часто статическое кеширование возможно и подключается в пару кликов.А вот вычистить код от кучу js\css кода и сделать так чтобы нужный код грузился постепенно, задача как правило требует ручной работы и тестирования-тестирования-тестирования.
Ну окей отдал я 16кб сжатого html в 1 окно, но если там будет грузится 200-500кб js (в расжатом виде 1-2мб )
на многих коммерческих есть два самых тормозных скрипта (из топ популярных) это метрика с включенным по дефолту вебвизором (если его отключить то метрика чуть легче становится) и живочат.О джейквери и её дополнениях я уже молчу.
Ну и конечно шрифты куда же без них доходит до бреда используется 3-5 глифа, а грузятся 20 шрифтов.
Опять же порой накодят так, что потом если обновить js-библиотеки то все ломается. В итоге используется старые библиотеки. (работает же)
А в России еще любят говорить "Индуский код", да большинство сайтов рунета, полное днище говна!
У вас странные представления о "не так долго". Не так долго это в пределах 10мс на коннект (в интернете) и в районе 1 мс на генерацию контента, причём основное время ещё уйдёт на запросы к бд. Каждый раз, когда я смотрю на все эти сайты где ответ приходит через тысячи миллисекунд (и таких ресурсов сотни на каждой странице), мне делается больно.
М-да. С кэшами у браузеров сейчас реально порой неладное творится. Выставляешь - хранить вечно - всё равно что-нибудь да загрузит. Но это ещё полбеды! Каждый идущий к успеху бизнес-стартапер, не отставая от Goolag и Necrosoft, пишет в страничке include ajax.js и весь контент летит неизвестно какими некэшируемыми путями, а потом выясняется что часть картинок - это вообще image/data=UUE прямо в тексте HTM... простите, DOM. Вообще порыться бы - кто же ввёл возможность внедрять картинки в HTML?.. это же золотое дно...
Ну короче если большинство ресурсов закешированы браузером, H2 не нужен.
> Ну короче если большинство ресурсов закешированы браузером, H2 не нужен.Да и сервер ни к чему. Это "программа на электроне" нынче называется.