Да, это не опенкарт

[ArtemPitov]

 технология AMD

а это что такое ? бросьте ссылку пожалуйста 

 

- все нарыл ) 

Змінено 5 жовтня 2016 користувачем ArtenPitov

[markimax]

а это что такое ? бросьте ссылку пожалуйста 

https://www.google.com/search?q=RequireJS+%D0%B8+%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F+AMD&ie=utf-8&oe=utf-8&gws_rd=cr&ei=_EL1V5TSNImfsgGTh4yACw

 

http://sly-and-fluffy.blogspot.com/2013/02/amd-requirejs-javascript.html

 

Можно попробовать переписать addScript под AMD и RequireJS

И тогда можно выжать из opencart -a 99/100 и самое главное совместимость с JS других модулей

[ArtemPitov]

Кому лень почитать 

 

[sitecreator]

Да в какую бы сторону не смотрели, но файл CSS все равно нужно подключать в хедере страницы.

 

Иначе каким образом можно отобразить шапку не загрузив еще файл CSS? Да никаким!  Только если встроить весть CSS в HTML код.

[ArtemPitov]

Да в какую бы сторону не смотрели, но файл CSS все равно нужно подключать в хедере страницы.

 

Иначе каким образом можно отобразить шапку не загрузив еще файл CSS? Да никаким!  Только если встроить весть CSS в HTML код.

я выше привел пример, скилет (первый экран ) в инлайном в шапке, все остальное потом и подключая в футере 

[Гість]

Это звиздетс!

 

запихнули весь css bootstrap на каждую страницу в html!

 

****com/about

 

весь css весом в 80Кбайт впихнули на страницу! более 2600 строк CSS прямо в начале HTML!  при этом сама страница с этим css занимает 90К с лихом. 10...20К полезного и 80К некешируемого мусора. вот это "эффективность"!

 

И все на забаву Гугла.

Где там 80кб и 26тс строк кода ? Если не знали то оттуда можно вырезать все лишнее, а еще произвести минификацию.

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

Змінено 5 жовтня 2016 користувачем Гість

[sitecreator]

Где там 80кб и 26тс строк кода ?

это мне вопрос? в каком смысле "где"? в хедере.

 

 

можно вырезать все лишнее, а еще произвести минификацию.

 

 

и это лучше чем один раз загрузить файл в кеш браузера? Т. е. лучше в каждую страницу пихать бутстрап в хедер?

 

 

страницы не кешируются. Правда здорово грузить 50К...80К СиЭсЭсов для каждой странички заново?

[sitecreator]

 

вот этот текст весит около 80К в формате utf-8.  без gzip

[Гість]

Ну что сказать, имея нормальный хостинг сервер , 80кб это иголка в стоге сена ) Или Вы хотите сказать что еще диалапом пользуетесь.

А бутстрапа там на 26тс строк кода нет !

Змінено 5 жовтня 2016 користувачем Гість

[chukcha]

Ну что сказать, имея нормальный хостинг сервер , 80кб это иголка в стоге сена ) Или Вы хотите сказать что еще диалапом пользуетесь.

А бутстрапа там на 26тс строк кода нет !

ты давно на жопорезе сидел?

А мне вот недавно пришлось

 

И это при условии, что я знаю, что такое 2400

[Гість]

ты давно на жопорезе сидел?

А мне вот недавно пришлось

 

И это при условии, что я знаю, что такое 2400

И ? Я все равно не ловлю сути с этими "выдираниями" контекста. Я показал просто что можно выжать 100 из 100, вы мне показываете стили в шапке сайта. И говорите про то что это х**во, а это уже вторая сторона медали

[Гість]

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

И да, за такое вряд ли кто возьмется )

Змінено 5 жовтня 2016 користувачем Гість

[sitecreator]

можно выжать 100 из 100

 

можно, но к реальному ускорению это не имеет никакого отношения.

 

80кб это иголка в стоге сена ) Или Вы хотите сказать что еще диалапом пользуетесь.

 

Вы это Гуглу скажите когда он просит сжать файл из-за  выигрыша в 960 байт, а пока не сожмете, то не будет 100/100.  И при этом можно трафик для одной страницы хоть 10 Мегов сделать, на это внимания он не обратит.

 

А вообще речь шла об соотношении полезной информации (20К) к общему объему (100К).  Т. е. 80% траффика - это некешируемый мусор если не учитывать картинки.
 

 

И на опенкарте можно такое реализовать

 

 

А цель? что это даст?

 

Вот я решал сейчас вполне реальную задачу с БД в 350 Мегов.  И с просмотрами за 10000 в день.

Как вы думаете будет польза от такого решения "100/100" или наоборот вред?

[HyperLabTeam]

И ? Я все равно не ловлю сути с этими "выдираниями" контекста. Я показал просто что можно выжать 100 из 100, вы мне показываете стили в шапке сайта. И говорите про то что это х**во, а это уже вторая сторона медали

Да тут больше не к тебе вопрос а к адекватности гугпейджсПидора))

Змінено 5 жовтня 2016 користувачем AWARO

[ArtemPitov]

Вот я решал сейчас вполне реальную задачу с БД в 350 Мегов.  И с просмотрами за 10000 в день.

 

Вот это уже интереснее, что интересного было сделано ? 

 

ЗЫ // Да ну этот гугломер, он главной гугля что то в районе 60 ставит =) 

[sitecreator]

