Экономия трафика и увеличение скорости загрузки страниц

Клиентский XSLT.

плевать, нет... не так... ПЛЕВАТЬ на объемы хттп трафика на фоне трафика медиа-контента.

и нагружать, как сервер, так и клиент, ога. реализуй серверную часть на пхп, а клиентскую на яваскрипте, вот и посмотрим, стоит ли того

Дык вроде есть же в стандарте html что-то такое. Можно сделать файл, содержащий любую часть страницы, и присобачивать его в любую другую страницу.

Фреймы/ифреймы. Жабаскрипты. В XML XInclude.

А что, в web2.0 кто-то грузит целиком страницы? И кеш принудительно отключают?

Нет, там что-то пожестче было. Можно было в фрагменты вставлять даже некорректный код, если при объединении с другим фрагментом он давал корректный.

Эмм, я не говорю ни про серверные, ни про клиентские скрипты. Этот функционал нужно встроить в веб-сервер и веб-браузер. Вот, сейчас твой браузер говорит серверу ЛОРа: «я умею читать гзипнутые страницы», и сервер начинает отдавать гзипнутые страницы. Так и в моём случае: браузер должен сказать: «я умею читать диффнутые страницы», а сервер должен понять и начать отдавать диффы вместо полных страниц.

ну ладно. тогда встройи сообщи, чо как

Ты изобрел AJAX.

У сервера должен быть весь лог изменений контента во времени, чтобы дифф создать? К этому подходу надо ещё подготовить принципиально новых php-кодеров.

Хранить состояние клиентов? Нунафиг.

Даже gzip бывает отключают, чтобы он процессор не грузил. А diff это вообще трудоёмкая операция. Это раз.

Серверу надо хранить предыдущую и текущую страницу для каждого клиента. Это огромные ненужные расходы памяти, это два. Опять же непонятно - сколько хранить. Когда ты нажмёшь ссылку, чтобы выдать тебе diff? Через минуту? Завтра? Никогда? Это два.

Сама по себе страница, если там не «Война и мир» (а если она, то, очевидно, что ваш способ не сработает), весит не так уж много по сравнению со скриптами, стилями, картинками и богомерзким флешем. Выигрыш вряд ли будет. Лучше предложи держать непрерывное соединение с сервером - на слабых соединениях огромное количество времени уходит именно на установку соединения, а не на загрузку самой страницы.

А с этим есть проблема что ли? Нет — не придумывайте решений к несуществующим проблемам.

Экономия трафика

неактуально

гм, для клиента может и не актуально (хотя можно вспомнить про мобильный интернет, который далеко не всегда безлимитный), а вот для сервера - вполне может быть.

лучший алгоритм сжатия картинок или видео, даст в разы больший результат.

а вот для сервера - вполне может быть.

хранить массу версий страниц и вычислять дифы? т.е. это такой сервер, где есть просто масса свободной памяти и процессорного времени, и при том очень узкий канал передачи?

нет, ты не понял, я вовсе не за идею ТС. И речь не о ширине канала, а о трафике. Он обычно ограничен. Делать дифы страниц - не правильно, а вот думать о экономии трафика - правильно. Можно, как минимум, jpegoptim-ом пройтись по фотографиям на сайте, ну и т.д.

типичный сайт: размер контента для которого ты сможешь применить дифф / размер всего контента = 0.000001. не смяши людей

В стандарте HTML? Ты с пхпшными инклюдами не путаешь?

Ты совсем не понял идею, дифы не вычислять надо, а готовить контент в форме дифов.

Каких диффов? У меня к серверу коннектится 100500 клиентов, у каждого персонализированная выборка. И чо дальше?

diff между последней отданной и той, которую хочет получить пользователь.

Последней отданной кому?

Ты не про SSI случайно? Так он *S*SI. Клиенту от этого ни холодно, ни жарко было.

Ты совсем не понял идею, дифы не вычислять надо, а готовить контент в форме дифов.

ну вот удалил модератор комментарий на прошлой странице, все комментарии съехали вверх + кто-то отредактировал оригинальный пост + написали новых комментариев, как ты будешь diff вычислять?

Если грамотно при генерации разбивать документ на строчки

Ты ещё будешь учить меня, как мне документ форматировать. jquery.compact.js никогда не видел?

Аффтар же сказал - построчно :)

Это не ко мне а к автору. Мне больше нравится идея разделения контента на шаблон и содержимое, по крайне мере не надо так сильно ломать сегодняшнюю концепцию.

Но если на то пошло, то в твоём примере всё легко разбивается на элементарные операции: удаление, добавление, редактирование элемента (комментария), дифф тут точно не сложно составить.

дифф тут точно не сложно составить.

на словах, на деле практически всегда будет быстрее, надежней и гораздо проще сделать diff для всей страницы

Неплохая идея для сжимающего прокси

Экономия!

На спичках.

