RGB

Добрый день, уточните в личку с какого логина и где покупали шаблон, т.к. вашего логина в списке покупателей я не вижу

Я не подскажу конкретных решений, потому что они по определению не могут быть универсальными, у всех разные требования к таким задачам и разная организация процессов. Шаблон тут в любом случае никакой роли не играет и с ним будет работать любой такой модуль

@Panda21 Доброго, вам уже в целом ответили, могу добавить разве что пример простого готового решения для загрузки товаров, в случае с экселем это модуль

Это будет проще всего, если вам это нужно - в настройках шаблона во вкладке Общее есть поле ввода пользовательских стилей, добавьте туда нужные вам правила для селектора #tab-description { ... }

Доброго, к сожалению, у меня совсем нет свободного времени, поэтому я не занимаюсь индивидуальным переделыванием шаблона. Насчет шрифта - в описаниях товаров вы можете прямо в визуальном редакторе менять шрифт и размер, независимо от шаблона

Добрый день, при обновлении шаблона модификаторы обновили? Они должны быть версии 2.7.3 и их кеш, естественно, должен быть обновлен. Если обновление шаблона выполнили корректно, то проверьте лог ошибок модификаторов, возможно что-то помешало модификаторам шаблона добавить код в контроллер футера.

Я неоднократно писал в теме, да и выше vvo описал алгоритм как осуществляются любые правки стилей шаблона. Если у вас это вызывает сложности, то лучше обратитесь к специалисту, тем более, что у вас это не единственный вопрос и не единственное пожелание по изменению внешнего вида шаблона, а значит нужно собрать все пожелания воедино, написать полноценное ТЗ, обозначить бюджет и отправиться в раздел услуг: https://opencartforum.com/forum/25-дизайн-верстка-и-шаблоны/ В рамках техподдержки, как вы понимаете, у меня нет ни времени, ни возможности заниматься индивидуальной правкой стилей магазинов всех его пользователей, а работу я не ищу

@aaasss На среднем и большом экране (от 1600рх шириной) у вас выводится 4 товара в строку: Если боковая колонка не используется, то будет выводиться и 5, все зависит от свободного места

@sadar4ik Пожалуйста, напишите в ЛС с какого логина и на какой домен покупалась лицензия шаблона, т.к. вашего логина в списке покупателей я не вижу

Под елочку добавились п.12-13 о необходимости документации и лога разработки

