Кто пробовал модуль По описанию должен кэшировать страницу сайта (но перед утсановкой изменят индекс пхп) кто пробовал?
Исходя из описания и беглого просмотра кода - это должен быть вполне неплохой вариант полного кеширования страниц средствами php (точнее, на нём написанный). Но вообще, такое лучше организовывать через nginx. Хотя и придётся немного с настройками поморочится (и иметь к ним доступ).
А что-бы иметь нужен впс верно? --- Добавлено, 15 авг 2018 --- А то думал сделать с него и TurboCache ot Snastik тандем и запустить. Или одно другому может потом помешать?
Да. Это не имеет смысла. Этот pagecache и так целиком кеширует страницы, никакое дополнительное кеширование к нему не нужно. Более того, возможно, имеет смысл даже от стандартного кеша избавится, если использовать этот модуль. Вот только, мне сейчас подумалось, что этот модуль несовместим с ЧПУ. Точнее, он не сможет опознать исключения, если у них ЧПУ. Правда, можно в список исключений прямо ЧПУ и вписывать, а не роуты, как там изначально.
обыкновенный html кешировщик полное кеширование страницы, как по мне - фуфло тРубо изначально было построено на его принципах, и ядре , потом там что-то подкрутили свое.. как по мне, наиболее приличное - jet cache от маркмакса, но и он с недостатками Все эти недостатки модулей, к сожалению, связаны с программной структурой опенкрата есть еще кешеры, но я их даже озвучивать не хочу.
Но именно так работают все топовые магазины (Розетка, например). И это вполне оправдано: в интернет-магазине динамический контент практически на 100% связан с действиями пользователя (корзина, вишлист и т.д.), а это всё на аяксе. Остальная часть страницы может меняться даже реже, чем раз в сутки, так что вообще нет смысла дёргать движок на каждом запросе. Даже при условии, что все данные уже и так закешированы, всё равно тратятся ресурсы на лишний воркер пыха, и времени это заберёт всё равно в разы больше, чем отдача статичного файла из кеша. Я сейчас говорю, конечно же, про кеширование средствами nginx или varnish. В случае кеширования на пыхе лишний воркер всё равно используется и эффект становится намного меньше.
Не вопрос.. про аякс.. Вот смотри.. Я закешировал статическую страниц, а теперь я должен отдать и динамическую состоавляющую.. Сделать еще один запрос, а то и два Тем самым увеличить запросную составляющую, а там.. по крайней мере в опенкарте.. и библиотеки, и переменные, и модели и так далее. Но вот что касательно кеширования Как я делал на одном проекте.. самопале.. Кешировался html в json массив Со всеми переменными но динамические переменные помещались в спец место И рендер, а вернее роутер кешереовщика обрабатывал только, их т.е. скомилированый код шаблона в кеше был такой <html> <body> {{ dynamic1 }} статический контент {{ dynamic2 }}{{ dynamic3 }} </body> </html> по сути рендерился только динамический контент. Что делают мне известные опенкартовские кешеры? Тупо кешируют Марк там начинает играться с кеширванием контроллеров, но у него тоже не все гладко
Это очень похоже на SSI. В случае SSI экономия по сравнению с аяксом происходит только на сетевых запросах, все дополнительные запросы к пыху сохраняются. И хотя сетевые запросы - это существенная составляющая по затратах времени, но есть несколько "но": - в отличии от аякса, SSI тормозит загрузку тела страницы - при наличии HTTP/2.0 лишние запросы уже не так критичны В сумме получаем, что с точки зрения впечатления пользователя вариант с аяксом будет существенно быстрее, чем с SSI. Хотя, возможно, в плане общего времени полной загрузки страницы выигрыш и будет минимальным.
ну, давно это было... Я просто показал.. Вот сегодня столкнулся.. есть кешер boost, чудный такой, кеширует и заголовки и контент Но.. Lastmodified кеширует, но не отдает 304 Т.е. кешеры должны быть умные. Мало того, ведь есть корзина, есть сравнение, есть вишлист, есть последние просмотренные есть.. кщк динамические составляющие.. Их все аяксом?
Если говорить про ОК, то корзина и так почти полностью на аяксе, вишлист тоже через аякс работает и не проблема допилить это и всю остальную динамику до полного аякса. В случае Розетки, там как раз вся динамика на аяксе. Если загрузка подтормаживает, можно даже не заглядывая в инструменты разработчика заметить, как корзина, вишлист, приветствие пользователя изначально загружаются в дефолтном состоянии, а потом уже под текущего пользователя аяксом догружаются. Но суть в том, что пока они догружаются, пользователь уже может видеть контент страницы. Для хайлоада уровня Розетки такая реализация означает, что можно существенно сэкономить на серверах, которые обрабатывают каталог товаров, поскольку количество обращений к ним будет минимально (по крайней мере относительно количества страниц и посетителей).
Я тебя прекрасно понимаю но это все надо делать на этапе создания магазина. Розетка пример хайлоада, и немеряного бабла вкладываемого в поддержку. опенкарт также может справиться с нагрузкой, но для этого нужно немного.. Все динамические переменные в аякс Не совсем, ведь common/cart Код: foreach ($this->cart->getProducts() as $product) { Т.е нужно удалять, а по клику грузить вот тебе пример со сравнением {{ compare }} Это динамическая переменная Следовательно при рендеринге она должна обновиться. но страница уже закеширвана.. Что делать? Правильно!!! Переменная в статику, а в аяксе - getCompare также getWish также getSticker - это еще та штучка.. и т.д. Кто готов вложиться? А ведь вроде не много надо.. если есть продажи.. Тогда и магазин летать будет.. + оптимизация картинок - немаловажный факт вопрос про оптимизацию скриптов и стилей открыт Управление местом загрузки Мало того, я бы и верстку переделал. {{ header }} {{ content }} {{ footer }} где header - это только <head></head> а content состоит из блоков {{ main }} {{left}} {{right}} {{ head }} А стилями и скриптами {{ head }} перемещать в нужное место Тогда.. Пользователь сразу получает основной контент и он ему доступен при загрузке.. Но!!! Бабло решает все. Кто готов за это платить?
Вот это и есть та часть, которая "почти" Надо просто сделать вывод этого блока без подгрузки данных и добавить на документ реди подгрузку корзины аяксом, как при добавлении товара. Стикеры - это уже сторонний функционал. Стороннего может много найтись такого, что придёться перепиливать. Кстати, Астикер изначально работает через аякс. Правда, у него другая беда: отдельный аякс запрос на каждый товар на странице. Это тот случай, когда предложение должно рождать спрос. Люди ведь покупают всякие супер-пупер турбо бустеры, которые творят какую-то алхимию обещая превратить какашку в золото Но всё упирается в наличие VDS, ибо без кеширования на уровне сервера овчинка выделки не стоит. По крайней мере в случае отсутствия каких-то особо тормознутых модулей, но в таком случае лучше непосредственно с ними разобраться.
Не обязательно.. ВПС/ВДС даст возможность тонких настроек, например самого mysql, или того же php, отключая, подключая нужные модули. Управление хранилищем. Или, например для быстрой фильтрации использование сфинкса и его тонкие настройки.. Но все это не малые деньги.. Нужен ли, например быстрый поиск? Поставить систему логирования поиска и проанализировать.. Может того не стоит.. Проанализировать частоту использования фильтров - имеет ли смысл тратить силы на кеширование, оптимизацию запросов. Кроме того, анализ и настройка архитектуры базы, Частота обновления, средства обновления, учет просмотров и тд, возможно переход с myISAM на innoDB
Самое интересное что кэш изображений то на опенкарте даже 1.5.6.4 работает (на хосте чётко есть папка кэша имейдж с размерами). Почему же её не видит гугл?
Кого не видит? какой кеш? Или вы имеет ввиду заголовки кеширования? Так это к серверу.. Не путайте оптимизацию картионок с кештрованием. Оптимизация -= это грубо, уменьшение размера, без потери качества. К сожалению gd библиотека, не обладает оптимизацией, для этого существуют другие методы, и для их внедрения, нужен вдс/впс
