Компания Facebook подвела итоги (https://code.facebook.com/posts/557147474482256) инициативы по увеличению эффективности локального кэширования на стороне web-браузеров, проведённой совместно с разработчиками Chrome и Firefox. Инженеры Facebook обратили внимание на то, что ощутимая часть запросов связана с получением сведений об актуальности прокэшированного статического контента (в основном изображения, CSS- и JavaScript-файлы), в процессе повторной загрузки страниц или запроса идентичных ресурсов при открытии новой страницы. Внесённые разработчиками Firefox (https://hacks.mozilla.org/2017/01/using-immutable-caching-to.../) и Chrome (https://blog.chromium.org/2017/01/reload-reloaded-faster-and...) изменения позволили на 60% сократить число запросов статических ресурсов, что привело не только к снижению нагрузки на серверную инфраструктуру, но и значительно увеличило скорость загрузки страниц.В частности, за счёт сокращения отправки лишних сетевых запросов для проверки актуальности прокэшированных браузером ресурсов, скорость повторной загрузки страниц Facebook возросла на 28%. При этом изменения не специфичных для Facebook и аналогичным образом повышают эффективность работы с любыми другими сайтами. Например, разработчики Chrome провели более глобальное измерение, в котором выяснили, что после внесения оптимизаций время загрузки всех сайтов, на которых 90% ресурсов загружаются повторно, сократилось на 1.6 сек. при использовании 3G-соединения.
Инициатива по повышению эффективности кэширования была предпринята после изучения в Facebook особенностей повторного запроса ресурсов в условиях изначально заданного большого времени жизни. Для максимального использования кэширования на стороне браузера в Facebook URL каждого статического ресурса включает уникальный хэш от его содержимого, что позволяет выставлять изначально большое время жизни записей (заголовок "cache-control: max-age=" установлен в год), не заботясь о вопросе сброса кэша после изменения файла (если файл изменится, изменится хэш и URL, что приведёт к загрузке файла независимо от времени жизни элемента к кэше).
Проблема оказалась в том, что несмотря на большое время жизни браузеры продолжают достаточно интенсивно отправлять проверочные запросы, оценивая время модификации файла. В частности, при перезагрузке пользователем ранее открытой страницы перепроверка актуальности всех ресурсов, в том числе внешних, выполняется независимо от того истекло время жизни записи в браузерном кэше или нет. В результате, несмотря на выставление времени жизни статических ресурсов в год, в 2014 году около 60% всех запросов приводило к выводу ответа с кодом 304 (файл не изменился). При этом, в обращениях пользователей Chrome проверочных запросов было 63%, Firefox - 13%, IE - 14%, Safari - 22%.
Как видно из статистики, основной вклад во внеочередные проверки вносил браузер Chrome. Анализ кода показал (https://chromium.googlesource.com/chromium/src/+/540d0cca0eb...), что Chrome всегда отправляет проверочный запрос, если обращение произведено с использованием метода POST. Разработчики аргументировали такое условие тем, что часто POST-запрос приводит к изменению страницы и необходимо всегда обеспечить показ самого актуального варианта. С другой стороны, операция авторизации в Facebook также проводится с отправкой данных методов POST, что приводило к перепроверке всех ресурсов при каждом входе пользователя в Facebook, игнорируя состояние кэша. Исправление данной особенности привело к тому, что число проверочных запросов от Chrome сократилось с 63% до 24%.
Продолжив анализ особенностей работы Chrome стало ясно, что Chrome считает перезагрузкой страницы ситуацию повторного открытия через элементы навигации (например, когда пользователь возвращается к прошлой странице через кнопку назад), что другие браузеры не трактуют как перезагрузка. Исправление данной особенности существенно не повлияло на статистику и стало ясно, что причина в поведении браузера при нажатии кнопки "перезагрузить страницу". В ходе длительных дебатов был достигнут компромисс - не проводить повторную проверку для уже давно не изменявшихся ресурсов, но как и раньше проверять ресурсы, которые были изменены недавно. Изменения были приняты в Chrome 54 и привели к существенному ускорению повторной загрузки.
Что касается Firefox, то его разработчики не согласились (https://bugzilla.mozilla.org/show_bug.cgi?id=1267474) менять давно устоявшееся поведение кнопки "перезагрузить страницу", но реализовали заголовок "cache-control: immutable (https://bitsup.blogspot.ru/2016/05/cache-control-immutable.html)", предоставив администраторам сайтов возможность управлять поведением при перезагрузке. При наличии данного заголовка браузер считает, что текущая страница никогда не меняется и не выполняет повторные проверки. Изменение было принято в Firefox 49. Кроме того, для увеличения скорости загрузки страниц в Firefox 44 был реализован метод сжатия Brotli (https://www.opennet.me/opennews/art.shtml?num=43006), который по сравнению с gzip позволяет сократить размер отдаваемого содержимого на 20%.URL: https://blog.chromium.org/2017/01/reload-reloaded-faster-and...
Новость: http://www.opennet.me/opennews/art.shtml?num=45934
Старая Опера (не хромопера) при отключенном интернете открывала все вкладки из кеша, при возвращении назад грузила страницу тоже из кеша. Мало того, что и по оперативки была самая экономная так ещё и трафик экономила не хило.
Это вообще разные вещи! Одно дело - явно работать в оффлайн режиме, а второе, когда браузер работает с кэшом и при этом проверяет его актуальность. Но ты и дальше можешь поклоняться своей Опере
Как показал опыт пользования Оперой, явная работа в оффлайн-режиме при нажатии на "назад" намного чаще требуется и удобнее, чем перепроверка кэша на актуальность.
100500 плюсов этому анониму!
«в оффлайн-режиме», Буратино
«с кэшем», дубина стоеросовая
У меня нет кнопки редактирования, бывает пишу быстро, отправляю, а уже потом нахожу ошибки.
Спасибо Ельцину за развал образования, кстати. Я дитё перестройки, и не одинок
А по существу у вас 0, лишь бы придраться
> бывает пишу быстро, отправляю, а уже потом нахожу ошибкиЭто сродни признанию "сначала говорю, потом думаю". А виноват Ельцин.
>У меня нет кнопкиНажми "смотреть всё" и появится. Согласен, сайт весьма дурацкий и нелогичный. Этот комментарий 100% удалят, критику здесь страшно не любят.
> «в оффлайн-режиме», Буратино
> «с кэшем», дубина стоеросоваяКстати, «в оффлайн-режиме» - это у вас не правильно, и является типичным словом-паразитом, американизмом, портящим русский язык
Акцент на дефис.
На принцип связи слов.P. S. Извини за "акцент", "дефис" и "принцип".
> Акцент на дефис.
> На принцип связи слов.
> P. S. Извини за "акцент", "дефис" и "принцип".Оборот, использованный вами, используется следующим образом:
P.S.: Ля-ля-ля.
Акцент на отсутствие пробела и двоеточие.P.S.: А ещё в русском языке используются не прямые кавычки, а «ёлочки» и „лапки“.
http://new.gramota.ru/spravka/buro/search-answer?s=скриптум
> это у вас не правильно, и является типичным словом-паразитомслова зануды.
Язык дан нам для общения. И чем общение будет понятнее - тем лучше.
От засорения односмысловыми словами он не станет понятнее.
Единственное отторжение у меня вызывает выражение "дорожная карта". Многие остальные заимствования часто лучше подходят под контекст общения, чем русские аналоги. И нет ничего плохого, что язык становится богаче и позволяет более тонко выражать мысли и эмоции.
А как надо?
Дорогкская карта? Карта Дорога?
Планирование. И короче :).
http://www.bolshoyvopros.ru/questions/100926-chto-takoe-doro...
Например "разработан план работ" или "спроектировано", или просто "рассмотрено решение". В зависимости от контекста можно подобрать вполне правильные слова. Но "у нас уже готова дорожная карта по внедрению чего-то там" - совершенно некорректно. В английском way значит "способ, путь, метод, средство", т.е. способ решения чего-то. В русском дорога - это дорога. Т.е. термин ущербный, нарушает обратную совместимость.
Вообще-то, "дорожная карта" - это roadmap. Причем тут way, казалось бы?
"При чём тут", Буратино!
:-) шутка не удалась."Dorog, 2510 Hungary"
https://www.google.com/search?q=карта+дорогP.S. А может я нашел смысл там где его нет.
и по кнопке назад открывались страницы в том виде в котором ее покинул, целиком из кэша.
Еще в старой опере можно было отключить картинки и правым кликом в меню подгружать нужные. Мне этой функции очень не хватает. Видимо потому, что сейчас у всех интернет 100 мегабит, на таких, как я, с интернетом 128 кбит/с, просто забили.
В ublock origin есть фича по блокировке медиа-контента тяжелее какого-то порога. Ставится красный плейсхолдер и по клику картинка загружается.
Ещё был https://addons.mozilla.org/en-US/firefox/addon/imglikeopera/ . Вроде до сих пор можно заставить работать, переключив лису на старую систему кэша.
Старая опера работала с веб 1.0, но не выдержала нового, тяжелого интернета.
Опера была лучшим браузером. И по скорости, и по безопасности, и по удобству. И даже по кастомизации, если кому надо было, могли из нее такие конструкторы делать...
И до сих пор ни один браузер не имеет такого идеального скроллинга как в старой Опере.Убили его, глобалисты, американцы, окаянные. Как и Нокию.
А всё. Так больше не кодят. Через 20 лет разработчики гугла преподнесут "это" как их ново-изобретенную фичу.
Это кэширование иногда выходило боком в престоопере. Например, при недоступности соединения с сайтом, она вываливала страницу из кэша (иногда без стилей, изображений) и непонятно, то ли сайт тупит, но все-таки вернул какой-то ответ, то ли вообще недоступен и старье показывается из кэша. Медвежья услуга, в общем.
В Firefox бесит, когда редактируешь какую-нибудь форму, применяешь, а потом жмёшь "назад", а он не из кэша выдаёт, а сабмитит её заново. Или при восстановлении сеанса заново всё грузит и если сайт недоступен уже показанный прокэшированный вариант заменяет на страницу ошибки.
Кури google и about:config. Все настраивается.
Подскажите хоть что искать.
Можно подробнее. Мне тоже интересна данная возможность.
Товарищ аноним видимо больше не появится. Кто разобрался в вопросе, расскажите, очень раздражает этот режим работы
У меня набранный текст восстанавливается при нажатии "Go back".
Специально это не настраивал.Я делал изменения вот по этим страницам
lurkmore.to/огнелис
ru.wikibooks.org/wiki/Защита_конфиденциальных_данных_и_анонимность_в_интернете#Mozilla_Firefox
kb.mozillazine.org/About:config_entriesВозможно вот этот параметр browser.cache.check_doc_frequency
Но сейчас пробовал менять его - текст все равно сохраняется.На всякий случай - при "network.http.sendRefererHeader = 0" не сможете постить на опеннете.
> На всякий случай - при "network.http.sendRefererHeader = 0" не сможете постить на опеннете.Потому что реферер надо подменять на корень сайта, а не отключать. И уж точно не отключать при переходах в пределах самого сайта.
> В Firefox бесит, когда редактируешь какую-нибудь форму, применяешь, а потом жмёшь "назад", а он не из кэша выдаёт.Хм. А у меня не так. Возможно, в Debian мейнтейнеры приняли какие-то другие дефолты в about:config. Посмотрите на отличия вашего и нашего, может найдёте какую-нибудь разницу.
Они бы лучше подумали как создать адекватную замену убогому HTMLю.
> Они бы лучше подумали как создать адекватную замену убогому HTMLю.Так ты дам им свой совет инженерный, они то что, простые лузеры, а ты то знаешь толк
Им не ко мне, им к проекту Qt, который создал действительно самый лучший и удобный язык для построения интерфейсов.
Героям слава!
Зря минусуете, шикарнейшая вещь. Гораздо меньше текста, гораздо легче читается и валидируется.
Между прочем есть проекты, реализующие поддержку QML в браузерах. Т.ч. скоро можно будет весь интерфейс писать на нем, и подгружать объектом несколькими строками html.
Это хорошая новость.
Плохая заключается в том, что HTML + обвязка в виде css + ужаснейший api для яваскрита всегда будут работать медленнее, чем изначально правильно спроектированная система. Кроме того, в стандартах там столько ньюансов, что просто невозможно обеспечить идентичное поведение и рендеринг элементов на разных браузерах. Когда как в QML Rectangle - это просто Rectangle, куда его поставишь - там он и будет.
Он не open source. Этот показатель перевешивает все плюсы бинарных форматов.
Поговаривают что двоичные форматы проще для обработки и легче по трафику, чем текстовые.
"Бессовестно врут!" ©
Да, но open source'ность оказывается важнее.
> Да, но open source'ность оказывается важнее.1. Не для всех. Ярые адепты идут в тoпку.
2. Двоичность формата не означает закрытость. Формат может быть транслируем в текст и обратно напрямую.
3. Для особо интересующихся может быть версия сайта с «исходниками».
4. Да много чего ещё можно сказать, было бы желание. Мир не чёрно-белый, и компромиссы всегда найдутся.
> Ярые адепты идут в тoпку.Вот не идут. HTML чрезмерно избыточен и неудобен. Есть море аналогов, которые превосходят его во всём, но не взлетают... Google и другие крупные компании добавляют разные костыли, типа разных обфускаторов, сжатий и т.д чтобы удерживать HTML на плаву, вместо того, чтобы просто параллельно внедрить в chrome тот же зарекомендовавший себя в андроидовских приложениях qml.
>> Ярые адепты идут в тoпку.
> Вот не идут.Идут. Строевым шагом. Новые форматы не принимаются не потому что они открыты или закрыты, а потому что начинается эффект лебедя, рака и щуки. Каждый хочет что-то своё, и, в результате, хтмл остаётся. Стандарт он на то и стандарт, чтобы быть общим, вне зависимости от того, есть ли более продвинутые альтернативы, или нет.
> дам им свой совет инженерныйКонцептуально товарищ правильно говорит. Современный web - это примерно как игра типа сапер в документе doc. Если изловчиться, то работать будет (принципиальных ограничений вроде нет) и ЧСВ взлетит до небес. Но изначально word (или doc) придумывали немного не для этих целей... Так-то можно и на whitespace программы делать, но нормальные люди этим не занимаются.
С HTML сейчас примерно такая же ситуация - наворотили 9000 костылей и радуются что макаронный монстр решил все проблемы человечества. Задачу давно пора переосмыслить и решить иначе. Требования современного web давно уже переросли наивную концепцию гипертекстового интранета для публикации и обсуждения научных статей. AJAX, canvas, WebSockets, выпадающие меню на CSS и всякие NaCl наглядное тому подтверждение.
ИМХО, пора бы уже задуматься над какой-нибудь альтернативной концепцией HTML-ng.
Ты какой-то толстый сегодня. Попробуй стать тоньше.
> Ты какой-то толстый сегодня. Попробуй стать тоньше.Роман о становлении сетевого тролля, -- "Худеющий".
JSON. Но это убожество <trololololo><>><<<><>> уже слишком популярно.
QML - декларативный язык программирования, основанный на JavaScript, предназначенный для дизайна приложений, делающих основной упор на пользовательский интерфейс. Синтаксис в формате json, позволяет легко описывать любые анимации. Компилируемый, т.ч. клиенту не надо каждый раз интерпретировать тонны текста. Компактный по сравнению с html. Уже можно использовать в браузерах.
Нативная поддержка QML в браузере была бы очень кстати, но надежды на это пока особо нет.
Из текстовых форматов давно придумали, называется JSON. Есть даже сравнение на странице в википедии: https://ru.wikipedia.org/wiki/JSON
Бинарных форматов придумано море, но все они вообще не взлетели.
Какой-то идиот не способен отличить формат сериализации от языка описания интерфейса. Бывает.
отключил гуглятский spdy и на практике инет ускорился, хотя теория говорит об обобратном
> отключил гуглятский spdy и на практике инет ускорился, хотя теория говорит об
> обобратномМогу подтвердить. Давно отключил все гуглозонды в about:config. Браузер (по ощущениям) действительно быстрее грузит страницы.
SPDY deprecated жи в пользу http/2.0
> Компания Facebook подвела итоги инициативы по увеличению эффективности локального кэширования на стороне web- браузеров, проведённой совместно с разработчиками Chrome и Firefox.Три девицы под окном / Пряли поздно вечерком. / "Кабы я была царица, / - Говорит одна девица, / - То на весь крещеный мир / Приготовила б я пир"...
Итого выводы: в хроме понаворотили странной эвристики, которая будет меняться от версии к версиии и непонятно, как вообще работает, в фаерфоксе добавили нестандартизированный хедер. Оба молодцы.Если есть проблемы с кешированием (а они есть), нужно идти в w3c и начинать разработку нового стандарта, а не городить костыли.
По поводу фейсбучного POST: я не знаю, как у них устроена авторизация, но у всего интернета все работает, а у них, из-за странной авторизации, вся страница перегружается — так может переделать фейсбучный сайт, а не затачивать все браузеры под их страничку?
А может все же лучше chrome исправить, чтобы он корректно с кешом работал при POST запросах, а не переписывать все сайты под chrome?
нет, не лучше. Он корректно работает с кэшом. Работал. Теперь вот не будет.
То что у фейсбука пост-запрос возвращает фейсбук целиком вместо странички "ok, ты залогинился, через секунду покажем остальное", это проблема исключительно фейсбука и его чудесной авторизации.А вот ради фейсбуков переделать весь интернет чтобы он "корректно" работал со странным поведением хромокэша - это по нашему.
Мазильный вариант, на удивление, хорош - если какой-то файл в принципе не способен меняться, незачем его и переспрашивать. Но способен или нет - решает сервер, а не гуглоробот по одному ему ведомым косвенным признакам.Но я уверен что гугль это не примет. Даже если мазила продавит это через w3c.
Гугль очень любит свои гoвноэвристики и "сделать хорошо 60% пользователей, насрав на остальных".
> нет, не лучше. Он корректно работает с кэшом. Работал. Теперь вот не
> будет.
> То что у фейсбука пост-запрос возвращает фейсбук целиком вместо странички "ok, ты
> залогинился, через секунду покажем остальное", это проблема исключительно фейсбука и его
> чудесной авторизации.Эмм... Может я не прав, но ведь фейсбук действует без нарушения rfc на HTTP? А вот хром при этом инвалидирует кеш по post-запросу, хотя согласно rfc этого делать не надо.
Смотрите, со мною бывает такая история. Я начинаю на каком-нибудь ресурсе, позволяющим анонимные комментарии, писать комментарий, открываю для этого страничку с формой для комментария и пишу. Потом я тыкаю в предварительный просмотр, и вижу, что я забыл залогиниться. Я тыкаю в кнопочку login, логинюсь и вываливаюсь на какую-нибудь страницу сайта отличную от странички с заполненной формой для комментария. Что я делаю дальше? Я тыкаю в кнопку back браузера, и возвращаюсь на страничку с заполненной формой, после чего повторно тыкаю в предпросмотр и вижу предпросмотр своего комментария уже залогиненным.
Со мной случается и иначе -- скажем есть некий форум, на котором я логинюсь только для того, чтобы оставить комментарий, но всё остальное время стараюсь быть незалогиненным. Не знаю в точности зачем я так поступаю, но будем считать, что мне так нравится. Поэтому при логине я не ставлю галочку в чекбокс напротив "помнить меня". Такой логин работает недолго -- может час, может полчаса -- я не замерял. И это приводит иногда к косякам, когда я начал писать комментарий залогиненным, а закончил писать когда сессия окончилась. Естественно эти вещи выясняются когда форум внезапно отказывается принимать моё сообщение, предлагая логин. Но и здесь я вполне могу разрулить ситуацию, если сначала залогинюсь, а потом потыкаю в back.И что-то мне подсказывает, что если при post-запросах инвалидировать кеш, то ничего подобного уже не получится. Кстати я слышал, что Хром как раз не позволяет подобным образом действовать -- может врут? Может это не связано с тем, что он инвалидирует кеш при post-запросах?
> Но я уверен что гугль это не примет. Даже если мазила продавит
> это через w3c.
> Гугль очень любит свои гoвноэвристики и "сделать хорошо 60% пользователей, насрав на
> остальных".Так сколько, вы говорите, процентов пользователей хрома пользуется фейсбуком? Меньше 60? Откуда дровишки?
> Эмм... Может я не прав, но ведь фейсбук действует без нарушения rfc на HTTP?rfc - это 'request for comments'. То есть авторы этой (неудавшейся) попытки застандартизировать интернет, изначально понимали, что он никогда не будет всеобъемлющ и всегда устаревший. Все что там про кэши - судя по контексту, вообще относится к кэшинг-проксям.
Факинбуг вполне его соблюдает, дореформенная мазила и хром тоже. Послереформенный хром, как бы, уже не совсем, но, опять же, вы явно никогда не читали эти rfc.
Вместо этого есть общепринятые нормы поведения, опирающиеся на здравый смысл - когда я тут нажимаю кнопку "отправить", я уверен что не хочу увидеть то, что было на этой странице _раньше_, я хочу увидеть свой высер (и чужое творчество, надобавлявшееся за пол-часа писания). Автор сайта может мне в этом помочь, а может - быть косорукой обезьянкой, бороться за cpu тики сайта, а не моего ящика, просто не иметь полного контроля над заголовками, не желать усложнять себе траблшутинг. Поэтому браузер, если только ему явно не указали выбросить и забыть, посылает запрос HEAD - ээй , там у вас поменялось чаво, или можно из кэша достать? И это вполне нормальное поведение, если там на самом деле ничего не менялось - запрос/ответ происходят достаточно быстро, сам документ берется из кэша, и тормозит, как всегда, его рендеринг.
Но тут появляется факбук, с его аяксом, страницей, собранной динамически из ста кусков со ста разных хостов - и вместо единственного head мы вынуждены отправлять с полсотни (а потом долго и печально перерисовываем все эти навороты, то есть вранье про скорость можно свернуть трубочкой и засунуть вот-вот, туда). Факбук мог бы легко решить эту проблему, переделав свою авторизационную страницу, но ему проще переделать все браузеры.
Теперь, имея дело с хромом, надо либо пихать во все скрипты специальный антихромовый код, либо никогда не быть уверенным, что браузер действительно перерисует содержимое страницы, когда это понадобится. Здравствуйте, дублирующиеся сообщения, формы заказов и тому подобное.
Провижу, что все, кроме факбука, будет теперь у вас грузиться _медленнее_, ибо кодеры просто начнут бороться с кэшированием так, что от него вообще камня на камне не оставят.(поток вашего сознания пропущен, ибо вы вообще не понимаете, как работает веб)
>> Гугль очень любит свои гoвноэвристики и "сделать хорошо 60% пользователей, насрав на
>> остальных".
> Так сколько, вы говорите, процентов пользователей хрома пользуется фейсбуком? Меньше 60?я надеюсь, проникновение факбука по планете все еще не настолько велико, 60 - это моя оценка того, с какого количества гугль все же отказывается от сомнительных нововведений (ну то есть если половине пользователей станет хуже - наверное, все же откажется)
Извините за баян, но у айтишников обычно есть две проблемы :
Инвалидация кеша, именование сущностей и ошибка на 1
Большинство серверов давно умеют указывать что кешировать, что не менялось столько то времени,
Типа не качай а бнри из кэша,
А они наконец то допетрили, ну тормозные ...
> Большинство серверов давно умеют указывать что кешировать, что не менялось столько то
> времени, Типа не качай а бнри из кэша,В том то и проблема, что ты знаешь как давно не менялся файл на момент запроса, но не можешь точно знать когда он изменится в будущем. "cache-control: max-age" лишь прогноз и не факт, что за это время файл не поменяют. Узнать поменялся или нет файл можно только опять обратившись к серверу (если сервер вернул 302 то и возвращается файл из кэша, но запрос всё равно отправляется). Поэтому создатели браузеров придумывают всякую эвристику, а web-мастера прибегают к ухищрениям в виде даты/хэша/случайного числа в имени файла CSS/JavaScript.
> но не можешь точно знать когда он изменится в будущемЭто невозможно до изобретения машины времени. Но проблему научились обходить
> в виде даты/хэша/случайного числа в имени файла CSS/JavaScript.
... так что, это уже и не нужно по сути.
Всегда указываю картинкам бесконечность, а в html приписываю к ссылке параметр с датой изменения. При изменении картинки меняется параметр, т.е. меняется ссылка. Браузер скачивает измененную картинку как новую. Единственная проблема при таком подходе - на стороне клиента остается старая картинки, которая на моем сайте уже не используется. Браузер может статистически определить что она больше не используется и удалить, но делает ли он это? Или все мои версии копятся у клиентов бесконечно?
> Всегда указываю картинкам бесконечность, а в html приписываю к ссылке параметр с
> датой изменения. При изменении картинки меняется параметр, т.е. меняется ссылка. Браузер
> скачивает измененную картинку как новую. Единственная проблема при таком подходе -
> на стороне клиента остается старая картинки, которая на моем сайте уже
> не используется. Браузер может статистически определить что она больше не используется
> и удалить, но делает ли он это? Или все мои версии
> копятся у клиентов бесконечно?Хранятся, но не бесконечно, а в течение некоторого разумного лимита времени, порядка недели.
> Браузер может статистически определить что она больше не используется и удалить, но делает ли он это?Конечно. Когда юзер подошёл к предельному размеру кеша (а это почти всегда, если не очищает вручную/автоматически), браузер постоянно удаляет (самое старое лежащее или самое старое использованное) элементы, чтобы сохранить новые.
А можно ещё с заголовками передавать хеш файла и при повторной загрузке страницы сравнивать значения серверного и локального хеша. Увеличение скорости загрузки страницы будет существенным
Ты только что придумал https://ru.wikipedia.org/wiki/HTTP_ETag
Идея с хешем позволяла бы хранить одну копию библиотелки для всех сайтов
Именно. А заодно - оказала бы некоторое давление в сторону использования одних и тех же либ, а не "а вот мы чуток подправим и минимизируем по-своему". Глядишь, бардака в вебе стало бы чуть меньше.
Цукерберг подсчитал и решил сэкономить пару ярдов на инфраструктуре и пораскинул рамсы с королями браузерного мира.
Вот и нам простым юзерам перепало в виде экономии мобильного трафика и ускорения загрузки страниц.
Пафос к тому, что сколько не пости в багтрекер и не голосуй, простого юзера никто не послушает. Собака лает, караван идет...
> Цукерберг подсчитал и решил сэкономить пару ярдов на инфраструктуреименно так. Основное время уходит на отрисовку всей этой мегаперегруженной бни, а вовсе не на проверку устаревания. Сотня head-запросов вместо одного - огорчает только сервера мордокниги (потому что на той стороне складываются в миллионы).
Цукерберг мог бы просто изменить авторизацию (тем более что миллионы мух как год назад залогинились, так и сидят), но зачем, ведь в мире нет других сайтов кроме факбука (а если есть, прогнутся)
> Вот и нам простым юзерам перепало в виде экономии мобильного трафика и
вы все еще платите покилобайтно да еще и сидите в факбуке с мабилы через _браузер_ ?
Вас ничто не спасет, вы безнадежны.
Не фиг мой диск изнашивать каким-то кешированием, пусть с сайта запрашиваются странички снова каждый раз!
Если низкие задержки передачи и большая скорость, то почему бы и нет. Другой вопрос, если мобильный интернет и задержка, к примеру 500 мс, не плодя лишних соединений на страницу с 10 картинками уйдет уже 5000мс. Если взять скорость 3G то надо прибавить еще время передачи, которое для 3 Мб странице составит еще порядка 5000 мс. В придачу скачанные html, css, js, изображения надо разжать, распарсить, интерпретировать, скомпилировать, построить дерево и т.д. и т.п. html кстати в этом смысле оооочень неэффективный.
Выйдет без кэширования как не старайся, 10 секунд будет уходить на каждое открытие страницы.
Изменен ли файл или нет - должно обозначаться в html коде страницы, это единственный правильный метод. Сменился файл - смени ссылку, делов то. И клиент естественным образом поймет, новая ссылка - новый файл. И не надо никаких дополнительных запросов. Все эти cache-control: max-age - только для html страниц.
Так тихо и незаметно браузеры превратились в толстых клиентов фейсбука.
Вот чего я не пойму - почему фейсбук и подобные приложения вообще в используют как основу HTML/HTTP. Казалось бы - тащи сериализованный формат через какие-нибудь вебсокеты и полностью сам контролируй, когда, где и как его кэшировать (в LevelDB, например).