У меня давно в голове назревала идея создать некое руководство с лучшими практиками и примерами того, как нужно и как не нужно делать при разработке шаблонов. Никакой саморекламы тут не будет, я адекватно воспринимаю критику и никогда не считал свои шаблоны (особенно первый – кто знает, тот поймет ) эталонными с точки зрения разработчика, так что аргументированная критика только приветствуется. Многие разработчики и фрилансеры называют лучшим шаблоном – default и в целом негативно относятся к коллегам-«шаблонописателям», на то есть немало причин, которые мы тут и обсудим. Для удобства восприятия информации дальнейшее изложение будет структурировано по пунктам, от более общих понятий к более частным. 1. Не воруйте чужие решения Как ни странно, даже среди известных разработчиков шаблонов были случаи воровства чужих решений: от заимствования целых модулей (например, фильтров) до более скрытого использования чужого кода, причем порой без понимания его сути. Думаю, всем очевидно, что это – плохо, причем плохо не только с моральной или этической точки зрения, но и с точки зрения атмосферы в самом сообществе в целом (а еще про вас напишет Yoda). Одно дело, когда код шифруется от пиратов, но когда разработчику приходится скрывать свой код от коллег, т.к. он понимает, что его могут просто украсть – это никоим образом не способствует ни сплочению сообщества, ни доверию к разработчикам в целом. 2. Не шифруйте все подряд Очевидный совет, который относится и к разработчикам модулей. Да, я знаю, что есть пираты (мне ли не знать этого?), с которыми вы так боретесь, но зачем кубить все? Каким образом стороннему разработчику потом разбираться в вашем коде? Каким образом пользователю внести свои индивидуальные доработки, если у вас закодированы и модель, и контроллер? А может быть в зашифрованном коде скрываются не только авторские решения, но и позаимствованные у коллег? 3. Не бойтесь пиратов По моему опыту те пользователи шаблонов, что стабильно используют взломанные версии с вареза, никогда ничего у вас не купят, это просто не их путь. По этой же причине малоэффективно тратить время и силы на пуленепробиваемую антипиратскую защиту шаблона – если даже у вас получится сделать что-то подобное и шаблон чудом не будет взломан, то этот факт вовсе не заставит сотню пользователей вареза пойти к вам его покупать, им гораздо проще взять любой другой пиратский шаблон, чем тратить деньги на ваш. Идея в том, что пользователь вареза изначально не настроен на покупку в принципе. Тот небольшой процент, которым кровь из носу нужен именно ваш шаблон (к примеру, нечистоплотные вебмастера, которым заказчик говорит «хочу») в случае отсутствия этого шаблона на варезе будут изо всех сил отговаривать заказчика от его выбора, поскольку это их хлеб. А абсолютно уникальных шаблонов уже просто не существует, в отличии от некоторых узкоспециализированных модулей. Также не стоит забывать о том, что есть определенная категория пользователей, которые любят тестировать дополнения с вареза, а уже потом их покупают, поэтому если у вас не предполагается тестовой версии шаблона – это еще одна причина не бояться пиратов, а воспринимать их как один из своеобразных рекламных каналов. 4. Не демпингуйте Если ваш шаблон плохо покупают – причина вовсе не обязательно связана с его ценой. Если ваши конкуренты продают похожие шаблоны за 3000, а вы выложите свой за 1000 – вы не получите в 3 раза больше покупателей, а получите покупателей в 3 раза более жадных и вредных. 5. Следите за чистотой кода Еще один очевидный совет, которым многие пренебрегают – все мы знаем, какое «удовольствие» разбирать чужой код. Порой читабельность кода не особо вырастает даже когда он не зашифрован, причем речь не только о коде как таковом, но и о верстке, скриптах и стилях. Если в самом опенкарте полностью избежать спагетти-кода (и не создать проблем с совместимостью) не получится при всем желании, то это вовсе не значит, что стоит пускаться во все тяжкие и запихивать $this->config->get в tpl-файлы (знаю-знаю, у меня в 1-м шаблоне именно так все и сделано и мне до сих пор стыдно) или делать множественные sql-запросы в контроллерах. Если вы не знаете, что и как сделать правильно – установите на локалку девственно чистый опенкарт и изучайте его структуру и его файлы, он сам по себе как документация (которой нет). 6. Забудьте о «разработке через страдания» Если вы хотите сделать толковый шаблон, то забудьте о принципе «Разработка через страдания», который звучит так: сначала сделай, чтобы было, затем — чтобы было красиво, затем — чтобы было быстро. Он совершенно неприменим к шаблонам. У вас все должно быть по возможности быстро, красиво и продумано до мелочей с самой первой версии, поскольку иначе ваш продукт просто не заметят и не оценят покупатели, а потом будет уже поздно. Даже если у вас горят все сроки по возврату кредита/ипотеки и вся надежда только на скорейший релиз шаблона – не выпускайте сырой «неупакованный» продукт, вы этим сделаете только хуже! Наполнение вашего демо не должно быть основано на стандартных унылых товарах и баннерах OpenCart, презентация шаблона не должна быть написана в последний вечер на коленке в ворде, а в самом шаблоне должны быть продуманы даже такие мелочи, как склонения числительных в таймере акций (никаких «Осталось: 13 дн 11 час 18 мин», вы шаблон делаете для живых людей, у которых в русском языке есть склонения, а не для роботов). На форуме представлена масса интересных и полезных дополнений, которые никогда не станут популярными по той простой причине, что их авторы – в первую очередь программисты, они не думают про упаковку своего продукта и считают простыню голого текста в описании дополнения презентацией. Они не думают о том, чтобы тратить время на «вылизывание» своего продукта и продумывание всех мелочей. Выражение «pixel-perfect» воспринимаются ими как что-то ужасно долгое и ненужное, но это совершенно не так, по крайней мере в случае с шаблонами – дьявол часто кроется именно в деталях. Если у вас однотипные элементы имеют разную высоту, абзацы выравниваются с произвольными отступами, а иконка в круглой рамке выводится не по центру, а смещена вниз – уделите этому свое время. Разумеется, все должно быть в меру, а лучшее – враг хорошего, поэтому маниакальным перфекционизмом заниматься тоже не стоит, важнейший навык в этом плане – найти золотую середину между скоростью и качеством работы. 7. Не превращайте шаблон в сборку Изначально задачи шаблонов заключались в обеспечении привлекательной «внешности» магазина, а функциональность обеспечивалась модулями. Но со временем началась своеобразная инфляция возможностей шаблонов, каждый новый старался превзойти предшественника по количеству настроек и модулей, входящих в комплект. Сейчас все знают, что получилось в итоге – монструозные сборки (это уже не шаблоны) со встроенными фильтрами, блогами, упрощенными оформлениями заказов, десятком плагинов фотогалерей и сотней комплектного модульного барахла, большую часть которого пользователь никогда не будет включать. Я прекрасно понимаю шаблонописателей, которые пошли по этому пути, да и сам не без греха, хоть и старался не перегружать шаблон лишней функциональностью. Почему же так произошло? Да потому что сложно «продать» средненький шаблончик, когда через дорогу продается такой же, но с фильтром и тележкой модулей в комплекте. Правильный ли это путь? Конечно нет, поскольку понятие шаблона смешивается с понятием сборки, от чего страдают абсолютно все: Пользователи получают неповоротливые громоздкие решения все-в-одном, чрезмерно сложные в целом и слабые по своим отдельным компонентам, в сравнении со специализированными модулями (смеха ради посмотрите возможности комплектного фильтра, входящего в состав какого-нибудь популярного шаблона, и модуля ocFilter), а постоянное наращивание таких решений у конкурентов вызывает у пользователя ложное предположение, что это нормальная практика – когда в шаблон впихивается модуль фильтра-блога-кешировщика и прочие несвязанные вещи Разработчики модулей теряют потенциальных клиентов, поскольку пользователю шаблона порой легче мучиться со встроенным в шаблон решением, чем искать нормальную отдельную альтернативу, которую к тому же придется адаптировать под шаблон Разработчики шаблонов вместо работы над внешним видом шаблона вынуждены постоянно наращивать его функциональность, стараясь угнаться за конкурентами, что доходит до абсурда и встраивания низкокачественных (а порой и вовсе чужих) решений, лишь бы не отстать в этой гонке 8. Не будьте эгоистом – ваш шаблон не единственный в мире Очень часто сталкиваюсь с ситуациями, когда пользователи решают сменить свой супер-шаблон на какой-то новый и их ждут любезно расставленные авторами грабли уже на моменте простого переключения в настройках на default, потому что заботливый разработчик и мысли не допускает, что его прекрасный супер-шаблон кто-либо когда-либо может захотеть сменить. Самая распространенная ситуация – когда многочисленная орава комплектных модулей супер-шаблона имеет файлы шаблонов исключительно для каталога самого супер-шаблона и не имеют своих адаптированных версий (или хотя бы копий!) для каталога дефолтного шаблона. В итоге при переключении на default все страницы магазина, где использовались модули супер-шаблона, перестают открываться, ведь опенкарт просто физически не может найти файлы шаблонов этих модулей. Несчастному пользователю придется вручную выискивать и отключать все модули супер-шаблона лишь для того, чтобы хотя бы вернутся к исходному состоянию системы со стандартным шаблоном. Вторая по распространенности ситуация – когда разработчику лень описать в документации процесс установки по шагам и все сводится к копированию всех файлов на хостинг (а модификаторов в /system) – уже догадались, что происходит при смене шаблона, когда пользователь понятия не имеет, что ему еще нужно по FTP ковыряться в системном каталоге и вручную удалять оттуда все модификаторы старого шаблона? И зачем в опенкарте сделан раздел Модификаторы с возможностью установки/удаления из админки? И напоследок уже довольно редкий сценарий – разработчик просто перезаписывает файлы шаблона default (и хорошо если только файлы шаблона, а не контроллеры или библиотеки). Думаю, объяснять последствия таких действий нет смысла, тут проще обрадовать пользователя, все сжечь и ставить движок с нуля. 9. Думайте о совместимости с другими дополнениями Бывает так, что у разработчика очень чешутся руки и он решает отказаться от устаревшего барахла, используемого опенкартом – убирает jquery, вырезает bootstrap или обновляет его с версии 3 на 4.5, убирает font awesome и т.д. Это все прекрасно и похвально, когда вы занимаетесь своим собственным магазином или выполняете работу для одного постоянного клиента и предупреждаете его о возможных рисках. Но если вы хотите сделать продукт, которым будете пользоваться не только вы и ваши друзья, подумайте на мгновение о том, с чем столкнется ваш пользователь при попытке установить какой-нибудь самый безобидный модуль, в котором используется сетка bootstrap (а это по определению абсолютно все модули, где идет вывод товаров), иконки font awesome (аналогично), а операции с DOM осуществляются через jquery. Конечно, можно следовать трендам и делать костыли для поддержки других дополнений (к примеру, убрать bootstrap и спустя пару десятков недовольных пользователей сделать опцию в админке «Подключить Bootstrap» – гениально же?), но не проще ли следовать стандартам? Поверьте, рядовому пользователю плевать на то, современный ли вы используете фреймворк и все ли у вас сверстано на флексах или на таблицах, ему важно, чтобы все работало как положено и сайт не разваливался при попытке поставить сторонний модуль. А сделать говно можно как на Bootstrap и jQuery, так и на каком-нибудь Foundation с ваниальным js или нодой. Это все лишь инструменты в руках разработчика, только вот успешность проекта зависит не от инструментов, а от навыков, с которыми эти инструменты используются. 10. Учите матчасть Один из последних пунктов по порядку, но не по важности – уделяйте внимание теории, причем я пишу не только про техническую составляющую, рассмотренную в п.5. Если вы делаете шаблон, то я бы очень советовал почитать Стива Круга, Филипа Котлера и других специалистов. Конечно, вы можете все делать и «по подобию» других шаблонов, ничего не понимая в дизайне, юзабилити и маркетинге, вдохновляясь на themeforest или на всяких дизайнерских CSSWinner и CSSDesignAwards, но есть один нюанс. Если проводить аналогии, то похожим образом на китайских ноунейм-фабриках делают дешевые велосипеды с тяжелой стальной рамой, неправильной геометрией, посадкой и «одноразовыми» компонентами. При этом со стороны их изделия действительно выглядят как велосипеды (ну а что там такого, два колеса, рама и руль), но если присмотреться поближе или проехаться на них, имея опыт эксплуатации нормальных моделей – все станет очевидно. Недаром есть термин BSO (Bike-Shaped Object, объект в форме велосипеда), которым и нарекают подобные продукты. Так и с шаблонами – если вы взялись их делать, стоит ли слепо копировать дизайн Юлмарта/Розетки в десятый раз? Почитайте пару книжек, поймите ошибки существующих решений и сделайте лучше! 11. Избегайте обращений к своему серверу Ваши пользователи не должны быть заложниками работоспособности вашего сервера лицензий. Любая зависимость ваших дополнений от вашего сервера – не просто неудобство и лишние тормоза (даже в относительно свежих шаблонах встречается ситуация с постоянным обращением к стороннему серверу для проверки лицензии), а и потенциально опасная уязвимость. Конечно, разработчик может возразить, что он – профессионал, доступ к его серверу есть только у него, а сам сервер невероятно надежен и полностью защищен. Пока петух не клюнет, все так говорят, к примеру, один печально известный «эксперт по php и OpenCart» @addist, пока из-за обращений к его серверу у пользователей не начались массовые проблемы с доступностью магазинов, а в его модулях не нашли критическую уязвимость. Или одна печально известная веб-студия N***** у которой модули по окончанию срока действия лицензии в определенных ситуациях просто «вешали» сайты клиентов. Не все разработчики понимают, что это не просто неудачные реализации и недоработки – это огромные убытки для работающего магазина, которые могут не только лишить владельца какой-то прибыли, но и привести даже к закрытию всего бизнеса, поэтому таких практик нужно избегать любой ценой. 12. Полная документация сэкономит время как вам, так и пользователям Думаю, тут и так все понятно из заголовка. Кто-то возразит, что пользователи – лентяи, поэтому документацию не читают, я с этим полностью согласен, но есть очень важный нюанс. Рано или поздно в общении с пользователями вы поймете, что чаще всего задаются одни и те же типовые вопросы, поэтому если вы их опишете в документации, то в будущем не будете тратить время, отвечая в -надцатый раз на вопрос о перекраске кнопок, а сможете дать ссылку на конкретный пункт в вашей документации. Это же касается любой из функций шаблона, поскольку при наличии даже базовой документации она со временем (при вашем участии, естественно) разрастется до такого состояния, когда будет отвечать на подавляющее большинство вопросов (или хотя бы задавать направление пользователям для самостоятельного поиска ответов). Если вы цените свое время, то сами к этом прийдете, но лучше это сделать раньше, а освободившееся время потратить на что-то более продуктивное. 13. Ведите лог разработки и обновлений Помимо очевидных удобств в плане повышения рабочей дисциплины и понимания изменений кода со временем, этот пункт имеет и другой важный и полезный эффект. Конечно, вы сможете показать своей маме/детям/внукам историю своей работы и эволюцию своего шаблона, но, как ни странно, вам это может пригодится в общении и с менее близкими людьми. Причем речь идет не только о хейтерах, но и об администрации площадки, где вы собираетесь выкладывать шаблон. Речь пойдет о плагиате и способах обоснованно избежать обвинений в нем. Причем я пишу не о плагиате, например, с многострадальной Розетки, удивительное сходство с которой можно без проблем увидеть даже в самых новых шаблонах. Я имею в виду другой плагиат – когда элементы более нового шаблона напоминают элементы другого, более старого шаблона. Пример из личного опыта – я уже третий год разрабатываю новый шаблон (назовем его A), в котором, среди прочих нововведений, используются градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо – фото айфонов. И вот неделю назад один разработчик выпускает свой новый шаблон B, в котором используются – угадали? – градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо фото айфонов в том числе Конечно, если через несколько месяцев будет релиз моего шаблона A, то некоторые персонажи могут усмотреть в этом плагиат с шаблона В другого разработчика. Но я веду историю разработки и в ней есть железные доказательства того, что, к примеру, градиенты на кнопках в моем новом шаблоне A были уже весной 2021-го года, когда шаблона В, естественно, еще не существовало и увидеть его будущий дизайн я физически никак не мог. Так вот, чтобы всего этого избежать и быть готовым в случае чего доказать свою правоту и авторство – у вас должна быть история разработки, в которой не только будет видно эволюцию шаблона, дизайн-макеты и прочее, но в ней также должны быть четкие (и независимые от вас) временные отметки по всем важным этапам разработки. В самом примитивном виде – снимок вашего тестового сервера из WebArchive или даже какие-нибудь скриншоты, пересланные в Telegram – такие данные не подделаешь, потому что там видно оригинальные даты, поэтому чем больше у вас таких данных – тем сильнее ваша позиция.

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

