Comments 46
а можно кат?
0
дадада. простите великодушно =)
+3
Того, кто просит убрать под кат всегда минусуют. Но кто то же должен подсказать это автору? Зачем минусовать.
0
A.
Вот так делать — это глупость.
1. Не будущее — лучше даже в mysql-ой базе хранить данные в виде unix timestamp. Т.е. обычным числом, тогда не придется так изворачиваться.
2. Даже если вы храните в дате, в выборке можно спокойно указать SELECT UNIX_TIMESTAMP(date); и получить на выходе готовый.
3. Даже если приходится хочешь-нехочешь а обрабатывать время в виде mysql-формате, то для этого существует php-функция strtotime.
4. А вообще, если делать по нормальному надо прямо в SELECT-формировать дату в нужном формате. Это спокойно делается, посмотрите ф-ии mysql для работы со временем.
Б. Даже в HTML выдаче лчше делать на основе E-tag, который может вычисляться как md5 или sha1 от времени последнего изменения страницы. Результат проще, но мороки меньше.
В. О eregi уже давно пора немного забыть.
$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 уже давно пора немного забыть.
+5
1. последний вариант не будет работать корректно без mod_headers, лучше уже тогда
либо так, как описано в самом начале неуказанной статью по сжатие:
2. Про gzip и альтернативные хосты ни слова — они применялись? Хотя, на странице, в среднем, не больше 5 картинок, так что особо и не требуется…
3. Да, и можно эту статью на webo.in перепечатать? :)
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 перепечатать? :)
+1
1. Ну я не указал конкретно статью, просто сослася на сам сайт =)
2. Альтернативные хосты не применял, но, собираюсь, ибо сейчас сайт в зачаточном состоянии, а вообще — там основная задача — показывать товар лицом. например страница Каталога вообще только и содержит, что картинки/
3. почту за честь.
2. Альтернативные хосты не применял, но, собираюсь, ибо сейчас сайт в зачаточном состоянии, а вообще — там основная задача — показывать товар лицом. например страница Каталога вообще только и содержит, что картинки/
3. почту за честь.
+1
А результат-то такой? Какое было время загрузки, на сколько уменьшилось? Судя по сайту, он и неоптимизированный вряд ли тормозил – стоила ли игра свеч?
+1
Ну а в среднем загрузка страницы насколько стала быстрее? Замеры проверяли?
0
без привязки к mod_php: $_SERVER['HTTP_IF_MODIFIED_SINCE']
+1
"… тдаётся она в gzipованом виде с коэффициентом сжатия 9.."
Сожмет чуть лучше чем на 1...3, а процессора поест в разы больше
Сожмет чуть лучше чем на 1...3, а процессора поест в разы больше
+1
Насчет файлов с кириллицей — это проблемы с начтройкой сервера, такого не должно быть. И в баш-скрипте *всегда* берите имена файлов в кавычки, "$1" вместо $1, иначе будут глюки с файлами с пробелами и спецсимволами.
+1
для оптимизации и чистки html кода могу посоветовать использовать tidy, www.w3.org/People/Raggett/tidy/
+1
Ну тут не совсем такая оптимизация нужна. Например, в одном из методов уменьшения размера html-кода предлагается не закрывать некоторые теги. Тут же просто приводится к «идеальному» виду, например:
Тут размер увеличивается.
heading
<h2>subheading
is mapped to
heading
subheading
Тут размер увеличивается.
0
А я думал, че за глюки в ФФ3 иногда…
+2
И на сколько сократился трафик? Какие результаты в целом? Или пока рановато мерить?
+1
Спасибо, интересно.
Опечатка в третьей строке примера ($hrd=''), было бы хорошо исправить на случай копи-паста.
— BookCare — это отлично! Отчаянно хочу обложку :)
Опечатка в третьей строке примера ($hrd=''), было бы хорошо исправить на случай копи-паста.
— BookCare — это отлично! Отчаянно хочу обложку :)
+2
UFO just landed and posted this here
Ошибаетесь милейший, это не микрооптимизация сайтов визиток, а привлечение траффика на говносайт.
-1
> микрооптимизация сайтов визиток — конечно ахуенная тема. бред.
Ну уж простите, не у каждого есть под рукой яндекс. За неимением большего, попробовал воплотить методы на малом сайте.
Представленные методы без труда можно применить и на большом портале.
> ТС найди норм работу раз умный
Позвольте мне решать самому, что делать.
Ну уж простите, не у каждого есть под рукой яндекс. За неимением большего, попробовал воплотить методы на малом сайте.
Представленные методы без труда можно применить и на большом портале.
> ТС найди норм работу раз умный
Позвольте мне решать самому, что делать.
0
> Проектик маленький — сайт моих друзей Bookcare.
Да что ж такое… Проектик маленький, а раздел «Зачем мне обложка?» существует только в виде пункта меню.
Да что ж такое… Проектик маленький, а раздел «Зачем мне обложка?» существует только в виде пункта меню.
0
# find *.jpg -depth 0 -type f -iregex ".*\.jpg" -exec ~/s.sh {} \;
Есть способ проще:
# for i in *.jpg; do ~/s.sh "${i}"; done
Есть способ проще:
# for i in *.jpg; do ~/s.sh "${i}"; done
+1
>>>… иначе страница будет загружаться через раз, так как в ответе 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, который лезет в кэш и берет еще не обновившуюся картинку %). Если кликнуть по любой ссылке или рефрешнуть страничку, то все обновится правильно, потому что в кэше уже будут лежать «свежие» картинки.
Помогите кто может советом, очень хочется побороть эту траблу?
Я столкнулся с подобной проблемой. Но у меня это отражается на картинках. Вкратце, я делаю поддержку тем для веб-приложения. Чтобы иметь возможность переключать тему «на лету» я добавил опции кэширования. Пока тема прежняя сервер для всех картинок и 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, который лезет в кэш и берет еще не обновившуюся картинку %). Если кликнуть по любой ссылке или рефрешнуть страничку, то все обновится правильно, потому что в кэше уже будут лежать «свежие» картинки.
Помогите кто может советом, очень хочется побороть эту траблу?
0
Sign up to leave a comment.
Оптимизация загрузки страниц на практике