@zelenin не нужно путать со здравым смыслом. Оптимизация не преждевременная, а как раз на базе накопленного опыта и наступания на грабли. Толковый разработчик изначально систему строит оптимизированной на необходимом уровне. И здесь дело не только в мегабайтах, хотя и они безусловно важны. Чем меньше разных размеров, тем меньше самих файлов грузит пользователь, меньше запросов обслуживает сервер. Те превьюшки, которые он получил на главной, на других страницах уже берутся из кеша. Это тоже большой плюс. Здесь нужно видеть все шире. Ваше утверждение неприменимо. Оптимизированная система тоже работает как часы, ничем не хуже, и даже лучше. Одно другому не мешает. Вы же эти понятия фактически противопоставляете, что в корне неверно. Я занимаюсь разработкой тем для WordPress уже не один год, и с размерами под разные форматы вывода сталкивался уже очень много раз. Паттерн "не плодить ничего лишнего без крайней на то необходимости" всегда был, есть и будет самым разумным подходом. Ваша позиция по "преждевременной оптимизации" - это обычная лень и нежелание разработчика принимать стратегические решения. "Сначала сделаем абы работало, а потом посмотрим, если что - допилим".
@zelenin все относительно. Например, я для оптимизации скорости работы сайтов использую VPS от Digital Ocean, который на SSD. Гигабайты SSD весьма недешевые. Простая математика. Пример: новостной сайт по шоу-бизнесу. Редакторы загружают целые фотоотчеты с каких-то вечеринок. Грузят файлы любых размеров, в том числе оригиналы прямо из камеры. Сверху еще генерится куча превьюшек разных размеров. Каша. Вес папки uploads увеличивается как на дрожжах. Далее ставится плагин Imsanity который ограничивает максимальный размер (грузить можно любой файл, но он потом ресайзится, таким образом оригинальный размер всех файлов никогда не превышает заданные размеры), ставится EWWW Image Optimizer для сжатия без потерь качества, проводится инспекция всех размеров картинок и из 6 разных размеров, созданных ЛЕНИВЫМ девелопером оставляются стандартные 3, которых в реальности более чем достаточно. В итоге, было почти 20Гб мусора, около 50 000 файлов. Становится 6Гб и меньше 20 000 файлов. В деньгах это выражается просто - экономия $20 каждый месяц.
Если картинка не подходит по пропорциям - есть CSS overflow. Это не я узко мыслю, я как раз стараюсь мыслить эффективно. А вот ленивые разработчики, вместо того, чтобы думать стратегически, плодят кучу дополнительных размеров, подключают сторонние библиотеки, и т.д. Владельцу проекта такой необдуманные подход рано или поздно вылазит боком.
@Lici есть плагин ajax thumbnail rebuild, отлично справляется. Но все же это лишний гемор. Мне с первым новостным сайтом пришлось уйти от хостера не потому, что места или трафика больше ел, а inodes не хватало. Файловая система была забита всякими дополнительными размерами и прочей ерундой.
@rOOse и один из 3х существущих вполне должен подходить, их размеры можно изменить в настйроках или через код. Я там на сайте вижу 2 размера - превьюшка поменьше и превьюшка побольше (о которой и идет речь). Первая - thumbnail, вторая - medium, и еще остается large для вставки больших картинок и original для полноразмерного просмотра в лайтбоксе, если нужно (хотя вряд ли). Зачем здесь плодить дополнительные размеры? Чтобы через год-два работы сайта папка uploads весила на 20% больше? Или чтобы при смене темы (дизайна) нужно было опять пересоздавать все превьюшки, менять размеры, создавать новые... Зачем?
@zelenin для начала можно обойтись изменением одного из предустановленных размеров. И только если этих разных размеров заметно больше, нельзя использовать что есть (в том числе уменьшая и подгоняя по размеру в css) - только тогда создавать дополнительные размеры. Ибо каждый дополнительный размер будет создаваться для каждой фотографии. Я, как владелец 2х новостных порталов, знаю чем это выползет через 2 года, когда картинок будет гигов 10. И когда захотите сменить тему, а там другие размеры.
@Calc А) править руки и мозги, потом код В) купить нормальный сервер С) Nginx отдает на самые разные бекенды и забирает от них D) см. п.B или дергаем одмина Е) реврайты в Nginx есть, при чем толковее F) это какие-то синтетические тесты и абстрактная теория, в реальности же на среднестатистическом VPS с 0.5-2Гб оперативы и 1-2 виртуальный ядром Apache никогда не будет быстрее Nginx, кроме того, он не выдержит даже небольшой нагрузки. На коробках с большими ресурсами поначалу разница незаметна, но она всплывает, как только растет количество конкурентных запросов - и все повторяется G) Да, это разные инструменты, выглядят по-разному и работают тоже H) Бородато. Такие конфиги на обработку .php сейчас еще кто-то ставит? Пост 2010 года.
@Calc зачем? Все, что есть в .htaccess, есть и в nginx.conf / %site%.conf. Как говаривал один очень толковый системный архитектор, "большинство ваших запросов не должно доходить до БД, а в идеале - и до PHP". Зачем поднимать процесс Apache, если все уже давно можно было отдать клиенту без его участия?
IFы в конфиге - зло :) ИМХО, кроном подсовывать конфиг и релоадидь - самое оно. Или еще проще, в самом сайте в главном обработчике сделать. Любой серверный язык легко позволит сверить время и пустить дальше или показать фигу + расписание работы.
@Fesor все правильно. ИМХО, веб-сервер, по определению, именно это и должен делать - все что не требует обработки отдавать сразу, что требует - передавать на обработчик и отдавать результат. Обрабатывать запросы - это и есть главная задача. Плюс event-based, конечно же. Схема работы Apache, как по мне, уже устарела и не может быть эффективной. И уж тем более я не вижу вообще смысла использовать Nginx как фронт перед Apache. Зачем эта толстая прокладка, если Nginx сам может работать с PHP напрямую? К тому же, Nginx еще и напрямую работает с Memcached, а также имеет свой fastcgi кеш. Одни плюсы, в общем.
@Calc не надо морозить чушь. Вы говорите про возможность Nginx работать как прокси. Тем не менее, это только одна из его возможностей. Это полноценный, быстрый и легкий сервер. Однозначно переходить, Apache в топку.
@Lisonok, сами то поняли, что посчитали? Полной загрузки не бывает, смело уменьшайте сумму в 3 раза минимум. Работать за 500$ в месяц - совсем некошерно. Даже для украинской провинции. Про русскую глубинку не знаю.
@buggykey господа, отбросьте паранойу, и перечислите что конкретно уходит в поисковик, что конкретно уходит в гугланалитикс, что конкретно уходит мобильному оператору и/или интернет-провайдеру, что уходит производителю железа и т.д. Кроме криков "все пропало" я не услышал ни одного четкого утверждения, которое можно было бы проверять и обсуждать. Одни эмоции.
И да, Win, как и софт, должен стоять лицензионный. А что тут такого? И при чем тут вообще слежка поисковиков? Нету денег на Windows - переходите на Ubuntu.
