Угу. А подумать что я проверял такую гипотезу - не судьба?)
<input type="password" больше похоже на правду, но тоже неоднозначно.
Оформление заказа имеет кучу приватных данных, но предупреждения там нет. Хотя на логине того же сайта - есть. поля со звездочками в основном есть, но тоже есть нюансы.
А я здесь при чем?) Чего ко мне адресуетесь?))
Да и потом - откуда он 40мс получит если явно не понимает меня когда я говорю о чем-то вроде:
и разница между индейцем и нгинсом ему тоже не ясна?
Разве что случайно удачного хостера найдет.
Что у него здраво так это то, что он не захотел тащить за собой вагон глюков бесплатных коробок.
Сегодня во всех админках у ФФ у меня появился зачеркнутый замок.
Логику как они узнают что это форма логина я не понял, видно регулярки какие. Вроде фидбеки и т.п. не трогают, но полагаю что ПОКА.
Что за экспертизы?
А что там особенного? Нормальный хостинг и нормальная верстка у шаблона. Что тут дорогого? Дорого притирать разные части шаблона друг к другу. Тестирование и т.п., но если шаблон из стандартного набора, только картинки поменяли и прочие подобные вещи, то что там денег стоит?)
Ну так общепринято что первая страница отрендерена максимум через секунду.
В смысле всё скачалось и разобралось. Бегло гляньте на PageSpeed Insights. Сильно задрачивать не надо, но в качестве ликбеза самое то. Например спрашивают не про первую страницу, а про первый экран первой страницы. А тут большое пространство для маневра. В большинстве случаев в полсекунды все укладываются.
Сложно сломать код который не игнорирует нотисы про депрекейтет. Когда сломалось то ворнинги это вторичное. Но тоже - логи стоит читать.
Любопытно что именно отвалилось).
А так то не пользуйтесь говном, знайте свои зависимости, пользуйтесь библиотеками написанными по стандартам того десятилетия в котором живете, и будет вам счастье. Да, говнокода много. Но не обязательно во всё вступать.
Знаю) Вы это уже не первый раз рассказываете. Вам не первый же раз говорят, что да, говна много, но это не повод считать говном всё, но вам всё равно. В школе логику прогуляли, и не знаете что миллион примеров за опровергаются одним против. Сколько бы не было кривых коробок - это не отменяет факта что использование СУБД на сайте лучше чем ваши поделки).
Было уже.
Тоже было.
И это было.
Семь бед один ответ - коробки медленные и глючные, всё что есть у 90% магазинов им на самом деле не нужно, и никому не нужно потому что ТС так решил. Кеширование не спасает потому что у него еще лучше чем кеширование. Чем? Всем! Измеряется в попугаях и в сравнении с Битриксом.
Насколько я понял он сохраняет базу в json и по необходимости вытягивает ВСЮ базу аяксом. В целом в первой половине топика были интересные обсуждения из серии олимпиадных задач "как бы вы выкручивались если бы искусственно было запрещено нормальное решение". И идеи были интересные. Но... чисто в рамках олимпиады.
Это выбор между чужим велосипедом и своим. Тут поддерживаю. Сам неоднократно уходил в велосипеды, и таки наконец дорос до того, чтобы да, фреймворк имел право на жизнь. Но... мы ведь говорим о тонком статическом фронтэнде. И не в частном узком случае, а в массовом применении. И тут наличие косяков боксовых движков - неуместно.
Совокупная стоимость владения это важный фактор, но не единственный.
Каждый доллар на старте стоит много больше чем после выхода на окупаемость.
А если это еще и стартап, когда ты не уверен что не прогоришь...
А это здесь причем? Правильная верстка, правильно настроенный htaccess, сжатия, все дела, банальный нгинс в кеширующем режиме стоящий перед апачем (типичная конфигурация нормального хостера, ибо без апача не каждый клиент умеет), оптимизированные картинки, и нагрузка на хостинг будет меньше чем у вас. А уж тяжелые страницы с кучей цсс и жс, про которые вы писали... это не к пхп вопрос.
Да и потом - обычно хостеры стараются экономить свои сервера, и при грамотной настройке эти сотни килобайт будут жаться за счет настроек хостера, плюс отдавать срок кеширования большой, так что в реальности этот груз открывается лишь один раз, при первой странице. Если же верстальщик основную массу этого кода сделает неблокирующим оставив лишь самый минимум, то субъективно никто ничего не заметит, а объективно трафик тоже будет тратиться минимально.
Индивидуальный костюм можно починить у обычного портного. У любого хорошего портного.
Вопрос не в том что Ваш проект стоит значительно дороже рынка. Вопрос в том, что его совокупная стоимость владения еще выше. Сегодня вашему клиенту не нужно наличие. Завтра нужно. Сегодня он не видит необходимости в крослинкинге предложений, кто смотрел и т.п. Завтра будет нужно. Сегодня не нужен поиск по атрибутам, завтра нужен. Всё это у вас будет стоить дорого, но это черт с ним. Многие покупают битрикс и рады. Оно будет костыльно. Вот что важно. Вы за клиента решили что ему нужно, а что нет.
Какая у клиента должна быть посещалка, чтобы "экономия на серверах" окупилась? Грубо говоря штуку баксов именно за это он переплатил. Потом еще доплатит, но это потом. 10 баксов в месяц хостинг потянет тысяч 10-50 уников в день и не чихнет. Допустим вы запихнули клиента в хостинг за 1 бакс. Это экономия 9 баксов в месяц, 110 в год, т.е. за 9 лет он вернет свои деньги (только эти), и начнет экономить... офигенский ROI не находите?)
Угу. И он пойдет к тому кто ему сделает за 50 баксов и без всяких консультаций.)
Нет, конечно полноценный магазин за 100 баксов это фантастика. Но то что хочет клиент за 100 баксов, так это то что хотят 90% клиентов, и вполне можно давать всем в готовом решении. Статейник с несколькими видами фидбека, витриной, корзиной, акциями/топсейлами и т.п. магазином не является. Это визитка, и если клиент будет ее сам заполнять, и его устроит слегка оттюнингованный под него дизайн (а настроек у нас несколько сотен), то почему бы и не дать ему такую визитку за те деньги что он просит?
И главное - когда его бизнес выростет, и у него появятся большие потребности, то ему не нужно будет всё выкидывать.
Не отключайте нотификации когда тестируете код. Всё.
Обновления пхп очень демократичны. Если не использовать депрекейтет и писать на актуальной версии, то о проблеме узнаешь года за два. Слышали сколько воя было что злые люди в пхп7 убрали пхп4-стайл-конструкторы? Сумасшествие это. Еще в середине пятой ветки надо было их убрать. Одни проблемы с этим. mysqli всё еще доступен, и даже без плашки депрекейтет вроде. Хотя писать на mysqli когда PDO является системным расширением - наркомания.
Нет, бывает. Бывает что-то не так написали, не протестировали (почему?) и т.п. У меня вон полгода назад было. Написал код "как надо" под 5.5, с воркараундом под пхп5.4. Обновили на пхп5.6 и легла авторизация, ибо основной код был недостаточно протестирован, и реальность отличалась от документации. Перевел всё на режим совместимости, и забил.
Бывает. Но хостер который заранее не предупреждает - мудак. Да и вообще что за обновления я не понимаю. У всех обычно несколько версий. Древних переносят на отдельный сервер. Нет, если пхп4 "вдруг" "неожиданно" отключили то да, бывает. Но... Все переносы делают с тестами заранее.
Любопытно какие же у Вас зависимости такие?
У меня пхп5.4+ (причем чисто потому что не готов array() писать, всё остальное я бы и под 5.3 заточил), gd, curl. Ну SPL, PDO да. Но... нужно быть совсем отбитым, чтобы подавлять дефолтные вещи. Конечно бывают и мемкеши и прочее, но если оно на шареде живет (не часто встретишь мемкеш на шареде), то все равно деградация без мемкеша идет автоматом.
Вот что из неустановленных расширений вы можете потерять? Совместимость да, бывает не всегда соблюдается, но и то, если не подавлять нотисы, то нарваться на грабли сложно. А вот нехватка расширения... просто интересно что это было?---------- Добавлено 30.01.2017 в 12:16 ----------
Зависимости можно и нужно указывать в компостере. Тогда поймаешь вавку на этапе сборки. Всё.---------- Добавлено 30.01.2017 в 12:24 ----------
Скорее у всех разные коробки)))) Вы так напираете на сравнение с некоей коробкой, что вообще не слышите окружающих. Так то я автора опенКарт утопил бы в детстве, чтобы такое не рождалось. Оскомерс вроде тоже из той же области, но... это не повод, не повод всех грести под одну гребенку.
Вот тут кивну. Согласен. :) Обычно всякие рюшечки добавляю только когда "клиент созрел" не в плане хотелок, а в плане потребности бизнеса. 90% тех кто хочет "магазин" - нуждается лишь в простенькой витрине. Или не очень простенькой. Например делали сайт импортеру одного автобренда. По сути визитка, два десятка моделей, меньше сотни модификаций, корзина? А нафига если наличие не столь очевидно... Но украшательств был миллион. Слайдеры, шмайдеры, характеристики, перелинковки... Нафига им корзина? Вот нафига?)
А можно оценивать результаты внедрения раньше чем через год после внедрения?)
Сколько СТОИТ ваше время?
Я привел вам пример сайта сделанного из боксового движка человеком который знает только фотошоп, не знает ни JS ни php ни CSS. Знает основные HTML-теги, и то "со словарем". Да, сейчас такие коробки стоят некоторую небольшую денежку. Но... сколько стоит ваш час работы? Сколько часов вы потратили на этот проект?
Сколько будут стоить все более и более сложные костыли при разрастании требований? Вы смеетесь с битрикса за дороговизну. Я и сам с него за это смеюсь. Но ваш проект много, много дороже. Если у клиента совсем нет денег, или у меня есть другие интересы, то я могу предложить простой ИМ с уникальным дизайном, небольшой заточкой под его специфику и т.п. по стоимости сайта-визитки, за 100 баксов. И у него будет базовый функционал и скорость работы как у вас. А вы по чем?
Вы слишком дороги. Слишком. Потому и не нужны. :)
На двенадцатой странице речь по прежнему идет о идее ТС вынести весь магазин на бекэнд живущий на другом сервере, а на фронте держать только кеш сайта отрендеренный заранее. Идея конечно стара, список граблей известен, как и плюсы идеи. Но велосипедисты не переведутся. Это даже хорошо, ибо весь мейнстрим создан велосипедистами. Но... велосипедисты бывают разные.
Пример сайта в личку пожалуйста дайте. И возможно ли контент получить не в виде сайта? Интересует в качестве рыбы для наполнения тестового фрихоста на своем конструкторе сайтов. XML-ку какую-то или еще какие вариации...
В том то и дело).
Самое тяжелое это картинки, и они одинаковы в обоих подходах).
но дело не в том.
Вот пример сайта который не оптимизировался, кеша нет, ребята делали на довольно старенькой версии движка магазина. Там ни кеширования нет, ни особых оптимизаций, всё динамическое, все конфиги тянутся динамически и всё такое, т.е. да, каждый раз динамически генерится и меню, и футер и т.п. master-car.net.
Я в вас верю, я думаю у вас быстрее. Правда тут хостинг с пирингом до всех одесских провайдеров, что у меня на них пинг 1мс, и я просто не вижу где может быть быстрее. Всё упирается именно в картинки которые не оптимальны. Но да, можно сделать быстрее. Скажите другое - оно НУЖНО делать быстрее, если вот так оно из коробки работает, без допила?---------- Добавлено 28.01.2017 в 12:32 ----------Гы. Глянул сайт через VPN, чтобы убрать эффект близости сервера. Мееедленно.
Вот что делают неоптимизированные картинки.