Данная запись содержит личный опыт и наблюдения, как собственные, так и клиентские, поэтому не претендую на истину в последней инстанции и с удовольствием ознакомлюсь с аргументированной критикой. Убедительная просьба в комментариях придерживаться уважительного тона общения, дабы сохранить запись в удобочитаемом виде для всех желающих. Содержание записи для многих будет очевидно и понятно, однако есть немалое количество людей, которые до сих пор верят определенным мифам о PageSpeed, поэтому цель всего этого чтива – развеять мифы, простым и понятным языком объяснить, что же это за звери такие – попугаи PageSpeed, на что они влияют и с чем их едят, а в будущем при очередном повторении все тех же вопросов – отсылать пользователей на эту запись. Миф №1: Оценка PageSpeed влияет на позиции в поисковиках Как можно убедиться в документации Google, баллы PageSpeed действительно показывают оценку скорости работы сайта, а скорость работы сайта, как говорится в блоге Google для вебмастеров, действительно является фактором ранжирования поисковой выдачи. Итого мы имеем два утверждения, которые нередко преподносятся следующим образом: Баллы PageSpeed = оценка скорости работы сайта Скорость работы сайта = фактор ранжирования поисковой выдачи И вот, ознакомившись с этими двумя утверждениями, нередко можно увидеть и третье утверждение, которое эксплуатируется некоторыми разработчиками и фрилансерами, занятыми «накруткой» баллов: Баллы PageSpeed = фактор ранжирования поисковой выдачи Это утверждение ошибочно по одной простой причине – «оценка скорости работы сайта» и «скорость работы сайта» – это не тождественные понятия, хоть они и взаимосвязаны, но лежат в совершенно разных плоскостях. Даже у такой могущественной корпорации, как Google, нет ни физической возможности, ни реальной необходимости регулярно прогонять все сайты из поисковой выдачи через PageSpeed, поэтому в ранжировании принимают участие вовсе не конкретные цифры из PageSpeed, а гораздо более объективные и реалистичные данные, к примеру, из пользовательских метрик, в частности, фактическая клиентская скорость загрузки сайта из Google Analytics. Почему сам Google не должен и не будет полагаться на цифры из PageSpeed для поискового ранжирования? Есть немало причин: Этими данными легко манипулировать (их можно накрутить до невероятных значений, подсовывая боту не тот контент, что получат пользователи) На эти данные значительно влияет география серверов (утрированный пример – представьте себе скорость загрузки магазина на серверах, работающих в Минске, для бота, заходящего из США) Оценка и многие рекомендации PageSpeed ориентированы в первую очередь на пользователей интернета в США и Канаде, где технологии значительно отличаются от наших реалий (к примеру, в плане распространения ADSL) Результаты оценки имеют слабую точность и повторяемость, поскольку зависят от доступности сети и ее состояния в момент проверки, из-за чего два оценивания подряд могут иметь разброс в десятки пунктов Данные PageSpeed изначально не предназначены для оценки того, «любит» ли Google ваш сайт, а лишь для того, чтобы обнаружить узкие места в работе сайта Из всего вышеперечисленного легко сделать вывод о том, что оценка PageSpeed не имеет и не может иметь прямого влияния на позиции в поисковой выдаче, однако не спешите закрывать PageSpeed Insights и облегченно вздыхать – хоть у этой оценки и нет прямого влияния, это вовсе не значит, что красные циферки 17/42 можно игнорировать, поскольку стабильно плохие показатели (в красной зоне) сигнализируют о том, что с сайтом есть проблемы. Особенно если речь идет о крайне долгом отклике сервера и времени загрузки до взаимодействия – такие симптомы будут серьезно влиять и на поведенческие факторы, ведь никто не станет сидеть на вашем сайте минуту в ожидании его полной загрузки. Поэтому сильно проседающие показатели можно и нужно выводить до более-менее приемлемого уровня, ориентируясь на самостоятельные наблюдения и на те самые вышеупомянутые метрики, среди которых можно выделить процент отказов как один из индикаторов того, «нравится» ли посетителям ваш сайт. Если же вы переживаете из-за красной зоны, т.к. надеетесь, что поисковый трафик обеспечит вам основную часть продаж, то можно уже не переживать – с большой долей вероятности вы и так скоро закроетесь, потому что сегодня на одном только поисковом получится выехать лишь в очень узких, региональных и неконкурентных нишах. Это является еще одним аргументом в пользу того, что не стоит гнаться за оценкой 99/100, лучше направить эти ресурсы на более важные вещи – на рекламу или контент. Миф №2: PageSpeed показывает скорость работы шаблонов Так уж сложилось, что мне знакома ситуация с шаблонами, поскольку нередко ко мне обращаются с подобными вопросами о том, какой шаблон «быстрее», а в качестве аргументов рассматриваются именно цифры PageSpeed из демо-сайтов шаблонов. При этом данный миф активно эксплуатируется некоторыми авторами шаблонов, которые указывают в роли преимуществ шаблона его скорость работы и ссылаются при этом на конкретные цифры PageSpeed. Тут надо напомнить немного теории. На формирование итоговой оценки PageSpeed влияет множество факторов, значительная часть которых вообще не связаны с шаблонами, а зависят исключительно от настроек сервера и его времени отклика, наличия кеширования, оптимизации графики сайта и прочих технических особенностей. В частности, среди ключевых метрик рассматриваются три важнейшие: Отрисовка крупного контента (Largest Contentful Paint, LCP) - время, за которое браузер отрисовывает самый крупный видимый элемент в области просмотра. Отсчет начинается с того момента, когда пользователь запрашивает URL. Самым крупным элементом контента обычно является изображение или видео, но это также может быть объемный блочный элемент с текстом. Этот показатель важен, так как появление первых элементов на экране говорит посетителю сайта о том, что URL загружается. Первая задержка ввода (First Input Delay, FID) - время между первым взаимодействием пользователя со страницей (нажатием на ссылку, кнопку и т. д.) и ответом браузера. Учитывается нажатие на любой интерактивный элемент. Этот показатель позволяет оценивать эффективность страницы, на которой пользователи могут предпринять какие-либо действия, и определяет, с какой скоростью реагируют интерактивные элементы на ней. Совокупное смещение макета (Cumulative Layout Shift, CLS) - показатель того, насколько элементы на странице смещаются во время ее загрузки. Значения показателя находятся в диапазоне от 0 (без смещения) до 1 (максимальное смещение). Этот показатель важен, поскольку смещение элементов страницы при загрузке плохо влияет на удобство использования сайта. Даже если не углубляться в детали каждой из метрик, достаточно рассмотреть первую - LCP (или похожую по сути FCP - First Contentful Paint), на значение которой влияют следующие важнейшие факторы, согласно документации: Медленное время отклика сервера Ресурсы JavaScript и CSS, блокирующие отображение Время загрузки ресурсов Рендеринг на стороне клиента Как видите, сразу на первом же месте идет то, что обычно никак не контролируется шаблоном и зависит в первую очередь не от него, а от того, быстрый ли у вас сервер. Аналогичная ситуация будет и со временем загрузки ресурсов (хотя «продвинутые» шаблоны могут плодить их количество) и множеством других пунктов, поэтому если вы попросите у авторов шаблонов, хвастающих высокой оценкой PageSpeed, хотя бы 5 примеров реально работающих (не пустых) магазинов на их шаблонах и проверите их через PageSpeed – вы и близко не увидите тех красивых цифр, которые видите при проверке специально подготовленных и вылизанных демо-сайтов шаблонов. Можно ли в таком случае утверждать, что оценка демо-сайта шаблона не играет никакой роли при выборе шаблона? Лишь отчасти, ведь хотя эта оценка и показывает в первую очередь уровень подготовленности демо-сайта, вместе с тем она позволяет проверить и те факторы, которые все же зависят от шаблонов, например вышеупомянутый FID (Первая задержка ввода), повысить который, согласно документации, предлагается следующим образом: Уменьшить влияние стороннего кода – чем больше всякого «мусора» в виде скриптов и плагинов тянет шаблон с собой, тем хуже Сократить время выполнения JavaScript – на первый взгляд красивая и плавная JS-анимация с выдвигающимися товарами запросто может стоить нескольких секунд проигрыша Минимизировать работу основного потока – чем больше стилей, скриптов и захламленности, тем больше уйдет времени на анализ, компиляцию и выполнение всего этого добра Минимизировать количество запросов и размеры передаваемых данных Также немаловажно будет обращать внимание на следующие факторы: Размер структуры DOM – если рассматривать два гипотетических шаблона, у которых выводится одинаковое кол-во товаров в категории, то чем меньшей будет структура DOM, тем легче будет верстка шаблона Размер кода CSS – чем меньше вес и легче правила, тем лучше Размер кода JS – чем меньше вес и сложность в выполнении, тем лучше и быстрее все будет отрабатывать Разумеется, это не все факторы, на которые стоит обращать внимание, но цель рассмотрения данного мифа не в том, чтобы научить выбирать шаблоны, а в том, чтобы показать сомнительную целесообразность оценивания и сравнения шаблонов по оценке PageSpeed. Важность метрики CLS (Совокупное смещение макета) в плане юзабилити можно хорошо продемонстрировать следующим примером: При этом оценивающие инструменты вроде того же PageSpeed и Lighthouse подходят к вопросу измерения этой метрики очень формально, являясь автоматизированными инструментами, не понимающими контекста измерений и не знающими, по каким сценариям используется ваш интерфейс. Например, нередко эта метрика показывает плохие результаты из-за того, что определенные блоки инициализируются с помощью скриптов Javascript и могут быть не видны до момента инициализации. Самый распространенный пример – слайдшоу или карусели, на практике «внезапное» появление таких блоков выглядит следующим образом (обратите внимание на блок карусели дополнительных фото товара справа вверху): Можно ли от этого избавиться ради получения более низкого показателя CLS? Конечно, есть разные способы (от довольно простого и «глупого» принудительного указания рассчитанной высоты этого блока, чтобы на его месте до инициализации карусели выводилась пустота, до более серьезных и продуманных способов с выводом статичных миниатюр дополнительных фото, визуально идентичных таковым в инициализированной карусели), однако практической ценности у этого будет очень мало, кроме выигрыша «попугаев» этой метрики, да и то не факт. Улучшится ли UX (user experience, опыт взаимодействия пользователя) на сайте после этих действий? Нисколько, т.к. все эти скрипты, вызывающие смещения в макете, грузятся сразу со страницей, поэтому пользователь до их загрузки все равно ничего с сайтом не сделает и не сможет сделать, даже если поставить заглушки вместо неинициализированных блоков каруселей – заглушки будут нефункциональными до момента инициализации самих каруселей, а значит ими все равно невозможно будет пользоваться. Возможна ли ситуация, когда пользователь захочет нажать на какую-то из кнопок или ссылок под неинициализированным блоком карусели и промахнется из-за смещения блоков, последовавшего после инициализации карусели? В теории да, но на практике такая ситуация крайне маловероятна, поскольку чтобы нажать на кнопку покупки товара или на какую-то из информационных ссылок, их нужно как минимум успеть увидеть и прочесть. Конкретно в вышеприведенном примере даже при использовании медленного мобильного 3G-интернета основное фото товара загружается намного дольше, чем инициализируется карусель и подгружаются ее дополнительные фото (потому что при весе основного оптимизированного фото в 15.5 кБ дополнительные даже суммарно весят в 4 раза меньше), а кто будет нажимать кнопки покупки товара, не увидев его фото, не говоря про чтение описания и т.п.? Как видите, на практике результат оценки шаблона по такой метрике может быть низким даже тогда, когда никакого влияния на юзабилити эти измерения не оказывают, поскольку машинные алгоритмы физически не могут знать всех вышеуказанных нюансов и оценивают такие вещи исключительно с «машинной» точки зрения. Стоит ли из-за этого закрывать глаза на все случаи смещения макета? Конечно нет, по возможности это лучше исправлять, особенно если такие проблемы вызывают больше неудобств, чем в вышеуказанном случае (например, когда весь контент страницы дергается и съезжает вниз из-за загрузки большого фото). Миф №3: PageSpeed это зло До версии 5.0 инструмент PageSpeed сложно было назвать архиважным или очень информативным, но после того, как PageSpeed начал использовать Lighthouse, его оценка стала намного информативнее и объективнее, достаточно лишь относиться к ней со здоровой критичностью и видеть в ней не цель развития сайта, а ориентир – тот самый «Lighthouse» (в пер. с англ. - маяк), направление которого стоит учитывать, но не стоит принимать как единственно возможное. Если вы считаете, что все рекомендации PageSpeed выеденного яйца не стоят и никак не повлияют на поисковое ранжирование магазина, каждая страница которого грузится по 30 секунд, то в целом вы правы – ваши посетители убегут прочь с вашего сайта и забудут о нем как о страшном сне безо всякого участия и PageSpeed, и Google Однако если вы думаете, что достижение заветных цифр 99/100 проложит вам дорогу в Топ-3 поисковой выдачи по всем ВЧ-запросам, то вам стоит сразу написать это в письме Деду Морозу, ведь вы, скорее всего, все еще в него верите. Выводы для тех, кто читает только заголовки 1. Я не призываю и никогда не призывал "забить" на оценку PageSpeed 2. Оценка PageSpeed (абстрактные баллы 0..100) и метрики, на которых основана оценка PageSpeed (конкретные данные FCP, SI, LCP, TTI, TBT и CLS) – не одно и то же! 3. Оценка PageSpeed не является точным индикатором сама по себе, потому что не несет никакой конкретной информации, в отличии от метрик, на которых основана оценка PageSpeed (вышеупомянутые FCP, SI, LCP, TTI, TBT и CLS) Почему так? Распишу подробнее на примере из комментариев: 4. С умом улучшая метрики, на которых основана оценка PageSpeed, вы, естетственно, улучшаете и саму оценку PageSpeed Ключевое слово - "с умом", т.е. понимая за что именно отвечает каждая из метрик и каким образом ее правильно улучшать. Слепое выполнение всех рекомендаций без понимания их сути (например, назначение абсолютно всем изображениям атрибута loading="lazy") принесет больше вреда, чем пользы, хоть и может реально улучшить итоговую оценку! 5. Даже вывод всех метрик, на которых основана оценка PageSpeed, в зеленую зону - не сыграет большой роли в ранжировании вашего сайта и не может гарантировать высокие позиции в поиске При этом фактором ранжирования (одним из множества) является вовсе не оценка PageSpeed (абстрактные баллы 0..100), а данные метрик (вышеупомянутые FCP, SI, LCP, TTI, TBT и CLS), на которых эта оценка основана и которые собираются с помощью разных механизмов отслеживания пользовательского взаимодействия. Еще раз - поисковые системы не гоняют и физически не могут прогонять все сайты в поисковой выдаче через PageSpeed для их оценивания! 6. Оценка PageSpeed косвенно показывает то, насколько грамотно сделан шаблон, но она не может объективно показывать его «скорость», потому что зависит от массы факторов, никак не связанных с шаблонами (скорость ответа сервера, наличие кеширования и тому подобное). 7. Улучшать удобство и скорость работы можно и нужно независимо от оценки PageSpeed. UPD (20.12.2021): Запись актуализирована, убраны устаревшие скриншоты, а также добавлены выводы для тех, у кого сложности с чтением и пониманием. UPD (25.12.2021): Выводы дополнены информацией из комментариев.

