ArchLinux для веб разработчика.

Может быть я чего то не понимаю, но зачем надо постоянно отдавать css картинки и спрайты в в теле страницы (если я вас понял правильно то картинки идут в виде base64)? Оформление можно слить один раз и потом уже брать из кэша браузера. если картинок стилей и js на пол сотни кб то за двадцать просмотров набегает почти мб паразитного трафика.
точнее что именно требует перерасхода трафика ради более быстрой отрисовки страницы?
Да пребудет с вами знание ip адреса
Встраивание обычно не используется для крупных библиотек, а куча маленьких файлов типа создаёт кучу запросов, которые долго обрабатываются сервером.
Короче говоря, надо делать замеры и считать, что выгодно, а не тупо делать всё, что написано на webo.in.
lampslave
Такая оптимизация создаёт много мороки и мало выгоды, так что кроме ну очень высоконагруженных сервисов она в общем-то и не нужна.
P.S. А правду писали, что не умеют у нас делать средние проекты. Либо "хомепага для кота", либо хайлоад.
Да вся эта оптимизация на самом деле не сложна, просто код должен быть в порядке. Ну и конечно, для "хомепага для кота" не нужна, скорее всего. А хайлоад, да какой там хайлоад.... Скорость отдачи страницы еще не хайлоад.
Но то, на что я насмотрелся на американских сайтах и хостингах, иногда вообще ни в какие ворота не лезет. Я уже как-то говорил, что авторов Wordpress, представь они свой проект в России загнобили бы на корню.
lampslave
Встраивание обычно не используется для крупных библиотек, а куча маленьких файлов типа создаёт кучу запросов, которые долго обрабатываются сервером.
Короче говоря, надо делать замеры и считать, что выгодно, а не тупо делать всё, что написано на webo.in.
Это точно. :)
Страница должна быть в одной строке, без лишних пробелов, и, естественно, без переносов строк. Это лучше для DOM.
При верстке так не сделать, потому что крайне не удобно, а удалять несколько десятков/сотен байт (переносов и лишних пробелов) из подготовленной страницы для отдачи клиенту глупо и бессмысленно, а так как перед отправкой страница сжимается штатными средствами сервера, удаление дает экономии трафика всего в несколько байт, но заставляет сервер делать ненужную работу!
Стили, если не большие, а так оно и есть, как правило, внедряются прямо в страницу. javascript тоже.
Стили вообще все должны быть отдельно от страницы! это удобно для легкого изменения дизайна, и уменьшает объем страницы.
javascript тоже должны быть отдельно! а в страницу добавлен только динамически изменяемый javascript.
Небольшие картинки оформления и спрайты - туда же в бинарном виде.
А это вообще фигня полнейшая, так как каждый раз будут вместе со страницей отдаваться и картинки, что так же увеличивает размер страницы, и занимаемое процессорное время на сжатие плохо сжимаемых данных.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
И тем не менее, всё это присутствует на поиске яндекса и гугла. Так что выгода где-то всё же имеется. Но снова и снова повторю, что основной критерий нужности - замеры, причём не в "лабораторных" условиях, а в "боевых". А второй основной критерий - количество проблем для себя.

Касательно пробелов. Код того же гитхаба (как я его вижу) в обычном состоянии занимает 54 183 байта. В вытянутом в строку - 48 664. Итого 5,5 килобайт или 10% экономии на одних только пробелах.
Не забываем про сжатие и браузерный кеш!!!
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
Иногда сделать 10 запросов и получить "not modified" дольше, чем скачать 10 файлов одним куском.
Ну ну... браузер не делает запрос если в кеше есть данные, и они не просрочены!
а выше описанное поведение присуще только функции обновить.
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
А пруфлинк будет? :) Была такая возможность в Опере - при переходе вперёд/назад сразу отдавать всё из кэша, но при нормальном серфинге запросы делаются постоянно.
 
Зарегистрироваться или войдите чтобы оставить сообщение.