Компания Google представила (http://blog.chromium.org/2009/11/2x-faster-web.html) протокол SPDY (произносится "спиди", "Speedy"), реализуемый на уровне приложений и являющийся частью программы (http://code.google.com/speed) по разработке решений по увеличению скорости работы web. В частности, в SPDY осуществлена попытка решения проблемы HTTP с задержкой соединения между клиентом и сервером. Исходные тексты (http://src.chromium.org/viewvc/chrome/trunk/src/net/flip/) с реализацией SPDY распространяются под BSD-подобной лицензией.
Среди характеристик:
- Сжатие заголовков, что, по словам разработчиков, на ~88% уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа. На медленном DSL-линке, в частности, сжатие заголовка запроса привело к значительной прибавке скорости при загрузке страницы для некоторых сайтов (например тех, которые породили значительное количество запросов ресурсов).
- SPDY добавляет сеансовый уровень поверх SSL, что даёт возможность создава...URL: http://blog.chromium.org/2009/11/2x-faster-web.html
Новость: http://www.opennet.me/opennews/art.shtml?num=24247
Надстройка обычно = костыль, но тут, судя по анонсу, как-то язык не поворачивается так назвать. Маркетинг :)
ИМО хорошее начинание.
Не фига не хорошее, какой-то костыль, решающий частную проблему. Пусть сделают свою куйню в виде прокси, чтобы локально на компьютер можно было поставить и на сервер. На компьютере пользователя HTTP будет преобразовываться в этот SPDY, отправляться через тырнет на SPDY-сервер, который будет конвертировать его обратно в HTTP и обслуживать. Получится по сути свободная реализация модных у вантузятников веб-ускорителей.
прокси-сервер? Не проблема. Особенно при открытом протоколе. Вот модуль для веб-сервера уже посложнее задачка.
Глупость какая!!!
почему просто не стандартизировать эти улучшения как HTTP 2.0 и не мучится с настройками если это стандарт да еще и открытый всерано или поздно поддержат.
Аха ... вместо того, что-бы излечить саму болезнь, будем как обычно заплатки делать. Новый протокол это конечно замечательно, особенно со сжатыми заголовками.
Но я так понимаю, всего-лишь вводится новый уровень инкапсуляции HTTP протокола.Но почему:
а) не изменить стримовый характер самого HTTP на пакетный ?
б) не заменить HTML на EBML к примеру ?Маркап останется, доступ к данным изменится с последовательного на параллельный и скорость обработки увеличится.
Ещё один момент. Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться. Если сейчас не закачиваются лишь игнорируемые внешние линки, то с подобным изменением можно будет блокировать ненужный контент сервера к которому подсоединён. Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно.
А HTTP это болезнь. Когда-то давным давно, когда Интернет был маленький, и Мозаик был чудом, HTTP был идеален для своих задач. Все придерживались простого правила, использовать гифы и простенький дизайн страниц. И даже на dialup-е HTTP был вполне приемленм. Через 2 года Интернет настолько вырос, и такое кол-во манагеров разнюхало о его существовании, что появились Веб-Дизайнеры, ну и они конечно стали впихивать в простые и ясные странички, "красоту неимоверную". Чтоб манагерам было хорошо... Но интернету тут-же поплохело, но прошло 2 года и пришёла широкополоска, многим сразу полегчало (в основном в ЮСА, Западной Европпе, Средней Азии и Юговосточно Азии). Еще через 5 лет DSL был почти везде. И кое-где даже DSL2.
Сейчас у меня 16/1 Мбит канал но я подумываю о переходе на 32/2 Мбит так как цена та-же а скорость выше. Флеш я не люблю, но пользуюсь. От ютуба не убежишь. Торрент рулит и вообще есть куда девать пропускную способность.
ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ...
HTML стар. Пора менять.
> доступ к данным изменится с последовательного на параллельныйиз-за последовательного доступа обрезка рекламы и счётчиков даёт заметную прибавку в скорости отображения страниц -- броузерам слишком часто приходится подолгу ждать пока загрузятся все баннеры.
Как только отключу дома проксю -- впечатление что инет начинает жутко тормозить.
Это не из за последовательного доступа, а из за закачки фигни со всех сторон. Обрезка происходит после закачки именно из за того что протокол последовательный. А твой случай это имменно подтверждает :) Прокси заранее режет все-то что тебе ненужно, и т.д.
Цитатко из меня любимого:(1)
>Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться.(2)
>Если сейчас не закачиваются лишь игнорируемые внешние линки, то с подобным изменением можно будет блокировать ненужный контент сервера к которому подсоединён.(3)
>Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно.
>Все мы пользуемся NoScript и AdBlock, при параллельном доступе вместо последовательного (стримового), ненужные данные не будут закачиваться.Вот на этой самой странице, отнюдь не перегруженной JavaScript'ом тупое удаление этого JavaScript'а дало уменьшение размера страницы на ~12%. А на каком-нибудь mail.ru эта "оптимизация" даст более 40%. ;)
> а именно не загружать этот контент.Как ты себе представляешь игнорировать то, чего ещё не знаешь?
Можно указать то, чего не хочешь видеть, но это не значит,
что на другой стороне примут во внимание пожелания населения.
>Причём не просто блокировать при рендеринге, а именно не загружать этот контент. Гибкость филтеринга контента возрастает неимоверно.Вот на этом-то внедрение нового протокола и загнётся. Нафиг гуглам и прочим, зарабатывающим на рекламе, такая фича =)
в опере так и работает игнор список для блокирования контента, ничего лишнего не грузится, выкиньте ваш слоуфокс
Их персональный слоуфокс они не отдадут. Он им дорог. У остальных AdBlock Plus тоже режет по-человечески.
>Новый протокол это конечно замечательно, особенно со сжатыми заголовками.были какие-то сервисы в том тысячелетии, зиповали веп на лету, вроде как "ускоряли" браузинг, ничто не ново. Вот на наге человек предложил в "панели мейл.ру" и другие порнографические надстройки браузера добавить что-то вроде торрент-клиента, вот это действительно даст эффект в скорости доступа, но она ни к чему, на мой взгляд, проблема уже давно на стороне клиента, браузеры тормозят.
>ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то
>у меня все быстрее и быстрее, и HTML парсинг шустрый, и
>JS движки все круче и быстрееПроблема чаще не в отдаче серверов, а в насыщенности яваскриптом/итп. Я часто использую для браузинга 'links -g', когда нужно просто "посмотреть/почитать", без дописок и тп. Странички часто отображаются коряво - но моментально, часто буквально в момент ввода урл, нажатия 'enter', дома сижу на корбиновской 10тке метров/сек, на работе хз какая скорость. Тормозит яваскрипт и тп, вовсе не канал. Если бы отдача сервера была причиной задержек - не было бы разницы между браузингом в links -g и файрфоксе.
> насыщенности яваскриптом/итпТак ведь не парсинг скрипта тормозит и скрипты небольшие. Все задержки приходятся на резолвинг имён и подключение к 3-м серверам. А тормоза из за того, что все действия происходят последовательно. Считал тег отпарсил,[ есть реф ] -> пошел по рефу, вытянул, .... тегу конец -> РЕНДЕРИНГ. Весь процесс синхронный и последовательный. Спасает только многопоточность которая рефы в фоне качает.Но рендерить ведь не начнёшь, до тех пор пока не получишь контент.
Открой для себя оперу :)
Ставим фаербаг в идём на вкладку net и смотрим как и что грузится и чего мы собственно ждём.
Удивитесь и паралельности запросов и ожидания загрузки ява скриптов. Можно у гугла по теме оптимизации сайта и особенностей работы с ним браузеров почитать.
Эта штука не для Web, а для программ использующих HTTP в качестве транспортного протокола. Так как сжатие заголовков напрочь убивает возможность согласования параметров. Пользоваться такой штукой можно только если заранее известно что и клиент и сервер ее поддерживают.
> Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ...
> HTML стар. Пора менять.как-то не вяжется :)
> ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ...Наверно не последнюю роль в этом играет то, что кол-во клиентов и их запросы всё растут.
> HTML стар. Пора менять.
Насчёт HTML не уверен, а вот HTTP И FTP это уж скорее таки да.
>> ОДНАКО !!!!! Веб сайты грузятся не быстрее а медленнее. И компьютеры то у меня все быстрее и быстрее, и HTML парсинг шустрый, и JS движки все круче и быстрее, нo иногда очень задалбывает загруженость самих серверов и их отказы от обслуживания. Они медленно отдают тебе твой контент, постепенно и не спеша. Побайтово ...не в том проблема что медленно отдают, а в том, что хозяева серверов вешают всё большую функциональность. Одна страничка обвешивается модулями как ёлка, повесить модуль сейчас легко, поэтому о том что он кушает ресурсы никто и не думает.
В отличии от некоторых "альтернативных производителей ПО" навязывающих необходимость проапгрейдить железо дабы удовлетворить потребности прожорливых никомуненужностей, Гуглеры более адекватно оценивают возможности потребителей. Людям с толстым каналом этот прирост в общем-то до лампочки. А вот тем кто пользует "медленный DSL"(Dial-UP, а иногда и GPRS на старых трубках) это да. Так что зря вы это про "год".
Людям с толстым каналом тоже влом больше 3-х секунд ждать появления странички. Это психология. Всё что дольше 3-х сикунд длится - медленно и долго, и бесит. Частичное появление контента, до конца закачки, конечно спасает. Но регулярный перерендер из за появления запоздавших элементов - бесит.
>В отличии от некоторых "альтернативных производителей ПО" навязывающих необходимость проапгрейдить железо дабы
>удовлетворить потребности прожорливых никомуненужностей, Гуглеры более адекватно оценивают возможности потребителей. Людям
>с толстым каналом этот прирост в общем-то до лампочки. А вот
>тем кто пользует "медленный DSL"(Dial-UP, а иногда и GPRS на старых
>трубках) это да. Так что зря вы это про "год".Я сижу на EDGE на новой трубе, и то отказ от лишних соединений должен раз в 10 повысить скорость загрузки страничек.
>Гибкость филтеринга контента возрастает неимоверно.Никто из рулящих "крупняков" на такое не пойдёт, и в первую очередь Google.
> а) не изменить стримовый характер самого HTTP на пакетный ?В TCP/IP вообще не хватает надежного протокола для пересылки пакетов данных. Не UDP, а чтобы гарантированно доходили, но при этом не надо было ждать открытия/закрытия соединения.
У Oracle в разработке есть RDS (Reliable Datagram Socket, http://oss.oracle.com/projects/rds/), но это пока только дизайн, который ничем не поддерживается.
Вообще, я согласен, интернет-технологии очень сильно устарели, потому что сама суть интернета сильно изменилась. Однако людям свойственно цепляться за существующие решения мертвой хваткой, и добавлять один за другим новые костыли, одновременно треплясь про "новшества".
А чем их SCTP не устраивает? Стандарт, и вполне параллельный.
>А чем их SCTP не устраивает? Стандарт, и вполне параллельный.Это ж баблгам....транспортный уровень, вот!
А речь про прикладной.
SCTP тоже надо, но слишком много переписывать придётся.
Он висит как IPv6.
>Это ж баблгам....транспортный уровень, вот!
>А речь про прикладной.
>SCTP тоже надо, но слишком много переписывать придётся.
>Он висит как IPv6....
1 Физический уровень (англ. Physical layer)
2 Канальный уровень (англ. Data Link layer)
3 Сетевой уровень (англ. Network layer)
4 Транспортный уровень (англ. Transport layer)
5 Сеансовый уровень (англ. Session layer)
6 Представительский (Уровень представления) (англ. Presentation layer)
7 Прикладной (Приложений) уровень (англ. Application layer)HTTP протокол все-таки висит на транспортпом уровне.
Отображение страниц в браузере больше зависит от сеансового уровня и уровня представления
А то, что уровень приложений не может это адекватно обработать, зависит от кодеровИМХО
Марш курить доки по модели OSI. HTTP - прикладной, надо же такой бред сморозить.
Ради троллинга :-)
Демон http отвечает на запросы на....
Браузер отправляет запросы по...
Ясное дело, что текстовый протокол расходует больше трафика чем бинарный.
Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1.Но это всё жутко мешает распространению и популяризации.
Самый лучший по всем показателям язык программирования ассемблер не используется повсеместно именно по этому.Вердикт: не взлетит.
> Ясное дело, что текстовый протокол расходует больше трафика чем бинарный.компрессия сейчас практически везде включена, даже если 99% пользователей о ней не знают
> Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1
и это за вас полностью прозрачно браузер делает.
Вердикт: перед тем как писать не мешало бы ознакомиться с сабжем
>> Ясное дело, что текстовый протокол расходует больше трафика чем бинарный.
>компрессия сейчас практически везде включена, даже если 99% пользователей о ней не
>знают
>> Так же понятно, что человек иногда заходит на сайт узнать не вышел ли новый релиз, и его бы устроил ответ 0 или 1
>и это за вас полностью прозрачно браузер делает.
>Вердикт: перед тем как писать не мешало бы ознакомиться с сабжемContent-Encoding: gzip
Оно?
А разве оно хедеры и куки жмет?
>А разве оно хедеры и куки жмет?Естественно не жмёт, оттого-то гугль и зашевилился.
а 90% передачи - это контент. сжать его в 5-10 раз - эффективнее, чем париться про 20% импрува при сжатии заголовков
к сожалению, почему-то про эти простые вещи забывают/не знают кул-админы
к слову, хеадер зачастую умещается в типичный mtu, и, соответственно, может быть передан неделимо, что автоматически означает максимальную скорость передачи при большом количестве хопов.
стоит ли игра по разработке нового формата заголовков свеч, или таки лучше для начала в принудительном порядке отправлять детей в школу читать маны перед тем, как садиться что-то админить?
на месте гугля (если конечно его намерения действительно так благи) я бы просто организовал курсы повышения квалификации
если честно, новость интересная но написанна в стиле PR кампании - будто бы они 'ускоритель интернета' изобрели. Этот протокол должен быть действительно не плох для ajax, но только в строго конкретных случаях - на уровне приложения и организации сервера нужно делать тесты и смотреть будет ли выигрыш. В любом случае хорошо если браузеры его будут поддерживать.
> быть действительно не плох для ajax, но только в строго конкретных случаяхв израиле, например. где пакетики бьются на 512 на каком-то большом роутере :)
P.S. сочтут за разжигание :P
>а 90% передачи - это контент. сжать его в 5-10 раз -да не всегда контент. Часто 90% - это установление соединения. Крайний случай - спутниковые каналы, где скорости большие, а задержки ещё больше. 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть получен. В хороших сетях ответ быстрее приходит, но если померять - при пинге 250ms (USA-RUS) только на установку соединения уйдёт четверть секунды, а 100К данных при мегабитной линии придёт за то же время. 50/50 , это ещё если повезёт.
> 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть полученв этом случае приплюха тоже ничего не меняет. только усложняет. кто ж с ЖПРезом на output сидит сейчас?
>> 100 килобайт там пролетают за долю секунды, а ответ на запрос - за десятки секунд может быть получен
>
>в этом случае приплюха тоже ничего не меняет. только усложняет. кто ж
>с ЖПРезом на output сидит сейчас?при чём тут GPRS, спутниковые линии имеют особенность - огромные задержки (именно на спутниковой линии), большой MTU (например 16 килобайт) и большую скорость передачи данных при низкой надёжности. Там tcpip работает плохо, не то что http.
А на GPRS/EDGE пол-России сидит.
> большой MTU (например 16 килобайт)nu i? ...
vi sami ponimaete, chto eto avtomaticheski znachit, chto pripluha bessmislena? :)
>> большой MTU (например 16 килобайт)
>
>nu i? ...
>vi sami ponimaete, chto eto avtomaticheski znachit, chto pripluha bessmislena? :)мы сами понимаем, что если в этот пакет положить несколько запросов - вся страница придёт одтним куском. Гугль предлагает два решения в одной упаковке - уменьшение заголовка и группировку запросов. В разных случаях разный положительный эффект.
a, gruppirovku ya proglyadel. da. :)
vse ravno somnitelno, chto uzhe potrachennie (i v budushem potratyatsya) na razrabotku etoy figni cheloveko-chasi opravdayut effekt. krayniy sever u nas malozaselen.a reklama dlya google - niche! vse obsuzhdayut! ;)
>vse ravno somnitelno, chto uzhe potrachennie (i v budushem potratyatsya) na razrabotku
>etoy figni cheloveko-chasi opravdayut effekt. krayniy sever u nas malozaselen.Ну да, за кольцом жизни вообще нет.
ya dlekoooo za kolcom zhivu :)
> Сжатие заголовков, что, по словам разработчиков, на ~88%
> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа.Теперь эффективность DDoS атаки увеличится на 85% :)
>> Сжатие заголовков, что, по словам разработчиков, на ~88%
>> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа.
>
>Теперь эффективность DDoS атаки увеличится на 85% :)Помню во времена UUCP и FTN почты была такая штука как мэйл-бомба, когда фабриковался маленький почтовый пакетик, который распаковывался в огромный файл из одинаковых байтов и забиывл проц и винч на ноде. Защищались от такого проверкой и ограничением процента сжатия (ratio) пакета.
>>> Сжатие заголовков, что, по словам разработчиков, на ~88%
>>> уменьшает размер заголовков запроса, и на ~85% -- размер заголовков ответа.
>>
>>Теперь эффективность DDoS атаки увеличится на 85% :)
>
>Помню во времена UUCP и FTN почты была такая штука как мэйл-бомба,
>когда фабриковался маленький почтовый пакетик, который распаковывался в огромный файл из
>одинаковых байтов и забиывл проц и винч на ноде. Защищались от
>такого проверкой и ограничением процента сжатия (ratio) пакета.Ну а толку тогда от прироста скорости, вся идея Гугли в этом и состоит - сплющить, дабы в TCP влезло больше HTTP
>Теперь эффективность DDoS атаки увеличится на 85% :)Что, теперь полтора землекопа^W адслщика смогут завалить апача даже без ботов? За кадром слышно восторженное ликование хаксоров льющих вагоны сплюснутых хидеров которые сервант потом медленно и печально будет разгребать.
Всё это делается, скорее всего, для удешевления AJAX запросов, в которых на заголовок приходится большая доля трафика.
и правда, я как-то не подумал
Хотя, на сколлько я с AJAX сталкивался запросы вместе с хедерами редко больше чем полтора Kb требуют - в один пакет укладываются. Не понятно почему у них бинарные заголовки такой выигрыш дают, а вот использовать вместо отдельных TCP сессий собственный мультиплексор поверх одного TCP соединения действительно разумно. Опять же, видимо становится возможным в размер одного TCP пакета несколько параллельных мелких HTTP запросов укладывать, тогда и компрессия имеет смысл. Вроде смысл доходит помаленьку :)
Сейчас вообще среднестатистический "web 2.0" сайт требует сгрузить сотню-другую файлов. Естественно, заголовки создают лишнюю загрузку.Но это предложение - глупейшие костыли. Вместо узколобого сжатия заголовков, намного логичней было бы сделать протокол для настоящего асинхронного общения с веб сервером, чтобы оно шло через один поток и безо всяких извратов. А заголовки (нужные) посылать только один раз - при открытии потока.
>Сейчас вообще среднестатистический "web 2.0" сайт требует сгрузить сотню-другую файлов. Естественно, заголовки
>создают лишнюю загрузку.
>
>Но это предложение - глупейшие костыли. Вместо узколобого сжатия заголовков, намного логичней
>было бы сделать протокол для настоящего асинхронного общения с веб сервером,
>чтобы оно шло через один поток и безо всяких извратов. А
>заголовки (нужные) посылать только один раз - при открытии потока.это тоже неправильно. Наверно, все сталкивались с reget'оподобными программами, ускоряющими загрузку за счёт нескольких потоков. Несколько параллельных запросов могут выполниться быстрее, чем один последовательный. Это естественно на реальных линиях, не в локальной сети.
>это тоже неправильно. Наверно, все сталкивались с reget'оподобными программами, ускоряющими загрузку за счёт нескольких потоков. Несколько параллельных запросов могут выполниться быстрее, чем один последовательный. Это естественно на реальных линиях, не в локальной сети.Открытие потока занимает какое-то время. Отсылка заголовков занимает какое-то время. Загрузка еще одной копии сервера в память занимает какое-то время и жрет память. Когда файлы маленькие, многопоточность мешает. Не зря в HTTP 1.1 сделали Keep-Alive, который по одному потоку отправляет несколько страниц. Однако эта штука сделана для документов. А AJAX-запросы это, по сути, никакие не документы, а просто сообщения. Потому HTTP для их пересылки работает плохо. (Скажем, сильно не хватает возможности сделать запрос со стороны сервера. Естественно после того, как клиент открыл какую-то страницу. Приходится со стороны клиента постоянно что-то запрашивать.)
ИМХО, отличная идея использовать P2P для трансфера HTML страниц =)
>ИМХО, отличная идея использовать P2P для трансфера HTML страниц =)Дурацкая идея. Датентность P2P просто гигантская даже по сравнению с HTTP, а гуглу именно латентность не даёт покоя.
>ИМХО, отличная идея использовать P2P для трансфера HTML страниц =)конечно отличная, особенно в плане вконтактов: если Маша Вислодуденко уже посмотрела новый клип Сосо Павлиашвили, то Тане Ничай-Васько гораздо быстрее отдастся этот клип из локальной сетки провайдера (100м этернет) чем прямо с сервера вконтакта (512 кб/сек тариф "розовые бантики"), это очевидно
Трудно понимаемо такое стремление к пожатию. Ведь если заголовок размером меньше mtu большой прибавки к скорости пожатием не добиться. Другое дело что некоторые серваки и броузеры, пихают всякую чушь в заголовок. Но это вовсе не проблема протокола.
Можно в следующей спецификации договорится что, например, Content-Type и CT одно и тоже. Думаю два байта на имя поля более чем достаточно...
>Трудно понимаемо такое стремление к пожатию. Ведь если заголовок размером меньше mtu
>большой прибавки к скорости пожатием не добиться. Другое дело что некоторые
>серваки и броузеры, пихают всякую чушь в заголовок. Но это вовсе
>не проблема протокола.
>Можно в следующей спецификации договорится что, например, Content-Type и CT одно и
>тоже. Думаю два байта на имя поля более чем достаточно...там было такое ключевое слово "мультиплексор" - если браузеру нужно сделать одновременно несколько взаимно независимых коротких запросов, к примеру HEAD для разных ресурсов, и получить на них короткие ответы, то довольно накладно для каждого запроса открывать и закрывать новое tcp сеодинение (сколько это, 4 дополнительных пакета?), а потом гнать полупустые пакеты только по тому что для отдельного HEAD весь mtu не нужен. Короче, получается транспортный протокол аппликационного уровня.
А вообще, надоело. Сначала делают сайты, где требуется для открытия одной страницы грузить 100-200 файлов (Откройте Gmail со включенным Firebug), а потом учтиво предлагают под эти их сайты дополнять базовые протоколы - которые, по-хорошему, надо давно выкинуть к чертовой матери и заменить на что-то более адекватное.
> которые, по-хорошему, надо давно выкинуть к чертовой матери и заменить на что-то более адекватное.Это невозможно сделать. Legacy, legacy, legacy - это реальность.
> Сначала делают сайты, где требуется для открытия одной страницы грузить 100-200 файлов
> (Откройте Gmail со включенным Firebug)Gmail это не сайт а прежде всего веб программа, имеет принципиальное преймущество над "сайтами". За эти преймущества логично платить ресурсами.
Так что все правильно делают.