Прежде, чем писать новые комментарии, убедительная просьба ко всем "несогласным" - пожалуйста, внимательно прочитайте следующее: 1. Я не призываю и никогда не призывал "забить" на оценку PageSpeed 2. Оценка PageSpeed (абстрактные баллы 0..100) и метрики, на которых основана оценка PageSpeed (конкретные данные FCP, SI, LCP, TTI, TBT и CLS) – не одно и то же! 3. Оценка PageSpeed не является точным индикатором сама по себе, потому что не несет никакой конкретной информации, в отличии от метрик, на которых основана оценка PageSpeed (вышеупомянутые FCP, SI, LCP, TTI, TBT и CLS) Почему так? Распишу подробнее пример выше: 4. С умом улучшая метрики, на которых основана оценка PageSpeed, вы, естетственно, улучшаете и саму оценку PageSpeed Ключевое слово - "с умом", т.е. понимая за что именно отвечает каждая из метрик и каким образом ее правильно улучшать. Слепое выполнение всех рекомендаций без понимания их сути (например, назначение абсолютно всем изображениям атрибута loading="lazy") принесет больше вреда, чем пользы, хоть и может реально улучшить итоговую оценку! 5. Даже вывод всех метрик, на которых основана оценка PageSpeed, в зеленую зону - не сыграет большой роли в ранжировании вашего сайта и не может гарантировать высокие позиции в поиске

