Yoda

Вам советуют за 5000 рублей всё то, что делает ISP manager за четыре евро в месяц, или на множестве хостингов бесплатно. Не верьте сказкам.

Это ужасно? Я так удручен.. Вы сейчас серьезно вот это написали... Где проблема? В чем?

Здравствуйте дорогие мои читатели. Сегодня у нас на повестке оценка скорости работы сайта по данным PageSpeedInsight. За что я люблю гугл, за то что он дает постоянно работу разным шарлатанам. Им бы на завод впору пойти, или в сторожа. Но нет. Гугл выпускает очередную "супер важную муть" и на ней спешат наживаться всякого рода аферисты разных мастей. Ну не будем тыкать пальцами. Все итак знают, кто у нас умеет чудесно продавать одну строчку кода за 2000 рублей. Речь вобщем-то не об этом. А история у нас сегодня про https://www.modpagespeed.com/. Когда-то в 2013 году, когда я первый раз в жизни с двадцатого раза засетапил свой первый VPS, я пробовал ставить эту приблуду к апачу, что такое Nginx я тогда слыхом не слыхивал, а как его пересобрать и что такое ваще собрать ченить у меня не было ни малейшего понятия. Но годы проходят и седые волосы неумолимо приносят понимание. Как оказалось. Когда я пробовал modpagespeed эксплуатировать на своем первом сервере. Он был сырой, косячыный и сработал в очень ограниченном формате. Совершенно случайно, пару дней назад, в силу каких-то нелепых обстоятельств, я решил попробовать как это работает в нынешних реалиях. И о чудо!!! Эта штука автоматом, гонит все картинки в webp, там где надо, все это отлично открывается во всех бразуерах. Отличнейшим образом автоматом. Подчеркиваю.... Автоматом жмёт скрипты стили. Инлайнит это все дело там где можно... Ну и требует для установки времени совсем чуть чуть. Любой сисамин справиться. И при этом. У вас это все всерьез надолго... Без каких либо косяков на стороне файлов магазина. Без оплаты за "чудо-модули" не стоящие воздуха. И с кучей дополнительных плюшек, типа автоматического LazyLoad, асинхронного внедрения гугл-аналитики и гугл-шрифтов. И это все блиииин. Из коробки в один клик грубо говоря и работает... Друзья мои. Я вам крайне рекомендую посмотреть в эту сторону. Это реальный крутой ништяк. И в целом чаще гуглите профильную информацию. Оказывается нас всех некоторые персонажи держат за дураков и реально тупо парят пытаются впарить воздух! Да прибудет с вами сила!

Не надо никаких патчей. Этот mysqliz кривой на всю голову. Заберите с гитхаба 1.5.6 версию. Из нее возьмите db.php класс и драйвер mysqli из папки system/database. И поменяйте у конфиге mysql на mysqli

Сделать для одного сайта папку storage_1 для второго storage_2 и поменять конфиги.

Верно на 100% c одним дополнением. Необходимо оставить на старом домене доступный роботс с обновленными данными директивы host. И сделать грамотную преадресацию.

О вашем о вашем А) создает излишнюю нагрузку. Б) вызывает бесконечные конфликт. В) даёт не гора только иллюзию быстрой работы магазина и никоим образом не решает проблемы нагруженных проектов с большим количеством позиций. По факту маркетинговая шелуха. Если вы со мной не согласны. Просто лишний раз почитайте внимательно отзывы к вашему же дополнению. Это моё личное мнение, основанное на огромной практике, как в целом построения нагруженных систем, так и в частности по избавлению подопечных от проблем и с вашим дополнением в том числе. И здесь не нужно пытаться со мной вести беседы. Мнение у меня вряд-ли поменяется, а учить вас как не надо делать не входит а мои планы. Не здесь так в другом месте вы найдете кому это впарить под соусом круто и клёво.

В какой туман. Не решают эти модули поставленные задачи. А только создают излишние конфликты и нагрузки. Развод кроликов по факту.

А вы не задумывались о том, что Яндекс может менять код метрики чуть более чем чаще чем месяц, и не просто так у них время кеширования два часа. А также. Если внимательно почитать все 350 страниц мануала к Пейдж спид, там можно найти интересный текст, про то, что требования являются РЕКОМЕНДАТЕЛЬНЫМИ..

Некоторые отзывы здесь выеденного яйца не стоят. Не читайте утренних газет. Аналогов по скорости, по качеству кода и по реализации seo - нет!

Ну вы же описание читали, так и так. Прогрев кеша все дела. Заддосили сами себя. Автор везде рассказывает что это круто, но слабо имеет на самом деле представление о том, как должен работать кеш. Очень жаль, что подобные отзывы как ваш, решаются написать единицы, все остальные молча съедают и народ и ведутся на супер продающие рекламные обещания и золотые горы.