У меня есть другая идея. Сделать так, чтобы для разных файлов (скриптов, картинок) можно было указывать кроме адреса откуда его взять еще и SHA256 хэш. Типа href=«sha256::6bac0b52ca0126f9d5209de2752a64e5de05ceaccd4a4e07a5768a1e1b613f88http://domain.ru/uri.js» В таком случае, если у пользователя уже есть в дисковом кеше файл с таким хешем, то его брать из кеша (неважно, как он туда попал). Таким образом, можно не париться, откуда отдавать JQuery (со своего сайта, CDN гугла или яндекса). Неприятность в том, что все эти варианты с изъяном (на мой сайт пользователь заходит в первый раз и у него может быть закачан нужный файл с яндекса или гугла, Яндекс по россии отдает быстрее всех, но не поддерживает https, гугл держит https, но отдает из штатов, т.е .медленнее чем с моей машины или яндекса) в результате приходится отдавать со своего сервера...

или лучше ввести новый аттрибут hashref=«sha256::6bac0b52ca0126f9d5209de2752a64e5de05ceaccd4a4e07a5768a1e1b613f88» href="http://domain.ru/uri.js"

а вот для сервера - вполне может быть.

доля такого трафика ничтожно мала по сравнению с трафиком, потраченным на отдачу мультимедиа контента

С выходом из криокамеры! MVC JavaScript фреймворки уже давно изобретены.

О том и талдычу - дифать текст не надо, но экономить трафик стоит, и в этом плане больше бы помог какой-нибудь более эффективный алгоритм сжатия графики или видео. Ну, или как минимум jpegoptim-ом пройтись по фоткам, и всего такого прочего по мелочи. Это даст в разы больший эффект чем то что предлагает ТС.

Нужно, чтобы сервер отдавал не целиком страницу, а diff между последней отданной и той, которую хочет получить пользователь

где хранить «последнее отданое» со стороны веб-сервера?

и да, мой омский товарищ, ты таки упоролся.
основные ресурсы к сожалению сьедаются на парсинг браузером всего отданого г@вна, и в том что сегодня каждая страничка - это тяжеленное нагромождение вебдванольных кнопок, ненужного ajax'а и еще более ненужного флеша - виноваты в первую очередь дизайнеры и кодеры этих самых страничек.

ненужного ajax'а и еще более ненужного флеша

это ты сам не нужен.

ETag

Насколько я понимаю, ETag позволяет не загружать заново ресурс, уже загруженный с указанного URL. Я же говорю про другое.

К примеру, на моем сайте используется JQuery (и еще не нескольких миллионах других сайтов) и наверняка в кеше пользователя он уже есть. Пользователь заходит ко мне на сайт в первый раз. Я могу отдать ему скрипт со своего сайта с CDN гугла или яндекса. Если у пользователя еще нет в кеше этого скрипта ни с одного из трех источников (т.е. он его не взял ни от меня, ни от гугла, ни с яндекса), то быстрее всего его грузить по http с яндекса, который не умеет https, по https от меня, а если он его уже загрузил, то больше всего шансов, что с гугла (но по скорости отдачи гугл самый медленный, потому что в штатах). Вопрос, какой URL для скрипта мне прописать в шаблоне заголовка страницы сайта? Или другой вопрос, как объяснить клиенту (браузеру), что он может использовать jquery нужной версии, неважно из какого источника он его взял (лишь бы содержимое совпадало)?

Скрипт большой, и часто работать должен начать еще до полной загрузки страницы. Время на его загрузку уйдет с пол секунды - запросто, т.е. есть экономия заметная. И Etag тут не поможет (он, насколько я понимаю, в nginx сам автоматически работает для статических страниц, а динамические почти всегда нужно пересоздавать при каждой отдаче).

Ajax же, подгружай контентые блоки как хочешь.

Кто и когда будет считать этот хеш?

и да, мой омский товарищ, ты таки упоролся.
основные ресурсы к сожалению сьедаются на парсинг браузером всего отданого г@вна, и в том что сегодня каждая страничка - это тяжеленное нагромождение вебдванольных кнопок, ненужного ajax'а и еще более ненужного флеша - виноваты в первую очередь дизайнеры и кодеры этих самых страничек.

Флеш - жутко тормозящий плагин, это ты прав. А ajax... хорошая нужная технология, которую очень легко можно неправильно использовать.

где хранить «последнее отданое» со стороны веб-сервера?

Вот и я о том же. подумал

А вот веб-страницу я гружу полностью (возможно, гзипнутую, но всё рано большую).

Посмотри хотя бы для примера что отдает страница http://forum.ixbt.com/topic.cgi?id=10:59658 и как в ней на 90% избавились от лишнего html

XSLT крутая штука! Но, как обычно, с реализацией в браузерах одно разочарование.

Первый то работает, если не считать IE за «работает» и disable-output-escaping в Firefox (по крайней мере раньше он не работал)…

AJAX only. Сервер должен отдавать более-менее статику, а подгрузка клиентских данных и их следствий - дело ajax`а.