И где же вы здесь увидели приписанный мне призыв? Вы понимаете, что такое метрики CWV и чем они отличаются от попугаев PageSpeed? Если понимаете, то к чему перекручиваете мои слова? Если не понимаете, то перечитайте еще раз этот абзац: Опять же, где я сказал, что пейджспидом нельзя и какие еще левые сервисы? Зачем вы опять перекручиваете мои слова и приписываете мне то, чего я никогда не заявлял? И кто после этого демагог?

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

Вы же опять себе противоречите - сама оценка PageSpeed опирается в значительной степени на те самые CWV, на которые вы предлагаете не смотреть, а брать во внимание исключительно попугаев PageSpeed. Для большей наглядности и понимания того, насколько сильно (и что конкретно) влияет на итоговую оценку по конкретным метрикам, какие у них пропорции (выше @MaxD уже это расписал) - советую посмотреть сюда: https://googlechrome.github.io/lighthouse/scorecalc/ Информация о том, что на сайте CLS, скажем, 0.5, а FCP больше 3 секунд - позволяет понять в чем проблема и как ее решать, потому что является конкретным индикатором проблем на сайте, на который и следует смотреть в первую очередь для исправления положения. А информация о том, что на сайте 60 попугаев из 100 - это информация "для домохозяйки", т.е. ни о чем, эти 60 попугаев могут появиться вследствие как высокого значения CLS, так и вследствие "долгого" TBT или просадки любой другой метрики.

