Yoda

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

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

Если честно, кроме того что какой-то неуч не может сам ничего толкового придумать в своих поделках, смысла в остальном тексте я не понял. 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. В третьих сделать все элементы максимально интерактивными, убрать лишний мусор и подгружать контент ровно там где он нужен. (тоесть если вам нужен фильтр, колбаса параметров должна грузиться по нажатию элемента, который его раскрывает. равно как и дерево меню и все остальные большие элементы). В четвертых необходима проработка модулей и разделение вывода изображений, или использование динмаических тегов верстки, для вывода разного размера изображений под разные форматы экрана. В пятых, все сторонние скрипты, типа тех же яндекс карт, виджетов вконтакта и прочих прочих, необходимо грузить по какому-либо пользовательскому событию, типа скролл, клик, свайп, а не сразу на страницу. На этом пока хватит. В целом друзья, не бывает плохих и медленных магазинов, бывают кривые руки выпускников курсов программирования имени Джигурды.

Джино не супер от слова совсем. Даже Фаст ВПС получше будут. Занят я, дней десять точно. И на требования чтобы все летало, есть всегда ответное предложение развернуть кластер с базами и отдельным web сервером. Но едва ли за всю мою практику наберётся десяток случаев, когда требовался именно дедик, один случай, когда нужен был очень мощный дедик, чтобы держать овер 1к онлайна и один случай когда в силу специфики системы и необходимости её регулярного обновления, пришлось танцевать с бубном и строить отказоустойчивую площадку. Во всех остальных случаях практически всегда удается найти баланс между стоимостью площадки, функционалом и набором используемых технологий. Не одним mysql мир живёт вобщем)))

Лично я, не вижу смысла в таком вопросе, так как у меня сервера с более слабыми параметрами спокойно отрабатывают до 40-50к pageview в день с огромным запасом ресурса и сотней онлайна в пике.

20к товаров в вашем случае должны ходить строем как дети в школу на дефолтных настойках. Комплексное решение вашего вопроса полдня делов. Но в ближайшую неделю ничем не смогу помочь.

Нитро, сессии, тупые запросы, много запросов, паразитные боты, некорректный роботс, динамические фиды, неправильная работа с кешем, права на папки, ошибки в логике модулей, внешние обращения, много изображений в одной папке, всякого рода у компрессоры на "на лету". Это только малая часть того что бывает. Ни один htop, atop, mytop никогда не покажет всех возможных проблем. Только пошаговое профилирование и изучение логов.

Точно так же. Если потенциальный покупатель возрасте до 35, все ровно и линейно. Если миллиенналы - то перекос в мобайл. Если бабушки, дедушки - то это телефонные звонки.

Да хоть их 90% будет мобайл, в твоей тематике все равно конверсии будут с декстопа. Так как возрастная категория специфическая потенциальных клиентов, которая не шибко обучена с мобилы вводить 100500 полей. А большая половина не помнит своего e-mail.

В силу некоторых обстоятельств. Буду в златоглавой. Есть два часа свободного времени и место для meetup. С 15:00 по 17:00по Москве в районе Курского вокзала. Желающие конструктивно пообщаться, набить мне рожу, заказать оптимизацию пишите в личку. Цена билета 2000 рублей.

А я наблюдал сервера которые лежали после ваших настроек. Это ужас и кошмар. Если вдруг вы захотите возразить. То готов всегда доказать свои слова но при участии независимого жюри и с большими ставками. Крайне не рекомендую обращаться к данному исполнителю. Берёт деньги за воздух.