sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
Немного информации для понимания по счетчикам. Предполагаю, что описание мало кто читает и еще меньше тех, кто его пытается понять. (Отсюда домысли и фантазии, не имеющие с реальностью никакой связи, особенно от тех, кто не понимает разницы между скриптом php и скриптом JavaScript) Только на это могу списать появившееся на пустом месте мнение о якобы отсутствующих (? ) счетчиках в процессе оптимизации. Счетчики (аналитика, метрика с вебвизором и т.п.) загрузятся в любом случае автоматически даже если пользователь бездействует. Оптимизация никуда не девает счетчики и никаким образом не изменяет код счетчиков и, тем более, не отменяет их действие. Это работает независимо от действий пользователя. В пояснении как работают отложенные скрипты четко указано: Реальные пользователи подтверждают четкую работу: Специально делали контроль в гугле и в режиме реального времени отслеживали пользователей через аналитику после оптимизации (ниже мультфильм - наблюдение в реальном времени сбора данных аналитикой ): -
без глубокого анализа сложно сказать в чем причина. Сам шаблон в демо-версии автора шаблона имеет существенно меньше узлов. 2500 и 4800 узлов против ваших 10 000 и 12 000+. Но тут может сказываться кол-во товаров - у вас их больше, поэтому ваше предположение насчет шаблона может быть верным. У вас картинок раза в три больше чем в демке шаблона, вот и узлов больше в итоге. Повлиять без пересборки магазина на это очень сложно или невозможно. Можно предположить, что какой-то модуль добавляет кучу лишних узлов к каждому товару. Тут только переделка магазина - частичная или полная, иного варианта уменьшить. Т.е. с учетом этого нужно понимать, что оптимизацией без серьезной переделки (а это долгая ручная работа) тут не обойтись если цель - подняться к 90+ с 3 баллов на старте. Либо смериться с тем, что можно достичь реального максимума, например, 50...70 при таком тяжелом DOM, но при скромном бюджете. Также не стоит забывать про отклик сервера в 2...7 секунд. При старом алгоритме гугла было оптимизировать проще. Я вам сделал на скорую руку оптимизацию когда новому алгоритму гугла всего две недели. На данный момент полного арсенала эффективных методов под новый алгоритм гугла пока нет. Разумеется, что нужно определенное время чтобы воплотить новые идеи в программе. Универсальные методы, безусловно, работают и сейчас. Но не на всех сайтах получается прямо взлететь с нуля до 90+. На некоторых и до 100 получается взлететь с 25. Все индивидуально. так я вам по каждому моменту старался делать разъяснение и сейчас тоже.
-
Не забывайте настраивать время жизни кеша для формата webp. Иначе гугл будет неодобрительно реагировать на это. Если у вас сервер (vds), то это обычно настраивается в конфиге nginx. Модуль по мере возможностей делает свой конфигурационный файл (.htaccess) для Апачи если у вас именно Апачи отвечает за вывод webp. На общем хостинге внесите в "статические файлы" формат webp наряду с jpg, png. Чтобы использовать кеширование webp в том числе, обычно вся статика кешируется браузером. Пожалуйста, не забывайте про этот важный момент! Вот так не должно быть, иначе гугл занизит оценку в итоге: Вы можете увидеть, что кеширование работает для вашего webp если откроете панель инструментов в браузере. ctrl+shift+I. В примере видно, что кеширование задано длиною в месяц для webp.
-
я обратил внимание на огромное кол-во изображений в самом начале, и про раздудый DOM писал сразу как отягчающие факторы, на которые я повлиять не могу. Только слепой не увидит это или тот, кто специально делает вид, что не видит. Оценка гугла сейчас падает с увеличением времени отклика. Более 7 секунд. Ну какие 90 или хотя бы 80 баллов при этом? Никакой оплаты заказчик не делал, более того, никаких обязательств передо мною у него нет, т.е. платить не нужно. Заказчику был показан результат, а далее он волен сам решать как быть. Где тут в этой логической цепочке хоть что-то может ущемить заказчика? Загрузка страницы Категория точно также без оптимизации те же самые 5 баллов (плюс/минус 2 балла). После прибавка около + 40 баллов. Все в точности как обещано - несколько десятков баллов в плюс. Причем я спрашивал заказчика нужно ли мне стараться чтобы поднять до 60 или 70, что в принципе возможно. Заказчик явно дал понять, что его никак не устроит результат подъема с 3-6 баллов до 60-70 и оплачивать он не будет работу. Извините, господа, но если вам уже подъем на +60 - это не результат, за который можно заплатить 3000 р, то ищите иные варианты.
-
Я четко объяснил Петру, что будет прирост в несколько десятков баллов. Это и получилось в результате. И сразу честно предупредил, что на сайте есть моменты, на которые я не могу повлиять, я их перечислил. В том числе назвал узким местом огромный DOM в 10 000+...12 000 узлов. Все это было до начала работы. Но вы же не читали, а стали сразу орать, не так ли? И что в итоге имеем кроме вашей невнимательности, откровенной лжи и хамства?
-
а где ваши глаза? вы читали хоть один раз описание? Каким боком я имею отношение к серверной части? крупным текстом написано в описании: Специально отмечено, что серверные скрипты php не ускоряются. Есть список того, что будет сделано (здесь нет серверных скриптов и нет речи об оптимизации отклика сервера): Если вы не знаете, что скрипты JavaScript работают исключительно на стороне пользователя, т.е. в браузере, то повышайте свой уровень образования или спросите сперва у людей, которые в этом разбираются. Тон вы выбрали совершенно недостойный. Я с вами общаюсь, не переходя на личности. Я так понимаю, что извиняться вы не обучены? По-мужски говорить тоже не умеете, скрываетесь за интернет-анонимностью? Кто вы? Фейк-аккаунт или клон человека, который боится чтобы его имя было упомянуто на форуме?
-
только модуль pagespeed никак не влияет на скорость генерации страницы сервером. А речь была именно об этом. К тому же появляется фактор нестабильности из-за этого. Смотрите одно из моих сообщений выше. Я не делал настройки с учетом данного мода. Он может вызывать конфликт. Не стоит пытаться использовать сразу как можно больше ускорителей - хороших и разных одновременно. Кроме как к нестабильности это не приведет ни к чему хорошему. Давайте точки над "i" расставим? @pmshirshov , разве я вам обещал настройку и оптимизацию серверной части? Снижение отклика сервера? Оптимизацию изображений разве обещал? Кстати, насчет изображений. Optipng, jpegoptim будут в вашем случае как мертвому припарки. jpegoptim кроме вырезания ненужной информации из файлов ничего не умеет, сжатие не делает в полном смысле этого слова, для больших изображений толк практически на нуле. Optipng? Это только для png, да и эффективность тут на уровне 15% выигрыша. Но, повторюсь, тут даже не только в объеме дело, дело в большом кол-ве соединений, необходимых для загрузки изображений.
-
да это нормальное желание. только вы же понимаете, что у вас несколько узких мест, на которые я повлиять не могу только оптимизацией клиентской части? 1) отклик сервера 2) большое кол-во (600 !!!) картинок, к тому же неоптимизированных. Но тут важнее кол-во в данный момент, особенно с учетом протокола http 1.1.. 3) ... Вам же понятна аналогия с автомобилем? Отремонтировали движок, но оставили кривые диски и лысую резину. Далее тестируем скорость автомобиля и.... остаемся недовольны ремонтом движка? У вас именно так получается? Что конкретно не ясно вам из текста про узкие места? Или вы не считаете их узкими? Я вам сразу сказал, что если не убрать узкие места, то будут проблемы. Вы можете пояснить ваше желание при отклике сервера в 6 секунд, который от меня не зависит, получить высокую оценку гугла? Т.е. получается, вы предлагаете мастеру: вы движок то ремонтируйте, но лысую резину я менять не буду, на лысой тестировать будем? И если на лысой не поедет как надо, то будем считать ремонт двигателя неудачным? Я правильно вас понимаю?
-
а куда же оно денется если у вас изначально так заложено? У вас при отключенном JS,довольно большая часть контента вообще не отображается. У вас до выполнения JS стоят одни размеры для картинок, а потом уже - другие. Это не мой косяк, это у вас кривой lazy load работает. Или какой там у вас скрипт JS используется для этого. Ваш, а не мой. И вы хотите при таком перестроении страницы желать идеальной загрузки? Отчего вы не замечали эту проблему раньше? Вообще, интересно было бы посмотреть как можно ускорить загрузку 600 (!!!) картинок для главной. К чему вы делаете вид, что не знаете проблем с загрузкой изображений? У вас это узкое место, но вы упорно не понимаете почему не произошло оптимизации сервера и картинок? Вы еще при этом упорно желаете использовать древний тормозной протокол http 1.1, который для каждой (из 600 !!!) картинки создает новое соединение? Разве ранее я вам не писал об этом узком месте? Почему вы решили, что это (кол-во картинок) не должно никак сказываться на конечном результате? Почему бы вам просто не снизить их кол-во для главной?
-
вообще то все сообщения к вам на почту дублируются. если у вас какие-то проблемы с работой форума (личкой, почтой и т.п.), то это не ко мне. Давеча один из пользователей не мог скачать прикрепленный мною файл в личке. Так и написал мне: файл вижу, а скачать не могу. Не стоит на меня пытаться свалить еще и баги форума, а последнее время они есть, особенно после обновления. не путайте время генерации страницы сервером и общую скорость загрузки. серверную часть я вообще не видел. Доступов вы не давали. у вас отдача страницы колеблется в пределах 2...6 сек. Предполагаю, что кеширование запросов сервером БД у вас не работает, т.к. изначально на сервере это не настроено. Серверная часть - это отдельная тема. Мы занимались клиентской частью, а это программы (JavaScript) на стороне клиента, т.е. в браузере смартфона и т.п. Вы снова желаете ехать на лысой резине, отремонтировав движок и утверждая, что зря ремонтировали двигатель, но забывая про резину? Аналогия понятна применительно к серверной и клиентской части сайта? Отклик страницы гугл называет так как на скриншоте. Reduce initial server response time Уменьшить начальное время ответа сервера . гугл пишет: Сократите время ответа сервера для основного документа, поскольку от него зависят все остальные запросы. Я лишь на скорую руку сделал настройки на вашем сайте, при том, что вы сразу заявили, что платить не собираетесь. И я вам сказал, что это лишь результат в первом приближении. При желании можно было бы работать дальше, но у вас то его не было. И без снижения ответа сервера бессмысленно чего-то ждать большего. Я вам даже бесплатно предлагал показать ваши узкие места сервера (именно серверной части). Вы предложение не приняли. Скажите точно, вы ждали, что я вам снижу время ответа сервера при том, что у меня даже доступа к нему не было? Вы это на полном серьезе ставите мне в вину? Подробнее гугл предлагает читать здесь:
-
https://hi-optimizer.sitecreator.pro/ вот на этой странице есть карты яндекса, вставка ютюб и пр. Карта и ютюб-вставка будут тормозить страницу, хотя они вообще находятся внизу станицы. Вполне логично, что гугл предлагает оптимизировать эти блоки. Логично использовать для этой цели механизм lazy load, т.е. показывать карту тогда, когда пользователь доскроллил до нее. Аналогично и с ютюб-вставкой. Это именно оптимизация, которую реульно можно почувствовать, особенно при медленном интернете. Вот даже не думая о баллах гугла, но думая об удобстве пользователя. Это не "накрутка", это именно оптимизация. В полном соответствии с рекомендациями гугла. Есть также оптимизация шрифтов в полном соответствии с рекомендациями гугла. Страница будет отображена даже до загрузки ваших фирменных шрифтов со значками, текст будет отображен быстро. Это и есть оптимизация. То, что гугл называет также "удобством для пользователя". Даже безотносительно с тем как это оценит гугл это просто будет более удобно для пользователя. Модуль Hi-Optimizer умеет оптимизировать загрузку шрифтов, включая загрузку внешних шрифтов. Вы не считаете это полезным? Также как применение технологий lazy load для отображения карт, ютюб-вставок и различных виджетов? Это ваше право. Гугл считает полезными такие оптимизации и положительно их оценивает. За оптимизацию шрифтов может увеличить оценку на несколько баллов. В конце концов сайты делаются для людей. И если оптимизация загрузки шрифтов, карт, ютюб-вставок, виджетов и пр. делают страницу удобнее для людей, то что же в этом плохого? А если вам это не нужно, так и не используйте.
-
оценка - это выражение скорости в конкретных единицах. гугл решил измерять общую оценку скорости в баллах.
-
Вообще то гугл явно пишет на странице результатов https://developers.google.com/speed/pagespeed/insights про "оценку скорости загрузки". И этот термин гугл неоднократно использует в своих официальных документах. О чем вы пытаетесь спорить? Вы хотите сказать что гугл pagespeed оценивает в баллах что-то другое, а не скорость? А если просто прочитать документацию гугла? Или гугл в своей документации нас вводит в заблуждение? Или вы сами запутались, возможно? Так почему гугл везде употребляет термин "скорость"?
-
Тот же самый вопрос я мог бы вам задать. Если вы утверждаете, что оценка производительности гуглом не учитывается при ранжировании, то это лишь ваше мнение. впрочем, каждый сам вправе решать насколько ему важна оценка гугла и т.п. Как-то странно обсуждать моменты, которые всем давно известно и о которых гугл давно уже заявил. это перевод вот этого (Официальные новости о сканировании и индексации сайтов для индекса Google): Posted by Sowmya Subramanian, Director of Engineering for Search Ecosystem источник:
-
@brooks , все дело во внимательности или в ее отсутствии. Работа была сдана и принята вами ранее. Далее вы захотели улучшить результаты, но не прочитали предупреждение (в инструкции) насчет совместимости: Вопрос легко решился. Проблем не наблюдается. Про изначальную ошибку в вашем коду HTML я вам написал в приватной переписке. Исправлять ее или нет - дело ваше.
-
@optimlab , у меня есть блог, мы можем поговорить на эту тему сколько угодно и поделиться своими соображениями. Здесь же тема поддержки. К чему писать тексты, словно я призываю отключать или не ставить метрику? Вы или невнимательно читаете или не знаю что... Но вы пишите совершенно о другой ситуации. МЕтрика остается и никуда не девается. Ее запуск лишь откладывается, но не позже чем произойдет первое действие пользователя. В вебвизоре нет никакого смысла пока пользователь не сделал ни одного действия, т.к. нечего отслеживать в этом случае. к чему это? речи про отсутствие вообще не было ни разу. Смысл поднимать волну на тему, высосанную из пальца? Можно еще про шаманов и экстрасенсов поговорить... Специально с заказчиками изучали вопрос как влияет оптимизация счетчиков. Не удаление их полностью, как вы пишите, а оптимизация. После долгих наблюдений заказчик говорит, что все "ОК". И у пользователя всегда есть выбор вообще не использовать оптимизацию Метрики. Никто же не навязывает, но если на протяжении месяцев полный порядок с Метрикой, то, возможно, что пользователь может все же сделать выбор - использовать стандартную Метрику (и поставить ее прямо в <head>) или использовать оптимизированную. Сам код Метрики не меняется в любом случае. Код (JS) Метрики как ДО, так и после оптимизации загружается с Яндекса как обычно. В любом случае за использование того же вебвизора в Метрике гугл сильно снижает оценку, и в целом использование неоптимизированной Метрики может вылиться в падении оценки гугла на десятки баллов. Вот и думайте важно ли вам ранжирование гугла и его оценка как фактор этого ранжирования? Если пользователь хочет, то он может оставить Метрику на сайте в исходном виде и не оптимизировать ее. Но пользователь будет вынужден смириться с тем, что гугл накажет оценкой за использование Метрики. И никаким способом вы не заставите гугл пересмотреть его отношение к Метрике, ибо гугл считает, что такая Метрика (особенно с включенным вебвизором) - это зло для посетителей сайта. И все современные браузеры, включая Хром от гугла, считают, что пользователь имеет право защититься от отслеживания его действий, т.е. от счетчиков, поэтому достаточно поставить галочку чтобы сам браузер стал блокировать счетчики, включая Метрику и т.п. Никаких иных способов оптимизировать Метрику (без отключения, например, части ее функций вроде вебвизора и т.п.) кроме как перенести ее старт на время после выполнения, действительно, важных скриптов и загрузки важных файлов, не существует. У вас есть свое предложение как можно оптимизировать Метрику? Добро пожаловать в мой блог дабы не вести тут дискуссии, не относящиеся к поддержке. Тем более, что высказываемые точки зрения могут быть лишь предположениями, заблуждениями и т.п.
- 142 replies
-
- 2
-
-
- ускорение
- оптимизация
- (and 6 more)
-
Еще в тему о возможной неверной статистике. О возможном обмане поисковиков. Тут нужно сразу сказать, что оптимизация никак не изменяет код самой Метрики и с помощью оптимизации поэтому никак невозможен обман поисковика. Утверждение обратного будет, мягко говоря, лукавством. Есть так называемая накрутка по поведенческим факторам. Имитация переходов с поисковиков, которых не было. Да, за это поисковики могут наказать. Но только поведенческие факторы поисковики не отслеживают именно из вашего счетчика. Они отслеживаются прежде всего в самой поисковой системе, т.е. на страницах Яндекса и Гугла, именно там фиксируются клики, которые не могут быть подделаны. Небезызвестный Платон о возможности накрутки за счет ПФ писал: В случае оптимизированного счетчика той же Метрики максимум, что может произойти - это срабатывание счетчика с некоторым запаздыванием. Сам Яндекс рекомендует ставить счетчик в самом верху. Это хорошо для счетчика, но плохо для скорости сайта. Самый просто способ оптимизации - это перенос счетчика в самый низ. Что может случиться страшного в этом случае? Например, гипотетически какой-то JS, расположенный ранее Метрики, может работать долго и пользователь просто не дождется загрузки страницы, а просто закроет ее. Вот тогда Метрика не сработает поскольку просто не успеет загрузиться и вы не получите статистику о таком пользователе. Этого не случилось бы если бы Метрика была в самом вверху. Но нужна ли вам информация о таком пользователе в ущерб скорости сайта? Скорее всего это просто не целевой пользователь, а случайно кликнувший не туда. Разумеется, что за перенос Метрики в подвал сайта никаких санкций быть не может. Это просто сбор статистики для вас, не более. Вы же не пытаетесь передать в Яндекс поддельную информацию, код счетчика остается верным, более того код самого счетчика загружается с сайта Яндекса. Просто напросто загрузка данного кода Метрики происходит с меньшим приоритетом, т.е. после загрузки наиболее важных файлов, а не наоборот. Откладывается время старта Метрики, но никак не изменяется сама Метрика.
- 142 replies
-
- 2
-
-
- ускорение
- оптимизация
- (and 6 more)
-
Немного полезной информации для понимающих и думающих людей. Насчет счетчиков. Есть один важный момент, который очень сильно, и уже давно искажает статистику, собираемую различными счетчиками. Это всевозможные блокираторы рекламы вроде adBloock, AdGuard и т.д. Они просто напросто отключают счетчики на сайте. Более того, браузеры позволяют вам включать настройки против отслеживания, которые также блокируют счетчики Яндекса и Гугла. В режиме "Инкогнито" счетчики уже обычно блокируются по умолчанию. Поскольку с каждой страницы сайтов поток рекламы уже давно перешел все разумные пределы, то очень многие пользователи пользуются блокировкой рекламы. Скорее всего не ошибусь если скажу, что половина пользователей используют блокировщики ненужного контента. Блокировщики блокируют не только рекламу, но они же блокируют Метрику, Аналитику и прочие счетчики. Было бы наивно полагать, что поисковики об этом не знают. Поэтому сама идея наказывать сайт на "неправильный счетчик" выглядит довольно абсурдной с учетом данной информации. С учетом установленных блокираторов добрая половина данных либо вовсе не отправляется в Метрику, Аналитику, либо отправляется в кастрированном виде, например, с отключенным вебвизором потому, что блокиратор может снисходительно позволить один раз отправить какие-то данные, но не позволит делать это постоянно с отслеживанием движений пользователя. Учитывая все вышесказанное + отсутствие в принципе санкционных фильтров поисковиков за "неправильные счетчики" (официально) идея "пессимизации" за счетчик звучит совершенно надуманно, более того никто не знает таких примеров. Более того, у людей работают годами сайты, которые в своих счетчиках используют алгоритм их отключения показа для ботов, и такие сайты прекрасно себя чувствуют. Сам Яндекс довольно спокойно описывает ситуацию, когда JS Метрики не работает. В этом случае не вся информация в Яндекс поступает или вовсе не поступает. Будет ли Яндекс наказывать за то, что ему отправили не всю информацию? Думаю, что вы и сами понимаете, что это абсурд. Яндекс также пишет, что точность собираемых данных зависит от множества факторов и не может быть полностью достоверной. Тот же вебвизор, входящий в Метрику может глючить и давать неверные данные если не соблюдены определенные условия. Не вполне валидный HTML? Тут уже верное поведение вебвизора метрики будет под вопросом. Яндекс также вполне недвусмысленно предполагает ситуацию когда устаревший счетчик будет работать некорректно. Яндекс всего навсего рекомендует его устанавливать стандартно, т.е. с автообновлением. Но Яндекс ничего не имеет против нестандартных счетчиков. Также Яндекс считает совершенно штатной ситуацией когда Яндекс не может найти свой счетчик на странице. Поэтому любое беспокойство о санкциях за неправильный счетчик не имеют под собой оснований. Как говорится, учите мат. часть. Как бы там ни было, но Hi-Optimizer при верной настройке не лишает хозяина сайта нормального сбора статистики Метрикой, Аналитикой и т.п. Это тщательно проверялось на разных сайтах. Также вы всегда можете отказаться от оптимизации Метрики, Аналитики и т.п. в случае сомнений или просто нежелания их оптимизировать. Вообще, на сайте поддержки Яндекс-Метрики миллион вопросов о неверно работающей Метрике. Но вы там не найдете даже намека на возможные санкции за неверный счетчик. Ответы дают сотрудники Яндекса. Вы и сами можете задать в лоб вопрос "а что будет если ...?" Тема на Яндексе так и называется про "неработающую толком метрику". https://yandex.ru/blog/metrika-club/schetchik-yandeks-metrika-korrektno-ustanovlen-no-ne-rabotaet
- 142 replies
-
- 4
-
-
- ускорение
- оптимизация
- (and 6 more)
-
@pmshirshov , раз уж тут обсуждаем ваш сайт, то прошу заметить, что у вас изначально присутствует ошибка Метрики. Я не могу нести ответственность за двойную загрузку и инициализацию Метрики, а эта проблема присутствует у вас изначально. Как будет работать такая Метрика после оптимизации? Вероятно, что также, а именно "ДО" она уже работала неверно, поэтому тут без гарантий корректности, такие ситуации непредсказуемы - тут изначально ошибка содержится. Тут сам Яндекс не гарантирует нормальную работу Метрики в случае ее дубликатов на сайте. По-хорошему Метрику вам надо бы сперва оставить только одну. Со всей ответственностью могу сказать, что Hi-Optimizer не влияет на верный сбор данных Метрикой, но с оговоркой, что у вас изначально Метрика установлена верно. У вас это не так. Кстати, поскольку у вас Метрика изначально неверная и Яндекс на это вроде бы не реагирует, то можно предположить, что "пессимизация" за неверный счетчик - это не более чем фантазия. Встречаю постоянно сайты с Метриками, которые работают совершенно неверно, включая случаи установки метрик от других сайтов вообще, но Яндекс на это не реагирует в плане ранжирования, по крайней мере, нигде официально нет информации, что Яндекс мог бы наказывать за неправильный счетчик. По словам заказчика, у него и три разных метрики было. И ничего.... работало как-то. Заказчик не даст соврать. В общем заказчик знает о своей проблеме с Метрикой, сам ее решает, да и никаким боком эта проблема не связана с установкой Оптимизатора Hi-Optimizer. Есть актуальные факторы пессимизации Яндекса по официальным источникам, но среди этого списка нет наказания за неверный счетчик. Ошибка Метрики в исходном коде сайта еще до установки Hi-Optimizer: UPD: Оптимизация сделана в данный момент лишь в первом приближении на "автомате" без вникания в нюансы и без ручной корректировки. Чисто для того чтобы показать принцип и результат работы. В данный момент нельзя утверждать, что работа закончена. Кроме того заказчику предоставлена возможность устранить ошибки, которые присутствовали до начала оптимизации и были обнаружены уже в ее процессе. Разумеется, если будет мотивация, то работа может быть доведена до логического конца. Сейчас сделано чисто на "общественных началах" без всякой оплаты. В настоящее время могут производиться работы на сайте и коррекция кода, в том числе самим заказчиком. И я, и заказчик знаем, что на сайте в данный момент есть некоторые ошибки. Неправильная Метрика - одна из них. На одной из страниц hi-optimizer отключен специально, и отчетливо видно, что на этой странице работают две метрики, т.е. видно, что изначально нарушена работа счетчиков. Внимательный и желающий разобраться человек сразу бы мог предположить ошибку в "Метриках" в исходном коде. И при желании проверить это предположение. Но если цель иная, то оно надо? поэтому видим двойную загрузку.
-
Не смотря на жуткий отклик сервера в результате экспериментов мне удалось сделать и выше оценку. Напомню, что при начальных 5...8 баллах для мобильных и около 20 для десктопов. Но я не стал закреплять данный результат, т.к. даже для его закрепления надо кое-что шлифануть. Но не бесплатно же? Поэтому просто откатил. Все равно вас не устроит подъем на несколько десятков баллов и платить вы за это не будете. Если бы я знал, что мне за подъем с 5 баллов до 50...70 будет оплата, то мое отношение к работе было бы несколько иным. У вас серверный оклик 4 сек и 5 сек соответственно. При том, что работа моего оптимизатора занимает сотые доли сек. Бесплатно я обещал лишь прибавки в несколько десятков баллов. И вы ее получили. Забесплатно добиваться 90+ без оптимизации серверной части невозможно, да и за деньги тоже невозможно. Этого невозможно чисто по "физическим законам". Также не забываем остальные отягощающие факторы на вашем сервере. Нужно лучше? Думаю, что уже все поняли, что за все нужно платить. В том числе и за оптимизацию серверной части. Может быть вам для начала что-то с хостингом сделать? Например, сменить тормозную хост-площадку? А то желание "хочу 80+ или 90+" при таком хостинге (отклике сервера), DOM в 12 000+ и пр. и пр. выглядит через чур требовательным, при том, что моя работа оказывается бесплатная по настройке/подгонке. Вы же ни копейки мне не платили - это для понимания читателям. Думаю, что нет смысла более уделять так много внимания вашему тяжелому сайту в теме поддержки.
-
помимо огромного DOM (10 000+ узлов) имеются серьезные проблемы с откликом страницы. он колеблется от 2 сек до 6.5 сек для главной. Поэтому говорить о результате в 90+ без комплексной оптимизации не приходится. Любой вменяемый специалист и заказчик это понимает, на неадекватов, заглянувших на огонек не будем обращать внимание. вот немного крупнее интересующее нас место (почти 4 сек задержка): Для десктопов узлов еще больше - 12 000+, оценка на старте тоже низкая: Вот что получилось для десктовпов на выходе: При прочих равных оценка гугла сильно зависит от отклика сервера. Это наглядно видно на скриншотах. Модуль hi-Optimizer не влияет на отклик сервера, для этого нужна отдельная работа. Требовать от hi-Optimizer при огромном и гуляющем отклике сервера оценки в 90+ или "хотя бы" 80+ - это слишком.... Как обещал, то в таких случаях моя оптимизация приведет к поднятию оценки на несколько десятков баллов. В данном случае для десктопов прибавка примерно в +40 баллов. Разумеется, что необходимо работать с длиной отклика сервера обязательно. Не может быть чудес только от оптимизации JS, CSS, но с дурной работой серверной части. Hi-Optimizer работает с клиентской частью, т.е. с программами на стороне пользователя. Соответственно для смартфонов получаем улучшение для главной (40...49 против начальных 5 баллов): Я сразу писал, что говорить в таких тяжелых условиях можно о подъеме в несколько десятков баллов при моей бесплатной настройке. Я за свои слова отвечаю. Даже в этих сложных условиях я мог бы поднять баллы еще выше, скажем, до 60...70. Это без решения проблем на сервере с откликом. Но, как вы писали выше, вас не устроит такой результат при любом раскладе. Так какой смысл мне делать подъем за бесплатно до 60...70? Согласны? думаю, что уместно напомнить мою аналогию с автомобилем на лысой резине и с убитым двигателем. Любой адекватный заказчик прекрасно понимает эту аналогию.
-
ошибка bad request в карточке товаров
sitecreator replied to hitball's topic in Opencart 3.x: Sandbox
так 502-я возникает не только из-за кукишей. это лишь одна из причин. я могу привести примеры когда с кукуами полный порядок, но возникает 502-я уже, действительно, с серверными корнями проблем. А бывает целый клубок одновременно разных источников. Вам, видимо, просто не повезло столкнуться когда причин сразу несколько одновременно. про "ура", думаю, что сильно преувеличено, так как подобная кука должна набрать определенный лимит длины чтобы проявится, а для этого нужно иногда не один час ходить. да и подобных кукишей может быть много, и от разных авторов. вот еще пример модуля, который в кукишах хранит все просмотренные товары. Мне "повезло", и на сайте было сразу несколько источников 502-й от разных авторов. Я бы не сказал, что такой клубок распутывать просто. ходить можно долго. Особенно если куки разных модулей реагируют по-разному, т.е. совсем не обязательно, что они одновременно растут на одних и тех же страницах. да еще представьте, что на сайте поиск сложный и долгий, плюс утечки памяти из-за php-fpm. А утечки приводят к той же 502-й, но причина иная. Вот это все мне пришлось разгребать. А вы говорите - просто. да ничего подобного. Отрубил одну голову дракону, а там еще две остались в виде php-fpm с утечкой и еще иного модуля. Вы же не будете спорить, что 502 как раз возникает когда есть утечка памяти и память банально заканчивается? -
ошибка bad request в карточке товаров
sitecreator replied to hitball's topic in Opencart 3.x: Sandbox
она, она родимая. Словлено было моими клиентами на двух разных сайтах, как минимум. Проявляется в виде bad request или 502-й ошибке. @hitball , вам прямиком к разработчику модуля. Впрочем, я ему уже написал об этой ошибке. остается ждать когда будет вероятное исправление. Ошибка из разряда крайне сложно диагностируемых. -
[Поддержка] Бонусные баллы (расширение функционала)
sitecreator replied to gello93's topic in Модули и дополнения
все верно, из той же самой оперы. 502 или bad request и так и эдак может проявляться. bad request ловил тоже. самое противное, что отловить крайне непросто, особенно когда 502-я, ибо тут информативности об ошибке просто ноль. Авторы забывают, что куки в браузере имеют ограничение на длину, и при очередном обновлении куки браузер не следит влезет ли в нее новая добавленная инфа или - нет. А потому получается кастрированная кука, которая потом покажет нам всем кукиш в виде 502-й или подобной гадости. Стоит в такой куке отрубить кастрированный кусочек на конце и снова страница открывается нормально до очередной попытки удлинить куку. -
[Поддержка] Бонусные баллы (расширение функционала)
sitecreator replied to gello93's topic in Модули и дополнения
Здравствуйте. Замечена серьезная проблема, которая приводит к 502-й ошибке сервера и белому экрану. Это переполнение ваших кукишей, которые вы ничем не ограничиваете по длине, а хранятся они целый год. В какой-то момент они становятся слишком длинными и браузер их обрезает. Из-за этого происходит ошибка 502 на сервере. Кукиши должны быть ограничены по длине, в браузере на длину есть лимит. У вас, похоже, длина ничем не лимитирована. Проблему наблюдал на 2-х сайтах. Модуль пришлось удалить. Прошу пересмотреть вариант хранения информации. Все же кукиши не по назначению используются в вашем модуле, на мой взгляд, вы их пытаетесь использовать как БД, что приводит к переполнению. Информация тщательно анализировалась, я привел лишь выводы после анализа на 2-х сайтах.