Реально рано или поздно у вас возникнут с этим фильтром проблемы. Купите И будет вам счастье!

Если честно, кроме того что какой-то неуч не может сам ничего толкового придумать в своих поделках, смысла в остальном тексте я не понял. 580 картинок десять мегабайт. Это к чему? Тут каждый второй автор типа быстрого шаблона показывает демо с зелененькими цифрами, забывая что магазин это не голый шаблон. А когда на боевом магазине десяток сторонних скриптов подвешивает себя на весь DOM вот эти фокусы с lazy могут вылиться а очень нелицеприятные последствия. И именно поэтому я вскользь упомянул эту тему, не раскрывая её подробно. К сожалению, вы в вашем подходе, ходите по тем же граблям что и все остальные. В погоне за технологичностью и пузомерками, забываете о балансе между оценкой робота Гугла и удобством для живых покупателей.

Черт, как вы плохо про меня думаете. Я специально не давал ссылку ни нак какие библиотеки, чтобы не было соблазна у начинающих начать творить. Что касается набюдений по Lazy в целом. Во первых, когда у вас допустим 3-4мб изображений и 200 штук на странице, пытаетесь из все обернуть в lazy - получите еще больший лаг при инициализации слушателей на элементах чем, сделали бы это просто так. Во вторых, я же вижу часто как это реализовывают. По моему из героев-спициализдов, никто ни разу не сделал нормальный те <noscript>.

Про это я даже забыл, хотя недавно сталкивался. Фильтр про большая редкость в последне время. Но в целом ренедирть на готовую страницу повторно набор товаров в нынешних реалиях - это плохая техника, равно как и даже очень быстрое, но ожидание ajax запроса, которым получается этот набор, даже если это 300-500мс. Ну вобщем тут как бы все понятно само собой. А по фильтру в целом, вы почти правильно сформулировали решение. В идеальном мире, набор параметров атрибуции должен грузится первично либо по событию поведения пользователя, либо по окончанию загрузки базового контента. Это вкладывается в общую концепцию алгоритма оценки, основная суть которого отобразить первичный контент как можно быстрее.

Нормальная мысль у frelancer, только не применима к опынкарпу, в силу изначальной реляционной модели. Из того что я понял, речь идёт о преобразовании хранилища в объектную nosql структуру и дальнейшую работу с товаром как с готовой коллекцией. Можно в таком же ключе рассматривать промежуточное решение и остаться в рамках все той же mysql, грн использовать json коллекцию вместо всех этих таблиц special, review и так далее. И возможно это здравая мысль была с точки зрения оптимизации работы вывода товарных предложений. Но у нас очень много базовых сущностей и достаточно сложных связей между ними. И при таком варианте nosql формат при попытке сделать представление чуть иного вида, чем товар, сразу превратится в ад. Использовать оба подхода это неоправданная избыточность. Ну и не стоит забывать про персистеность, крути верти, а информация хранится про деньги о деньгах. И все финансовые институты почему то предпочитают oracle или ms sql а не многодб или эластик.

Я подчеркну это написал Володя очень кривые запросы в базу. Исправлю за сто рублей свой косяк. И этот же Володя своими невменяемыми модулями, косячит каждый второй магазин который попадает мне в оптимизацию Друзья мои. PHP это очень многогранно и тот же ларавель это очень круто. Но у нас есть два варианта. Или Верить в тупых Володь у которых все равно кроме мочи. Или юзать самостоятельно фреймворки и понимать как ещё можно было. Не слушайте Володьи мракимракака, слушайте себя. Экспериментируйте пробуйте. А эти архитектурные ошибки пусть канут в лету.

Вот реквизиты Заносится практически откуда угодно, что вам еще непотяно?

Друзья мои. Мы к сожалению люди и иногда мы можем болеть. Как бы к кому я не относился. Когда в двери стучится беда - это не очень! Тут так получилось что один из наших соучастников попал в в неочень простую ситуацию. Наверное неправильного говорить про диагнозы, стоимость препаратов и все остальное. Поэтому я вам всем просто предлагаю поучаствовать материально в светлом будущем господина @vier долгих лет ему и здоровья. Для этого господин @spectre сделал сбор средств. И реально любая ваша копейка пойдет на пользу. Со своей стороны и со стороны администрации мы можем гарантировать что все до копейки отправится нашему герою и парню реально не будет лишняя ваша помощь! Спасибо! UPD: Пожалуйста - не надо лайкать этот пост!

не похожи на меня - не похожий на тебя. Просто так прохожий парень...

Есть возможность однозначно не рекомендовать использовать данные дополнения. В силу приведенных аргументов. А там каждый пусть решает как хочет.

