sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
я вам больше скажу. у хостера ukraine.com.ua, например, это и два года назад было. Т.е. у некоторых хостеров это есть. Но это не решает всех вопросов. Если для вас этого достаточно, то и хорошо для вас. Но вот пользователи хостера ukraine.com.ua все же устанавливают мой модуль. Значит, что не хватает все же чего-то. mod pagespeed не умеет сжимать JPEG. И это большой его недостаток. Поэтому если кто-то кричит, что можно для сжатия JPEG вместо модуля Компрессор использовать jpegoptim или mod pagespeed, то этот человек либо заблуждается, либо намеренно пытается ввести в заблуждение. Я склоняюсь к тому, что некоторые псевдогуру на деле просто малограмотны в вопросах графики. О безграмотности в данном вопросе говорит хотя одно утверждение, что jpegoptim - это якобы одно и то же, что mozjpeg. Прежде чем такое заявлять неплохо бы матчасть подучить, и понять наконец то, что же реально умеет jpegoptim. И почему имея якобы такой прекрасный инструмент как jpegoptim разработчики из Мозиллы решили создать mozjpeg? -
такого не бывает на обычном хостинге. вы просто заблуждаетесь. так я вам объяснил за счет чего она видна. не за счет веса изображений. вес после этого мода получается больше чем после Компрессора. Заблуждение. У вас же VDS!
-
@rassigor , вот смотрите, вы благодаря модулю "Image Compressor & Watermark & WebP" имеете на своем сайте водяной знак, пользуетесь возможностью избавиться от белых полей. Вы же всем этим пользуетесь, не так ли? Что еще заказывали у "афериста?". Не вы ли заказывали "стикеры для яндекс-маркета"? Ну и как? Так зачем же вы тащите в эту тему неадекватного человека, который только и может, что обвинять практически всех авторов данного ресурса? Да, и mod pagespped не сделает ваши изображения меньше чем умеет модуль "Image Compressor & Watermark & WebP" (он их даже не сделает хотя бы такого же малого веса), не выведет webp в браузер без танцев с бубном, не наложит водяной знак, не обрежет белые поля, да и много чего не сделает.... То, что вы получили какие-то чудесные оценки, с изображениями не связано. mod pagespped умеет объединять JS, CSS, умеет выкидывать лишний код из итогового HTML. Но это вы могли и сами руками сделать. На мой взгляд, вы попробовали сделать масло масляным. Т.к. изображения итак у вас уже сжаты были. Прежде всего нужно уметь анализировать. Модуль "Image Compressor & Watermark & WebP" прежде всего задумывался как комбайн по работе с изображениями, решающий практически все задачи, которые возникают в этой области.
-
Кстати, если речь идет о дополнении гугла для апачи и nginx под названием "pagespeed", то я давно знаю это дополнение для сервера. Впечатления двоякие. Насколько знаю, то из бета-версии данное дополнение так и не вышло. И по работа с изображениями у него довольно много неоднозначностей и глюков. Подходит только для VDS. И если у вас не чистый апачи, а nginx+апачи, то поставить его на nginx - это непростая задача. Рядовому пользователю с ней не справиться. Я его рассматривал в свое время как хороший вариант, много с ним игрался. Но в итоге не понравилось. В основном тем, что этот "pagespeed" переделывал jpeg даже тогда когда его не просили, и что самое неприятное - он делал изображения бОльшего веса чем делал это модуль Компрессор. Т.е. он из маленьких изображений, которые уже сделал Компрессор, делал более тяжелые. "pagespeed" сжимает png по алгоритму optipng.
-
я не читаю глупости, особенно от людей которых то изгоняют с форума навечно из-за создания постоянных срачей и склок, то банят периодически из-за этих же самых срачей. Этот персонаж у меня в игноре. Если что-то хотите спросить, то спрашивайте своими словами.
-
Здравствуйте. Персонально для вас могу устроить. В личку.
-
В качестве примера. На главной вес после сжатия уменьшился вдвое. По версии гугла выиграли 5 секунд при загрузке. ДО и ПОСЛЕ:
-
Пример неправильного конфига Nginx: Внес соответствующие пояснения в информацию про конфиг: Просто будьте внимательны и все получится!
-
Вы просто не застали повестки, отпечатанные в советское время. У нас они даже в начале 2000-х были. Вот там неподражаемая формулировка была - именно "рекомендую". Поверьте, такое из памяти не стирается. Я именно такие получал, и никогда не нарушал рекомендации. Также еще были варианты с "Предлагаю", но никакой обязаловки. Т.е. слов "обязываю" или "приказываю" не было, все как бы на мое усмотрение - хочу приму предложение/рекомендацию, а хочу - не приму. Возможно, что это местные приколы районного военкома. Но у нас именно такие ходили.
-
Повышение версии PHP
sitecreator replied to deltex's topic in Opencart 2.x: Setting and optimization
не надо ничего патчить. просто добавляете этот файл с mysqliz. в папку system/database а в конфиге прописываете mysqliz вместо mysql. И, насколько помню, то mysqliz полностью повторяет файл mysqli из той же папки. Только переменные/свойства местами названы иначе. -
он это не так говорит. лучше читать первоисточник. Гугл четко заявляет, что это один из важных факторов ранжирования. Этот фактор - скорость. Иначе с таким же успехом можно назвать рекомендацией предложение поисковика работать над контентом. Гугл всегда только рекомендует. Также как военком в повестке: "рекомендую явиться вам...". Мне всегда нравилось это слово в повестках. Кроме гугла есть только яндекс. Но Украина отказалась от яндекса, у них только гугл. Потому внимание к нему понятно. Бинг даже 1% пользователей не пользуются. Не будет, а уже полгода+ как есть. И вы тут по большому счету правы, когда ставите в ряд с сотней остальных. Но не вполне. гугл выделил этот фактор как особо важный наряду с несколькими другими важными факторами. Вот про прочие сотни других факторов гугл вообще нигде не пишет, про них можно лишь гадать. Но гугл пишет только про важные факторы. Уникальность контента - один из важных факторов. Никогда гугл про малозначительные факторы не пишет. А тут фактор именно важный.
-
а сам гугл уже не годится? Там на английском местами, но переведете ведь? Гугл вполне однозначно и недвусмысленно пишет об этом. Читайте первоисточник. Все ссылки на официальные заявления гугла есть прямо на его странице: https://developers.google.com/speed/pagespeed/insights/ В ваших словах противоречие. Оценка PageSpeed напрямую связана со скоростью. Это, собственно, и есть оценка скорости - реальной скорости. Но это не единственный фактор ранжирования, но один из очень важных. В общем, читайте гугл.... Он вполне четко написал почему будет опускать сайты из-за скорости.
-
А что делать если Гугл сайты ранжирует в поисковой выдаче согласно оценке PageSpeed? При прочих равных среди конкурентов вы будете тем ниже в выдаче, чем ниже ваша оценка. Поэтому любовь как бы взаимная...
-
этот адаптировать не надо. он есть под опенкарт 3.0 вот: Но дело в том, что под 3-ку практически нет спроса. А потому даже не спешу делать новые версии для нее. Под нее функционал у меня отстает. Продаж для 2.* на этом форуме: 330, продаж для 3.0: 3. Для 3-й меньше 1% продажи. В принципе мой модуль можно взять от 2-ки и переделать под 3-ку. Для этого все открыто, что нужно переделывать. Но если вы не автор, то дело это довольно гиморное, т.к. на автомате переверстанный шаблон в twig даже если сразу и заработает, то все равно останутся нюансы, которые нужно поправить руками. Поэтому я бы не сказал, что это простое дело. Теоретически в 3-ке можно включить режим совместимости с шаблонами tpl и даже использовать модули от 2-ки. Но это чисто теоретически, т.к. работает через пень колоду, не всегда и не в любой ситуации. Я для своего модуля включал режим совместимости с tpl. И на дефолтный опенкарт 3.0 ставил свой модуль от 2-ки. И даже все замечательно работало пока не стал ставить разные другие модули.... вот тут и начались проблемы. Модули разных авторов с включенным режимом tpl чудили и выдавали всякие гклюки местами. Поэтому реально на тройке должен быть только режим шаблона под twig, конечно, если нет желания получать сюрпризы и заниматься бесконечной отладкой. В общем, 3-ка - это очень для больших любителей...... А если есть желание создать магазин без проблем, то лучше на 2.3 делать. Для 2-кй полно модулей, они часто дешевле чем для 3-ки.
-
здравствуйте. вы можете полностью управлять этим процессом. И настраивать очень гибко. Включать только там, где вам необходимо. И контролировать любой файл и/или папку.
-
Приходится еще и такие названия файлов учитывать при разработке: Под Linux нормально работает. Под Windows (особенно если php ниже 7.1) есть проблемы с созданием webp файла с таким названием. Поэтому просьба все же придерживаться правила не создавать названия файлов с пробелами, кириллицей, всякими вредными символами вроде (# &), не писать названия одновременно на Кельнском диалекте и иврите с вкраплениями чего-то на кириллице. Но тут многие заказчики сетуют, что черти-какие названия для файлов дает поставщик. Постарался (максимально насколько возможно) чтобы Компрессор переваривал такие названия. Тесты под Linux в этом плане удачные. Но вам никто не гарантирует, что проблема из-за таких названий не вылезет еще где-либо в будущем.
-
это только в части php. Притом, что именно эта версия (7.0) самая глючная в плане утечки памяти. На 5.6, например, таких проблем не встречал. Именно в режиме php-fpm. Удивлюсь если у вас их нет. Вы это можете определить по графику (пила) для памяти. И всегда почти на максимуме. Но это все решаемо. Примерно так выглядит: Не такой ли ваш график? да и по серверу БД, думаю, что вы могли бы получить значительно большую отдачу. Поверьте, но вы многого не знаете и не догадываетесь про свой сервер.
-
1.10.7 - это довольно стабильная версия, хоть и имеет приставку бета. На десятках самых разных хост-площадок эта версия стабильно создает webp даже если хостер изначально такой формат никак не поддерживает. Охват сейчас примерно 98% самых разных хостеров в том плане, что webp будет гарантированно работать (создаваться). в 1.11 охват разных хост-площадок будет порядка 99.5% -99.9% в том плане, что webp будет гарантированно работать (создаваться). 100% не пишу по той причине, что говорят о существовании хостингов, на которых даже php нет. Поэтому на бесплатных и всяких "супер-эконом" может быть все, что угодно. Поэтому 0.1% отказов заложил. В реальности все же ближе к 99.99%. Поэтому вопрос "будет ли работать на моем хостинге" тоже уходит в прошлое. Будет практически везде. Если у вас php 5.6+ (с ioncube loader 10+). Еще ни разу не встречал хостера, у которого не было бы этой версии php.
-
подождать. прямо сейчас выйдет 1.11 В ней основной режим - это работа по расписанию (cron) с возможностью задания определенной нагрузки на процессор / память в единицу времени. Т.е. подстроиться можно под любого хостера. Даже под самого вялого и несчастного хостера, точнее, под хост-площадку, которую выбрали именно вы. В конце концов, экономите же вы, а не хостер, т.к. он за ваши денежки готов вам дать столько мощности, сколько вы пожелаете. Например, можно задавать 100 изображений/минута, а можно и 1000 изображений в минуту. Разумеется, что это максимальные значения. Для VDS и серверов также можно задавать сколько одновременных потоков разрешено для выполнения сжатия. Т.е. если у вас 4 ядра, то можно задать выполнение в 4-х потоках одновременно и в каждом потоке до 1000 изображений в минуту. Потоков может быть несколько и на одном ядре. Просто одно ядро не стоит перегружать излишними процессами. Т.е. долой любые тормоза! Полностью уходим от стратегии генерации изображений "на лету". Это годится только для довольно мощных VDS, и если такой VDS легко переваривает огромное кол-во файлов. Этот режим "на лету" еще остается, но его рекомендуется использовать только для тестов. Например, можно использовать этот режим вместе с админ-баром Компрессора, там кеш очищается только для одной страницы, а потому никакого всплеска нагрузки не будет. Вот для одной страницы можно и на лету создавать, при этом крайне желательно на время тестов включить режим для магазина "обслуживание" чтобы на других страницах ничего не создавалось на лету помимо вашей воли, а то боты вам враз насоздают.... Не надо очищать кеш изображений! Его очищать имеет смысл только если у вас изменяются изображения, например, вы наложили водяной знак, применили обрезу и т.д. и т.п. Если же вам нужно только сжать, то не очищайте этот кеш. Все будет создано автоматически по расписанию. @rassigor , у вас VDS? товаров то много.
-
Добавил одну строчку: expires 30d; Чтобы кеширование в браузере нормально работало для jpeg, png. Также добавьте в список webp в другом месте. вот так должно выглядеть: location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|ttf|woff|woff2|webp)$ { expires 30d; } Этот код у вас находится где-то ниже чем вставка в конфиг, которую вы сделали. И этот код может дублироваться для http (80 порт прослушивается) https (443порт прослушивается). Поэтому смело добавляйте дважды. Иногда может понадобиться перезагрузить nginx. Или нужно попросить его перечитать конфиг. Но это если вы правили файл напрямую, а не через ispmanager. это команда! Это не конфиг! systemctl restart nginx или так (это команда! не пихайте это в конфиг!) systemctl reload nginx
-
потому что вы были невнимательны. не туда смотрите. Вам уже подсказали выше где смотреть. Смотреть исходный код не надо, надо смотреть, что загрузилось. Точнее, какого типа загрузилось изображение.
-
Еще немного информации для сравнения. Очень часто WEBP даже по сравнению с сжатым mozjpeg имеет преимущество, и позволяет уменьшить вес в 2 или 4 раза. Проведя некоторое исследование, сделал вывод, что WEBP лучше чем mozjpeg сжимает файлы изображений, в которых изначально качество не очень высоко (некоторая размытость, зашумленность и т.п.), в таком случае WEBP включает интеллектуальный механизм и не позволяет раздувать бессмысленно вес конечного файла. Сравните сами (разница в весе в 4 раза! 65К против 17К): http://watermark.sitecreator.pro/img_test/udilishhe_xerabuna_chuang_01-800x800.jpg http://watermark.sitecreator.pro/img_test/udilishhe_xerabuna_chuang_01-800x800.webp
-
Для сравнения. Файл, созданный стандартной библиотекой GD, которая работает в опенкарт, сжатый файл за счет mozjpeg файл WEBP. Чтобы избежать лукавого сравнения я не стал приводить оригинальный вес файла после фотошопа. Он больше файла от GD в два раза. Сравнение с оригиналом не вполне уместно будет в данном случае. Но многие заказчики подобные оригиналы вставляют по прямым ссылкам, тогда в случае WEBP разница будет раза в четыре в пользу WEBP. Просто нужно понимать, что после фотошопа JPEG часто выходит с полиграфическим качеством, годным для профессиональной печати, но это будет неуместно для ВЕБ. размеры: 1) 170 К (GD opencart) 2) 101 K (mozjpeg) 3) 75 K (webp) Кто-то еще против webp? Все файлы для анализа: http://watermark.sitecreator.pro/img_test/468-900x1350.jpg http://watermark.sitecreator.pro/img_test/468-900x1350_mozjpeg.jpg http://watermark.sitecreator.pro/img_test/468-900x1350.webp
-
По сравнению с уже сжатым JPEG (за счет mozjpeg) у webp часто есть преимущество. это более меньший вес, часто на 25% разница с уже сжатым файлом. Только сравнивайте при одинаковом параметре качества. Например, при 80. И не ставьте для webp параметр lossless! От этого ваши изображения не станут лучше, но вес увеличится. Все же вижу, что нельзя обычному пользователю давать волю самому выбирать все параметры. Он в них не разбирается, а потому может выбрать неудачную комбинацию. Поэтому стараюсь максимально оптимизировать выбор параметров самим модулем автоматически.
-
Кстати, если вы используете для вывода webp конфиг nginx, то никаких проблем с индексацией изображений не возникает. Могу судить, например, по нескольким сайтам, которые только вчера (или пару дней назад) включили webp, а сегодня гугл уже переиндексировал заново бОльшую часть картинок. Причем часть сайтов раньше работала без водяного знака, и установлен он был через модуль Компрессор с одновременным включением WEBP. В результат индексации гугла попали уже изображения с водяным знаком. Т.е. именно новые изображения, на которых уже водяной знак (в отличие от старых) и плюс используется формат WEBP. За последние несколько месяцев (полгода или около того) ни разу не было даже намека на какие-либо проблемы с индексацией изображений из-за WEBP. Это мой опыт и опыт моих заказчиков. Думаю, что многие и сами давно поняли, что нет ни одного основания бояться применять WEBP.
