Death by Magento カスタマイズ

公開: 2018-10-31

Death by magento customization

多くの e コマース マーチャントにとって夢の Web サイトには、想像できるすべての機能に加えて、e コマース ビジネスの成長と運営を容易にするために必要なカスタマイズがすべて含まれています。

多くの小売業者にとって、Magento はその夢でした。 機能が豊富で、低コストで、カスタマイズが容易なソリューション。 残念ながら、Magento サイトにあまりにも多くの機能やカスタマイズを追加して自分自身を拡張しすぎた多くの貧しい人々にとって、その夢は悪夢に変わりました.

最初のビルドでは、過剰にビルドされたサイトの未解決のバグを解消することが実行可能に見える場合があります。 しかし、時間が経つにつれて、問題が積み重なって、サイト全体がダウンし、多くの顧客が失われる可能性があります (それに対応する売上高も失われます)。

だから — 多すぎるとはどのくらいですか?

この質問には、個々のビジネスごとに固有の答えがあります。 どの組織でも合理的に作成および維持できる機能およびカスタマイズの数には一定の制限があります。 優れた予算と技術的な洞察力を持つ企業は、信じられないほど複雑なソフトウェア (Google や Amazon など) をサポートできます。 しかし、すべての企業は、自社の限界を理解し、自社の能力の範囲内で事業を展開し、成長する方法を理解する必要があります。 まず、過剰なカスタマイズによってどのような問題が発生するかについて説明します。

  • コストの上昇 – カスタマイズの維持とアップグレードに多額のコストがかかるだけでなく、それらのドキュメントとノウハウの維持にもコストがかかります。
  • セキュリティ リスク – 拡張機能には、Web サイトへのバックドア侵害を開くコードが含まれている場合があります。 サードパーティの拡張機能は、e コマース ストアにいくつかの優れた機能を提供できますが、インストールする前に、経験豊富な開発者が品質とセキュリティについて徹底的に吟味する必要があります。
  • 遅い速度 –今日の競争の激しい環境では、e コマース企業が Web サイトの速度を最優先事項の 1 つとして考えなければならないことは言うまでもありません。 ほとんどの拡張機能は、CSS、スクリプト、画像などのアセットをロードするために HTTP 要求を作成します。拡張機能が正しくコーディングされていないと、さまざまな種類のパフォーマンスの問題が発生する可能性があり、その一部はトラブルシューティングが困難になる可能性があります。 新しい拡張機能またはカスタマイズがステージング環境でテストされているときは、ページ速度を常に批判的に評価する必要があります。
  • Web サイトの継続性 (またはその欠如) – Magento の広大で複雑なアーキテクチャにより、コードの難しさが拡張機能の競合を引き起こす可能性があります。 コードが修正されていない限り、これによりページがクラッシュする可能性があります「ページが見つからないというエラー」ほど不安なことはありませんが、顧客そのエラーを目にした場合は別です。 次の統計によると、「「ページが見つかりません」というエラーが 1 回発生しただけで、約 74% の訪問者がサイトを離れ、二度と Web サイトにアクセスしません。 それらは大きなオッズではありません。

私たちは今までにあなたを驚かせたと確信しています。 では、どうすればこれらの不幸な結果を防ぐことができるでしょうか? 最終的には、会社の規模、収益、およびリソースを確認する必要があります。

小規模な商人 – Magento はあなたに適していますか?

Magento 2 の開始に伴い、Magento 1 Community Edition を実行している多くの小規模マーチャントから、BigCommerce や Shopify などのサービスとしてのソフトウェア (SaaS) プラットフォームを使用することでより適切に対応できる移行の見積もりリクエストを受け取りました. これらの企業は、その多くの機能と柔軟性のために Magento を実行することに魅了された可能性がありますが、Magento を維持するためのコストは、これらの SMB の能力をはるかに超えています. Magento が成長のエンジンとして機能する代わりに、それは負担となり、これらのマーチャントは、アップグレード、パッチ、およびサポートのマーケティングに専念すべき貴重なリソースを費やさざるを得なくなります。 維持費が(一般的に)高すぎることに加えて、これらの加盟店は Magento を適切に管理するためのリソースを社内に持っていないため、ROI がさらに低下します。

私たちの意見では、通常、年間オンライン売上高が 500 万ドル未満の小規模から中規模のマーチャントは、Magento のカスタム モジュールの使用を 10 以下に制限することをお勧めします。 この数値は多少恣意的ですが、安全に処理できる以上のカスタマイズを行うリスクを軽減したいマーチャントにとっては良いベンチマークです。

オンライン販売額が 100 万ドル未満のマーチャントのほとんどは、Shopify や BigCommerce などの SaaS ソリューションが最適です。 SaaS を使用しているこれらのマーチャントが、パフォーマンスの問題や互換性のバグのリスクを安全に軽減しようとしている場合、既存のテンプレート化されたテーマと 5 つ未満のアプリを活用することを検討する必要があります。

大規模な加盟店 – 過剰なカスタマイズのバグに無防備ではありません

大規模なオンライン マーチャントは、Magento のような Web サイト プラットフォームを適切に運用するための予算と技術的な洞察力を備えていますが、あまりにも多くの機能やカスタマイズを追加することによる深刻な損害を無防備ではありません。 残念ながら、大規模なマーチャントが機能やカスタマイズが多すぎると、Magento の有効性が大幅に低下するのを目の当たりにしました。 このような状況では、Magento で新しいサイトを構築する際に、強気の経営陣が (新しいより良いサイトの立ち上げで大きな注目を集めようとして) 過剰な量の機能とカスタマイズの追加を要求することが何度もありました。

ウェブサイトに多数の複雑な機能を必要とする大規模なマーチャントの場合、パフォーマンスとコードの互換性の問題を最小限に抑えるために、カスタマイズが疎結合され、Magento API とのインターフェイスによって動作することをお勧めします。 たとえば、複雑な送料見積もりの​​要件を解決したいマーチャントは、サードパーティのアプリShipperHQを使用することで、過剰なカスタマイズのリスクを軽減できます。 ShipperHQ は、わずかな拡張コードと API を介して Magento に統合する SaaS ソリューションです。 したがって、アプリは非常に疎結合であるため、コードの競合やパフォーマンスの低下を引き起こすリスクは最小限に抑えられます。

カスタマイズは怖くない

カスタマイズは威圧的になる可能性がありますが、そうする必要はありません。 Magento の拡張機能を恐れる必要はありませんが、むやみに信用しないでください。 すべての拡張機能が同じように作成されているわけではありません。 これらのガイドラインに従い、使用前に上級開発者の精査と拡張機能のテストを厳格に行う限り、慎重に進めることができます。 いつものように、これについて質問がある場合、またはカスタマイズで頭がいっぱいになっている場合は、今すぐお電話で Magento 開発者にご相談ください。