Можно я без вас, пользователь с рейтингом 14, буду решать что мне писать, а что нет? Если вы считаете данную информацию не интересной - не читайте. И не участвуйте в дискуссии, возможно она будет полезна другим людям. Спасибо.

Далеко не у всех есть возможность следить за творчеством данного персонажа и экстермально латать за ним недоработки. В не самых старых версиях все это было реализовано соверешенно по другому и цеплялось во все дыры при намеке на малейшее использование этого хлама. Мало того, если вы немного разберетесь в логике работы - то вот это вот forms, валилось практически для любого варианта виджета, или как там оно. Поэтому проще выжечь и использовать утилитарные решения. Чем возится с бесконечными обновлениями. Если вдруг вы там по дружбе решите, что я это все выдумал - есть живой пример! Да и пост собственно не об этом. Не надо превращать его в очередной срач. А то сейчас прибежит киса и навалит тут 20 страниц параноидальных фантазий. А данный пост все-таки мое личное мнение основанное на определенном опыте решения общих проблем с оценкой гугла, и моими личными рекомендациями. Если вам что-то не нравится, или вы считаете по другому - вам никто не мешает написать подобный пост со своими личными рекомендациями.

Если пройтись поиском по форуму - тем, почему VPS лучше чем хостинг - будет вагон и маленькая тележка. Давайте попробуем обобщить и разобраться почему свой сервер практически всегда лучше виртуального хостинга. Возможности Хостинг VPS Тонкая кастомизированная настройка веб сервера (nginx+php-fpm) - + Возможность масштабироваться здесь и сейчас при возникновении таковой необходимости - + Простота администрирования + - Возможность построения полноценной доменной почты (ваши письма не попадают в спам) - + Возможность использования специальных сервисов (redis, sphinx, elastic), выбор типа сервера базы данных. - + Независимость от (соседей) на сервере и нагрузки, которую они создают - + Быстродействие (практически нет разницы, если говорить об одинаково настроенном окружении) + + Возможность создавать резервные копии на любое удаленно облачное хранилище - + Цена + - В целом для меня это основной набор базовых факторов, которыми стоит руководствоваться при выборе площадки для того или иного проекта. Если у вас небольшой магазин с небольшим трафиком, про VPS можно не задумываться. Если же вы хотите побить конкурентов в скорости работы проекта, то добиться максимально возможной производительности системы практически невозможно, так как и соседи мешать будут, и редис для кеша/сессий не вкрутишь, и Apache не выжжешь напалмом. А когда речь заходит о глубоком индивидуальном тюнинге проекта, каждая сотая секунды ответа сервера на счету и к сожалению, пока что ни один хостер, не дает развернутся в рамках обычного виртуального хостинга на полную катушку. Они там пытаются, кто memcache продает под сессии, кто версии php на выбор предлагает. Но в целом в силу особенностей архитекутры веб-сервера, реализовать в рамках виртуального хостинга доступ к возможностям тонкой кастомизации системы на сегодня невозможно. А если говорить о каких-то совсем новомодных фичах, типа JSON полей в mysql, то без mysql8 никак не обойтись, а пока что про такое у хостеров можно просто тихо помечтать.

