Как я выполнял советы webo.in

[homm]

preg_replace('#<!--[^>]+>#', '', $data);

а жадный квалификатор разве не съедает все от первого комментария до последнего тега?

preg_replace('#<!--.+?-->#', '', $data);

Так не лучше?

[ewgenij]

не, не съедает
он работает до закрывающейся скобки треугольной. а она только в конце комментария

[homm]

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

<!-- эта часть вырежется > а эта часть попадет прямо в код -->

[ewgenij]

мда я что-то тоже морознул) вписал ваш точный вариант
странно что я его часто видел, а тут свое кривое что-то вписал)

[remal]

Кроме того, такой регэксп не удалит многострочные комментарии.

Я бы воспользовался таким:
<!--[\s\S]*?-->
(возможно, что профи регэкспов закидают меня помидорами, но он работает, это я знаю точно:))

[akral]

А ваш код не равен

<!--.*?-->

[akral]

(Это вопрос)

[youROCK]

В любом случае, если вы пишете скрипты и CSS «по-старинке», или «правильно»:

<script ...><!--

alert("Hello world!");

//--></script>

Вырезание комментариев таким регекспом может вызывать потерю значимого кода.

[ewgenij]

а мы все скрипты вынесли в main.js :)

[volinrok]

Согласно YSlow помимо использования CDN еще нужно сконфигурировать ETags для JS/CSS файлов.

— There are 2 components with misconfigured ETags

* www.grinkevich.by/styles/main.css
* www.grinkevich.by/scripts/main.js

Entity tags (ETags) are a mechanism web servers and the browser use to determine whether a component in the browser's cache matches one on the origin server. Since ETags are typically constructed using attributes that make them unique to a specific server hosting a site, the tags will not match when a browser gets the original component from one server and later tries to validate that component on a different server.

[ewgenij]

Спасибо! ETags вписал как надо, а вот с CDN еще предстоит разобраться.

[volinrok]

CDN для такого сайта и не нужен.

Вообще очень рекомендую почитать blog.stackoverflow.com. Много интересной информации о оптимизации большого проекта.

Например вот здесь много полезного:
blog.stackoverflow.com/2009/08/a-few-speed-improvements/

[ewgenij]

Спасибо! Добавил в читалку, буду изучать

[BorisT]

> Выносите javascript и CSS во внешние файлы.
Разве лишнее подключение к серверу (загрузка внешнего файл) ускоряет загрузку страницы?

[ewgenij]

так они раз попадут в кэш и не надо будет к каждой странице
дополнительно приписывать по 10-15-30… Кб мусора. уверен, что ускоряет :)

[BorisT]

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

[BorisT]

Извиняйте, за сбитую хронологию сообщений. Поздно уже — руки плохо работают.)

[BorisT]

Тоже логично. Но наверное это не абсолютное решение. К примеру, главная страница яндекса — там почти все включено в один файл.

[Wott]

Ммм, прежде чем оптимизировать неплохо бы замерить и понять надо ли :)
Оптимизация ради оптимизации — это всего лишь хороших способ пораскидать кнопочки по сайтам.

[ewgenij]

для данного проекта и не факт, что надо было
это тренировка. а тест webo.in показал, что чего-то да и наоптимизировал :)
да и самому заметно. мелочь, а приятно)

[sunnybear]

хоспади…

[XAMelleOH]

И это говорит создатель webo.in? :)

[deniamnet]

ахаха, круто
вы вынесли весь JS в один файл (чем плохо в двух?), но зато понаписали кучу кода для того, чтобы второй js-файл работал в первом js-файле
имхо, это уже клиника
я не вижу никакого роста производительности в том, что вместо 124 запросов на сервер будет 125

[artch]

Это вы про аналитикс? Там дело не в запросах, а в том, что он периодически тормозит, и если скрипт подгружается inline, то вместе с ним тормозит и рендеринг страницы. Даже если он стоит перед </body>, то скрипт не даст сработать событию onload пока не протормозится.

[deniamnet]

в чем сложность перенести скрипт с гугла на ваш сервер? я не знаю, будет ли он работать, но по идее должен, если у гугла не стоит проверка на реферер
просто опять же дело не в скрипте от гугла, дело в том, что сделал автор топика — сделал мотоцикл, чтобы запустить велосипед
кстати, сколько себя помню — ни разу не тормозил скрипт GA

[ewgenij]

я думал его перенести себе, но здесь www.google-analytics.com/ga.js:
Last-Modified Sat, 12 Sep 2009 00:35:39 GMT
то есть нужно было бы еще и обновлять у себя его регулярно
а моей велик на мотоцикле сейчас летаей ой-йой-йой))

[Oleg_k]

несколько раз встречал при просмотре сайтов, ожидание запросов к GA

[deniamnet]

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

[artch]

А никто и не говорит про надежность. Речь про скорость доступа. GA подтормаживает. Нечасто, но может протормозить и пару секунд.

Переносить на свой сервер я не предлагал, это скорее всего противоречит EULA. А вот вынести в onload вместо inline — вполне разумное решение.

[deniamnet]

про onload вы правы

[artch]

Собственно, автор в топике это и сделал.

[LifeOS]

Знаете толк в извращениях…

[artch]

Слишком длинная и сложная статья. Надо было сократить до «Как я скачал и запустил yuicompressor».

[ewgenij]

нене. еще есть цели:
1. веб-сайт полностью посещает пару млрд. человек
2. веб-сайт полностью приводит тысячи клиентов
3. веб-сайт полностью сделал работников компании миллиардерами
ну и тому подобное. есть к чему стремиться :)

[kikaha]

Оптимизировано всё, что можно кроме GA — 85/82 и возможное ускорение по оценке сервиса 10%, на этом счел свою миссию завершенной

[deniamnet]

нене, вы не поняли… там еще замечания есть ))
«Загружается более 1 фонового изображения.»
«Размер фоновых изображений очень большой.»
«Загружается более 1 картинки.» о_О
короче, оптимизируйте xD

[sunnybear]

webo.in/ все равно лучше оптимизирован :)

[Freem]

И это блин, самый крупный форум в Казахстане — хотя есть плюс, ему есть куда стремиться, со своим то 1430%

[ewgenij]

Это же Центр Тяжести :)

[AstonMartin]

Вот если бы у вас в результате этих манипуляций показатель отказов уменьшился вдвое, вдвое выросли продажи, а трудоемкость поддержки и разработки сайта почти не увеличилась бы — это был бы реальный плюс =)

[ewgenij]

что-то не уверен, что для данного случая это реальный плюс :)

[AigizK]

Вчера только читал рекомендации «Разгони свой сайт» Николая Мациевского, там написано что не всегда архиваторы так хороши. Связано с тем что если js или css архивировать, то полная время получения файла будет равна времени на скачивание+время на разархивацию. Поэтому надо решить для себя каким каналом интернета пользуются ваши клиенты, и возможно лучше просто отдавать файлы уменьшенного размера. уменьшить можно с помощью CSS Minifier(http://www.artofscaling.com/css-minifier/) например.

[Vii]

YUICompressor ж вроде не «архивирует». CSS он просто сжимает, а в JS еще и локальные переменные переименовывает из, например, myLocalVar в m.

Может под-архивацией подразумевается gzip-сжатие на серваке.

[rootree]

По поводу FileETag-ов, не лучше ли будет использовать «FileETag MTime Size»?

[ewgenij]

YSlow сказал, что не лучше)

[rootree]

или даже можно так )))

[rootree]

<ifmodule mod_expires.c>
<filesmatch "\.(ico|jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault «access plus 1 year»
FileETag MTime Size