У "меня" как раз такие не сферические, а вполне конкретные, четко обозначенные и описанные Web Vitals метрики - LCP, FID и CLS. Напомню, хорошие результаты - это когда LCP до 2.5 сек, FID до 0.1 сек, а CLS - до 0.1. Как эти цифры считают, на чем они основаны, как их измерять - все это описано и всем известно. А вот вы предлагаете смотреть именно на абстрактных сферических попугаев в вакууме - обобщенную и упрощенную оценку удобства и скорости в виде пары цифр от 0 до 100. Это две большие разницы!

Забавно, что вы в одном сообщении написали два взаимоисключающих тезиса Как гугл может ориентироваться на "циферки пэйджспид", не гоняя сайты через Lighthouse, данные с которого и позволяют получать циферки пэйджспид? Или вы тоже не понимаете разницу между, к примеру, абстрактными попугаями 80/90 (циферки пэйджспид, на которые все смотрят) и конкретными значениями какого-нибудь LCP в 1.99 сек (на который как раз таки и нужно смотреть в первую очередь)? А может это вы прекрасно поняли смысл моих слов, но из упрямства продолжаете спорить? Когда человек прибегает к аналогиям - значит нормальных аргументов у него уже нет, но есть желание поупражняться в софистике.

Опять двадцать пять Фактором ранжирования (одним из) является скорость работы сайта и его удобство, а не циферки PageSpeed. Вы скажете - так циферки же как раз и показывают скорость и удобство, разве не так? Так-то оно так, но не на попугаев же гуглу ориентироваться и не гонять же миллионы сайтов из выдачи через Lighthouse, чтобы определять их скорость и удобство?