Да тут больше не к тебе вопрос а к адекватности гугпейджсПидора))

 

Так в том то и дело.  Раздуваем реальный трафик чтобы получить выигрыш в виртуальных циферках.  Т. е. создаем видимость без реальной пользы.

Главное, что на действительно нагруженных проектах проку от такого фокуса никакого, а только вред.  Поскольку при большом количестве посетителей запускать gzip для каждой некешируемой  страницы - это уже накладно, учитывая, что она увеличилась всего то в 5 раз из-за того, что css внутрь запихнули.

 

Трюк да и только.  Демонстрация возможностей без практической полезности.

 

Вот это уже интереснее, что интересного было сделано ?

 

Это и впрямь довольно занимательно, учитывая, что нехилый серверок все это дело отрабатывает, всего-то навсего 8 ядер....  А при заходе в админку прежде чем отобразятся последние заказы несколько секунд проходило.

 

Мусора движок много пишет в БД в том числе.  Название браузера, операционку, язык расладки клавиатуры все это в БД льется в том числе. Не смотря на то, что статистику по браузерам можно получить итак на сервере.  IP пишется в символическом виде (vchar), когда это число вообще то.  Даже вот эти все мелочи (оптимизация их) позволили 10% места освободить. Но это не главное, конечно, же.  Сейчас без потери информации общий вес БД понизил до 199 М.

 

Под большие проекты структуру БД нужно кардинально менять. Слишком неоптимальная она.  Много ненужного дублирования.  В тех же заказах идет дублирование страны в виде id и еще текстом. Хотя всегда по id можно получить название страны, для этого существует своя таблица.  И такого дублирования очень много.

 

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

[ArtemPitov]

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

 

Да я недавно в ступор упал, для отображения отзывов на странице товара подтягивается 2 ненужных таблицы 

 

 

r.review_id, r.author, r.rating, r.text, p.product_id, pd.name, p.price, p.image, r.date_added

 

review

product

product_description

 

ЗЫ \\ а тесты чем проводите  ?

[chukcha]

Ну так мы ж уже выясняли зачем там pd

 

Для языкового префикса.

[sitecreator]

Кстати, на примере такого большого проекта понял малую полезность от встроенного  кеширования в виде файлов.  Польза от всех этих "бустов" будет лишь в случае отсутствия у вас администрирования сервера БД и небольшого размера самой БД.  Грамотное кеширование средствами mysql перекрыло все потребности в костылях в виде всяких доморощенных кешеров и ускорителях.

 

Для примера, кешировал средствами движка модуль "категории" (до 3 уровня).  Выигрыш есть.  Но если настроить сервер БД и кешировать его средствами, то проку от кеширования модулей никакого не обнаружил, что ожидаемо.  Страница грузилась ровно столько же по времени: 1) кеш mysql и 2) кеш mysql + кеширование модулей "файлами".

[chukcha]

IP пишется в символическом виде (vchar), когда это число вообще то.

Remote_addr - что вернуло, то и пишется.

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

 

В тех же заказах идет дублирование страны в виде id и еще текстом. Хотя всегда по id можно получить название страны, для этого существует своя таблица.

 

Не вижу причин хранения, но не вижу причины не хранения, или же тогда для отчета нужно присоединять еще одну таблицу. Не нагрузка?

[sitecreator]

кстати, когда у вас всего один магазин в БД и один язык, то можно выкинуть кучу ненужных запросов.

И индексирование в БД перестроить.

 

А то там сейчас используются комбинированные индексы "язык + параметр".  При одном языке это все ненужно.

[sitecreator]

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

 

можно, да только на практике толку никакого.  Что полезного можно извлечь из этой статистики? Заказчик за 4 года ни разу ничего такого не смотрел и не строил. Без надобности ему.  Его другая статистика интересует.

 

Возможно, что в других случаях будет другой расклад.

[ArtemPitov]

@chukcha,да я знаю, как пример привел 

[sitecreator]

ЗЫ \\ а тесты чем проводите ?

 

чего конкретно?

[snastik]

Гугл, честно говоря, такие глупые рекомендации порой дает..

 

Я тут тормознутый сайт ускорял. Страница генерируется теперь за 0,5 сек вместо 2,5 сек.  А с кешированием mysql за 0,2 сек. Т. е. на порядок быстрее стало. Гугл за это накинул 3 балла всего.

 

Картинки на сайте грузились в родном разрешении (500х500) на странице категории, но ресайзились средствами браузера до нужного разрешения (200х200).  Гугл и тут не сильно добавил очков за оптимизацию.

 

Суммарный размер картинок его вообще не интересует, важно лишь, что можно выиграть от сжатия 16Кбайт.

У меня на сайте картинки были в PNG (!!!).  Представляете общий вес?  Перевел все в JPG.  Общий вес картинок уменьшился в несколько раз, а это мегабайты! Но гугл даже не заметил этого вовсе!  Ни одного балла не добавил, т. е. уменьшение на десятки мегов не заметил, но обеспокоился упущенной выгодой в 16 килобайт...

 

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

 

Извините,  а зачем вы масло масляным делаете ? Ведь Mysql шикарно кеширует запросы сама по себе?

Я вот часто сталкиваюсь - мне закешировали mysql?

Вы вроде бы давно на форуме и не самый глупый подрядчик...

Обьясните мне, зачем кешировать то, что и так кешируется?

 

Это ведь как воду сделать мокрой, а сахар сладким.