Оптимизация загрузки страниц на практике

а можно кат?

A.
$m = explode(' ', $d2);// $d2 - дата в формате MySQL - "YYYY-mm-dd hh:mm:ss"

$m['d'] = explode('-',$m[0]);// Разбиваем, чтобы потом получить штамп
$m['t'] = explode(':',$m[1]);

$md = mktime($m['t'][0],$m['t'][1],$m['t'][2],$m['d'][1],$m['d'][2],$m['d'][0]);


Вот так делать — это глупость.

1. Не будущее — лучше даже в mysql-ой базе хранить данные в виде unix timestamp. Т.е. обычным числом, тогда не придется так изворачиваться.
2. Даже если вы храните в дате, в выборке можно спокойно указать SELECT UNIX_TIMESTAMP(date); и получить на выходе готовый.
3. Даже если приходится хочешь-нехочешь а обрабатывать время в виде mysql-формате, то для этого существует php-функция strtotime.
4. А вообще, если делать по нормальному надо прямо в SELECT-формировать дату в нужном формате. Это спокойно делается, посмотрите ф-ии mysql для работы со временем.

Б. Даже в HTML выдаче лчше делать на основе E-tag, который может вычисляться как md5 или sha1 от времени последнего изменения страницы. Результат проще, но мороки меньше.

В. О eregi уже давно пора немного забыть.

1. последний вариант не будет работать корректно без mod_headers, лучше уже тогда

AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/x-javascript

— сам недавно так на одном виртуальном хостинге подрубал

либо так, как описано в самом начале неуказанной статью по сжатие:

AddEncoding gzip .gz
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ $1.gz [QSA,L]

2. Про gzip и альтернативные хосты ни слова — они применялись? Хотя, на странице, в среднем, не больше 5 картинок, так что особо и не требуется…

3. Да, и можно эту статью на webo.in перепечатать? :)

А результат-то такой? Какое было время загрузки, на сколько уменьшилось? Судя по сайту, он и неоптимизированный вряд ли тормозил – стоила ли игра свеч?

Ну а в среднем загрузка страницы насколько стала быстрее? Замеры проверяли?

без привязки к mod_php: $_SERVER['HTTP_IF_MODIFIED_SINCE']

"… тдаётся она в gzipованом виде с коэффициентом сжатия 9.."
Сожмет чуть лучше чем на 1...3, а процессора поест в разы больше

Насчет файлов с кириллицей — это проблемы с начтройкой сервера, такого не должно быть. И в баш-скрипте *всегда* берите имена файлов в кавычки, "$1" вместо $1, иначе будут глюки с файлами с пробелами и спецсимволами.

для оптимизации и чистки html кода могу посоветовать использовать tidy, www.w3.org/People/Raggett/tidy/

А я думал, че за глюки в ФФ3 иногда…

И на сколько сократился трафик? Какие результаты в целом? Или пока рановато мерить?

Спасибо, интересно.

Опечатка в третьей строке примера ($hrd=''), было бы хорошо исправить на случай копи-паста.

— BookCare — это отлично! Отчаянно хочу обложку :)

> Проектик маленький — сайт моих друзей Bookcare.

Да что ж такое… Проектик маленький, а раздел «Зачем мне обложка?» существует только в виде пункта меню.

# find *.jpg -depth 0 -type f -iregex ".*\.jpg" -exec ~/s.sh {} \;

Есть способ проще:

# for i in *.jpg; do ~/s.sh "${i}"; done

>>>… иначе страница будет загружаться через раз, так как в ответе 304 не было указано Last-Modified. Такое поведение было замечено за FF3.

Я столкнулся с подобной проблемой. Но у меня это отражается на картинках. Вкратце, я делаю поддержку тем для веб-приложения. Чтобы иметь возможность переключать тему «на лету» я добавил опции кэширования. Пока тема прежняя сервер для всех картинок и css отвечает 304, как только тема меняется, серве отвечает 200 меняя last modified timestamp и etag. Плюс я использую «Cache-Control»: «public, must-revalidate». Работает в Chrome, IE, Safari. В FF 3 работает «частично». Проблема в следующем. В приложении есть Табы, которые состоят из 3-х картинок — левая часть, правая часть, бэкграунд. Так вот Табов больше одного, соответственно одинаковых ссылок на одни и те же картинки столько же сколько и Табов. Так вот FF 3 обновляет картинки Табов не для всех Табов, причем LiveHTTPHeaders и Fiddler показывают что сервер работает правильно — отдает «свежую» картинку. Но FF 3 обновляет не все Табы :(( Такое ощущение что есть проблема в синхронизации. Например, FF одновременно шлет несколько запросов на одну и ту же картинку. Первый реквест получает 200 респонс. Следующий реквет уже получает 304 респонс. Первая картинка обновляется из респонса и кладется в локальны или ин-мемори кэш FF, но при этом успевает вернуться второй ответ с кодом 304, который лезет в кэш и берет еще не обновившуюся картинку %). Если кликнуть по любой ссылке или рефрешнуть страничку, то все обновится правильно, потому что в кэше уже будут лежать «свежие» картинки.

Помогите кто может советом, очень хочется побороть эту траблу?