Эта запись появилась на свет после -надцатого обращения кого-то из пользователей моего шаблона с вопросом в духе: Очень многие, по крайней мере раньше, реально воспринимали оценку пейджспида как сакральную цель, для достижения максимума которой (после чего гугл сразу отдаст топ-1) все средства хороши. Точно так же многие решили, что если прогонять через пейджспид демку шаблона - получим некую абстрактную "скорость" шаблона, гарантированную всем его пользователям - я с этим бредом, естественно, не согласен и постарался аргументированно это изложить в записи. К моему удивлению, смысл записи почему-то прекрасно поняли только chukcha, spectre и optimlab, а большинство остальных комментаторов (и вы в том числе) усмотрели в записи смысл полностью противоположный тому, который я в нее вложил. Возможно, тому виной чрезмерно длинное и запутанное изложение, каюсь, надо перечитать Ильяхова

Где вы это увидели? Я пытаюсь доказать очевидный тезис, что в контексте скорости/удобства важна именно фактическая скорость/удобство, а не то, 90 у вас попугаев PageSpeed или 95. Все смешалось! Я писал про циферки PageSpeed от 0 до 100, а не циферки Core Web Vitals, у последних вообще нет такого абстрактного деления в виде шкалы от нуля до ста, там играет роль либо время - секунды (для LCP до 2.5 сек, для FID до 0.1 сек), либо результат умножения долей воздействияи расстояния в случае CLS (до 0.1).

