Сам себе gzip: сжимаем скрипты на 20% лучше

[@p0is0n]

Теперь заменим везде в теле функции this на self и посмотрим на результаты сжатия.

а на сколько t тяжелее s?

[@sopov]

А вы пробовали сравнить два результата? Там все видно.

[@Bambr]

Там в результатах используется переменная d, а не self, что в целом понятно.

[@p0is0n]

Вы это серьезно сказали?

[@TheShock]

this нельзя сжимать. а вот self — можно

[@tenshi]

зато доступ к this быстрее

[@googol]

В Google Closure Compiler есть возможнось алиасить переменные this, window, document. Но от этого отказались по умолчанию потому как это уменьшает скорость выполнения ~10%. В особенности V8 не любит это.

Спроситите в maillist они вам более развернутый ответ дадут.

[@Bambr]

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

Прям страшный сон какой-то, нет под рукой gzip :)

[@bondbig]

опередил меня на секунды )

[@realovich]

может автор имеет такой gzip… ) его-то может и не оказаться под рукой, тогда способ актуален:

[@bondbig]

gzip нам не переплюнуть, но когда его нет под рукой

Это как, простите?

[@Fesor]

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

[@bondbig]

так при чем тут ваш метод? Таки заставить сжиматься, независимо от того, включен гзип или нет? Плохая идея. То, что можно сделать на уровне сервера (и сделать хорошо), никак не стоит делать на уровне приложения.

[@Fesor]

Это не мой метод, поправочка маленькая ;)

[@bondbig]

а, ну да. )

[@ipetropolsky]

Бывает всякое: требования заказчика, старые браузеры, спортивный интерес… :) Кроме того, я думаю, можно организовать код так, чтобы он эффективнее сжимался gzip'ом, и тогда оптимизированные скрипты будут выигрывать и в .gz.

[@homm]

Старые браузеры никак не мешают отдавать gzip новым.

[@ipetropolsky]

Разумеется.

[@homm]

Как-то не хватает итогов, на сколько с применением данных техник стали меньше исходники, сжатые Closure Compiler и YUI Compressor, по сравнению с оригинальными исходниками, сжатыми ими же?

[@ipetropolsky]

Каким-то необъяснимым образом часть поста осталась в черновиках :) Спасибо за замечание, читайте пост целиком.

[@asm0dey]

GWT?

[@asm0dey]

На самом деле я был не совсем прав.
Все-таки там генерируется джаваскрипт, который достаточно сильно сжат именно вербальными методами. Но мне затруднительно сказать, сколько он экономит трафика, потому что он еще и обфусцирован до полной невозможности восприятия.
А сам GWT — это возможность написать клиент-серверное веб-приложение на php или java без знания html, javascript и css

[@ad_Wolf]

А разве GWT существует не только под Java'у?

[@asm0dey]

Родной он под джаву, но
code.google.com/p/gwtphp/
www.gwtphp.com/

Насколько они актуальны, я не знаю, потому что сам пишу на джаве.

[@chaliy]

Это тока сервеная часть. Клиентскую так и остается на java.

[@asm0dey]

/Клиентская часть — это по сути всего навсего один js+5 html файликов. Не думаю, что большой проблемой является их распаковать из war архива и заставить отдаваться через апач/инжиникс.

[@chaliy]

GWT это штука которая компилит java в javascript. Как одну из фитчей он потдерживает комуникацию с сервером. gwtphp это простейшая реализация протокола которым пользуется gwt. Никаких компиляций клиентского кода єта либа не потдерживает.

[@asm0dey]

А, то есть как бэкэнд нам все равно нужен сервер типа томката или глассфиша?
Для меня просто тема не особо актуальна, потому что у нас в продакшене все равно томкат используется.

[@chaliy]

То что компилит GWT для клиентской части, это набор статических файлов. JS, CSS, HTML и картинки. Их можно хостить где угодно. Мы например .NET стек, и хостим их под IIS. А вообще собираемся на CDN.

А уж серверная часть может быть быть начем угодно, по умолчанию это java и соотвевенно требует апп сервер. Но вполне может быть чем угодно. У нас это .NET. Вот и gwtphp, это тока серверная часть. Маленький опциональный кусочек.

Тоесть вы все ранво продолжаете писать клиентскую часть на java. Компилить ее в статические файлы. А сервер уже PHP.

Это я к тому что не существует GWT не под java. Есть интеграции с разными серверными стеками.

[@asm0dey]

А, теперь понял.
Да, мне как-то не пришло в голову, что именно джава компилится в джаваскрипт и так далее.
Прошу прощения за тупость.
Ну и в итоге имеем, что при желании GWT-приложение можно поднять на бесплатном хостинге с php+mysql. До вас мне эта мысль в голову не приходила, спасибо.
А нет ли аналогичных фреймворков для того же php? Чтобы мы написали на php, запустили, у нас создалось некоторое количкство файликов?

[@chaliy]

Про аналогичные фреймворки на PHP я не в курсе. Я из .NET стека. Под .NET есть, но они все пока-что уступают GWT.

[@iShaman]

Тестовый плагин весит ровно 1 КБ, в сжатом виде 576 Байт, в gzip 391 КБ.

391 килобайт?:)

[@ipetropolsky]

Ой, 391 байт конечно же :)

[@nbordovskiy]

Тестовый плагин весит ровно 1 КБ, в сжатом виде 576 Байт, в gzip 391 КБ.

Если там действительно килобайты, то Вы очень неплохо переплюнули gzip :)

[@ipetropolsky]

:)

[@build_your_web]

По-моему, правильное решение в этом случае — это написать предложение в саппорт Google Compiler'a и прочих сжимальщиков.

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

[@donnerjack13589]

Есть одна проблема. Дело в том, что обращение к методу через переменную более долгое, чем напрямую по имени.
Т.е.

obj["method"](); // Дольше, чем:
obj.method();

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

[@Aralot]

о, расскажите, пожалуйста, поподробнее? насколько дольше?

[@ipetropolsky]

Разумеется, этот подход не для тех приложений, в которых критична скорость (впрочем, как и ООП с его наследованием и другие навороты). Но если в пределах 5 строк 12 раз встречаются конструкции типа $(document), то уж обращение к свойству через переменную вы точно можете себе позволить.

[@asis]

ну тогда вы выбрали не удачную библиотеку для примеров. В ней как раз все критично.

[@sunnybear]

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

[@sunnybear]

Packer тоже примерно также писали. Только вот инициализация такого сжатого скрипта — неблагодарное занятие.

[@sunnybear]

также -> так же

[@iStyx]

Отличная статья, спасибо. Кстати, вы там случайно функцию копирайта выложили ;)

[@ipetropolsky]

Спасибо :) Поправил.

[@akirsanov]

Можно было бы завернуть весь скрипт в строку, провести часточный анализ слов и заменять самые используемые слова в строке на неиспользуемые байты.
Распаковщик будет в 50 байт.

[@lol2Fast4U]

Подобное я уже где-то видел… А, в плагине Lightbox для RightJS: rightjs.org/builds/ui/right-lightbox.js

[@lol2Fast4U]

«var self = this», кстати, помогает, если ночью, когда «мозги не варят», переключаешься между Python и JS кодом и путаешься %)

[@Mourner]

Я для своего Санкалка на 10к использовал ту же методику. :) Всё-таки удалось в итоге добить размер до заветных 10240. Основной прирост при это обеспечил модуль Math и все его методы — Math -> m, m.cos -> mc, etc. :)