Как вы знаете, я давно и успешно борюсь с медленными магазинами. Мы научились делать магазины с миллионом товаров, научились выгружать в яндекс-маркет несколько миллионов товарных предложений, научились держать 1.5-2к онлайна посетителей без единого разрыва. Сделали поиск, который умеет искать iphone-7 iphone7 и айфон7 и понимает разницу между iphone7 и iphone-8. И в процессе всех этих наработок как-то вот очень мимо меня проходил вопрос улучшения оценки под новый алгоритм pageSpeed. Последние пару недель появилась возможность провести определенные эксперименты с факторами, которые влияют на оценку, и наработать кое-какую методологию решения этой ситауции без потери работоспособности и масштабируемости магазина. К сожалению вот так взять и взять в целом описать что необходимо делать - фактически невозможно, так как выйдет целый букварь. Но кое-какие секреты я приоткрою. И давайте начнем с врагов. Часто-густо как оказалось, можно практически из воздуха получить 12-15 баллов, просто устранив чью-то глупость. Я не знаю кто это сделал. Но на многих-многих магазинах стоят модули СДЭК и Яндекс-Доставки. Разработчики этих модулей ходили на курсу программирования к Джигурде. Поэтому ничего зазорного не увидели в том, чтобы взять и на все страницы подключить api яндекс карт. Круто и клево. Вместо того чтобы рендерить страницы магазина, бразуер ваших клиентов стучит в яндекс и ждет-ждет яндекс карты. Зачем - я не знаю. У меня нет на это ответа. Но я знаю что делать. Если у вас есть какое-то такое подобное творение. Они разные все. Находите в коде кусок, отвечающий за подключение скрипта и делаете что то подобное: if (isset($this->request->get['route'])) { $route = $this->request->get['route']; if(strpos($route, 'checkout') !== false || strpos($route, 'simple') !== false || strpos($route, 'shipping') !== false) { ///...здесь пример из реального дополнения. У вас может быть другой код $this->document->addStyle('catalog/view/theme/default/stylesheet/sdek.css'); $this->document->addScript('//api-maps.yandex.ru/2.1/?lang=ru_RU&ns=cdekymap'); $this->document->addScript('catalog/view/javascript/sdek.js'); }; } В итоге, мы публикуем виджет карт, только там где он нужен. И не грузим ни сервер яндекса, ни своих посетителей. И в попугаях профит и покупателям быстрее. Такие же плюшки есть у @29aleksey в его модуле редактирования товаров, да и много-много где. Вобщем мораль басни такая. Сторонние скрипты да и скрипты в целом используем только там, где нам нужно. А теперь немного общей информации. Если раньше на оценку pageSpeed очень влияло время ответа сервера, то теперь за уменьшение ttfb от 2 до 1 сек для мобильных устройств, валидатор накидывает всего 6-8 баллов. И еще столько же при уменьшении от 1 до 200мс, как того требует стандарт. Также все эти новые форматы изображений, webp и вся прочая лабуда, на которой пытается хайпануть и нажится на несведущих пользователях @sitecreator в целом абсолютно бесполезна на сегодня и не является дефакто необходимым действием, при условии что вы в состоянии использовать jpegoptim и отказаться от png. С нормально сжатыми и очищенными Jpeg гугл вас любит. Также от этого никуда не денешься. Все скрипты и стили надо обьединять. К сожалению автоматически это сделать без потери для масштабируемости достаточно сложно. Но при желании возможно. Если не получилось объеденить стили просто пытаемся перенсти большую их часть в футер. Туда же идут font-awesome и гугл-шрифты. А еще оказывается просто волшебное действие на 15-20 попугаев оказывает удаление, выжигание напалмом модуля от одного очень много безответственно разговаривающего автора. Я думаю кому надо тот догадается. https://upyachka.io/img/f_boyangreposm_2c6c344.jpg Так вот там в модуле у автора есть подключение пары-тройки скриптов (капча, визивиг и прости господи bbcode 2019 год на дворе а у нас bbcode, следующим этапом морзянку можно еще вставить) на все страницы магазина по аналогии с Сдэком. А так как все его модули это архитектурная ошибка, которая не лечится, то проще все это снести и поставить нормальный модуль для статей. Что же касается внутренних страниц (категории, товары). То если вы используете любой фильтр, неизбежно вы получаете пессимизацию оценки, в силу того что набор элементов фильтра - это много-много объектов DOM, а делать рендеринг набора параметров фильтра по какому-либо событию, фильтрописатели еще не научились. Что касается карточек товаров. Там есть два вселенских зла. Одно всегда, второе приходящее. Первое - это всякие социальные share-кнопки, которые давно никому не нужны, но их все равно тулят во все шаблоны. Второе - это видосы с йотубера. Кнопки выжигаем. А йотобуер борем как то так: https://ruseller.com/lessons.php?rub=32&id=2125 это первое что нагуглилось в понятном формате. В целом 65-70 попугаев на мобиле - это не сложно, при условии того, что у вас в целом быстрый магазин, достаточно выкинуть весь лишний мусор и немного привести в порядок процесс генерации контента и подключения скриптов. Если же говорить о глубоком тюнинге и раскачке магазина совсем в зеленую зону оценки. То и это фактически возможно. Но. Во первых потребуется ограничение количества элементов в модулях на мобайл страницах и существенная переработка всех этих модулей. Во вторых в идеале необходимо разделить общий стиль css на части и подгружать каждый согласно пришедшего vieport. В третьих сделать все элементы максимально интерактивными, убрать лишний мусор и подгружать контент ровно там где он нужен. (тоесть если вам нужен фильтр, колбаса параметров должна грузиться по нажатию элемента, который его раскрывает. равно как и дерево меню и все остальные большие элементы). В четвертых необходима проработка модулей и разделение вывода изображений, или использование динмаических тегов верстки, для вывода разного размера изображений под разные форматы экрана. В пятых, все сторонние скрипты, типа тех же яндекс карт, виджетов вконтакта и прочих прочих, необходимо грузить по какому-либо пользовательскому событию, типа скролл, клик, свайп, а не сразу на страницу. На этом пока хватит. В целом друзья, не бывает плохих и медленных магазинов, бывают кривые руки выпускников курсов программирования имени Джигурды.