Совершенно верно, а кто с этим спорит? Показатели-то коррелируют и итоговая оценка зависит от них в том числе, с этим тоже никто не спорит и не опровергает, но поисковая выдача основывается на чем - на абстрактной оценке (циферках PageSpeed) или все же на конкретных показателях скорости/удобства? Вы же понимаете разницу между этими на первый взгляд похожими сущностями? Ну привет! По preload мы с тобой спорили и ни к какому выводу не пришли, потому что я впустую потратил время в попытках показать тебе отсутствие разницы в оценках, извиняться тут за что, за потраченное впустую время? Никакой блог я не удалял, не пиши глупостей, обсуждение того спора было и есть в курилке, тебя в нем я специально не упоминал, но если хочешь найти тему - напиши в личку. Избыточные теги Preload убраны по причине никак не связанной с тобой, а потому что от них не было ни вреда, ни пользы (что тебе в курилке, к слову, писал не только я) - поэтому, чтобы не плодить кашу ненужного кода, он был почищен.

Любой желающий может посмотреть как я "не улучшаю" шаблон в логе его обновлений, которых на сегодня вышло 25 штук https://2.mnmkr.com/documentation/#changelog Речь идет в первую очередь о том, что какие-то глобальные вещи в шаблоне, который установлен у массы пользователей, менять очень проблематично и трудозатратно, поскольку любые кардинальные изменения сломают и существующие адаптации, и индивидуальные доработки пользователей. Поэтому то, что я сделал в 2016 и что сегодня сделал бы (и делаю) совершенно иначе - далеко не всегда целесообразно переделывать, если думать о последствиях глобальных изменений. Если бы вы сделали, выпустили, поддерживали и развивали хоть один собственный шаблон с хотя бы сотней пользователей (а не копировали существующие, как было в истории с @Medialine), то не задавали бы таких вопросов. Вы, конечно, можете возразить, что такой проблемы не было бы, если бы у вас была своя система обновлений, которая бы учитывала все подводные камни у всех пользователей и все бы делала сама без конфликтов и по одному щелчку мышкой - ну да, если бы да кабы. А почему вы не спросите, к примеру, почему на демо товаров не миллион, у них фото весят не по 100 мб, нет онлайн-чата, аналитик, вебвизоров, фильтров с тысячью атрибутов и прочих радостей реального магазина? А ответ очень простой - это демо шаблона, а не реальный магазин. И я, в отличии от подавляющего большинства авторов шаблонов, честно об этом пишу в описании шаблона: Заметили, что вы сами же процитировали этот текст выше в своем первом сообщении?