Webアプリケーションのプログラマは、サイトを公開する前にどのような技術的詳細を考慮する必要がありますか？

サイトを公開する前に、Webアプリケーションの技術的な詳細を実装するプログラマーはどのようなことを考慮する必要がありますか？場合ジェフアトウッドは忘れることができHttpOnlyのクッキー、サイトマップ、および クロスサイトリクエストフォージェリ 同じサイト内のすべてを、私は同様に重要な何の事を忘れてされるだろうか？

他の誰かがサイトの実際のデザインとコンテンツを作成しているような、Web開発者の観点からこれについて考えています。したがって、ユーザビリティとコンテンツはプラットフォームよりも重要かもしれませんが、プログラマーはそのことについてほとんど語りません。心配する必要があるのは、プラットフォームの実装が安定しており、パフォーマンスが高く、安全であり、他のビジネス目標を満たしていることです（コストがかかりすぎず、構築に時間がかかりすぎ、Googleと同様にランク付けされるなど）コンテンツサポート）。

これは、かなり信頼できる環境でイントラネットタイプのアプリケーションの作業を行った開発者の観点から考えてみてください。そして、彼の最初のショットを持ち、大きな悪いワールドワイドウェブ全体で人気のあるサイトを公開しようとしています。

また、あいまいな「Web標準」の応答よりも具体的なものを探しています。特に、あなたがプロのWeb開発者であることを既に指定している場合は、HTML、JavaScript、およびCSS over HTTPがほとんど与えられます。それを超えて、どの標準ですか？どのような状況で、なぜですか？ 標準の仕様へのリンクを提供します。

ここでの考え方は、ほとんどの人がこのリストにあるもののほとんどをすでに知っているべきだということです。しかし、実際にはまだ調べていない、完全に理解していない、または聞いたこともないアイテムが1つまたは2つあるだけかもしれません。

インターフェイスとユーザーエクスペリエンス

• ブラウザは一貫性のない標準を実装しており、サイトがすべての主要なブラウザで適切に機能することを確認してください。最近のGeckoエンジン（Firefox）、WebKitエンジン（Safariおよび一部のモバイルブラウザー）、Chrome、サポートされているIEブラウザー（アプリケーション互換性VPCイメージを活用）、およびOperaに対する最低限のテスト。また、ブラウザが異なるオペレーティングシステムでサイトをレンダリングする方法を検討してください。
• 携帯電話、スクリーンリーダー、検索エンジンなど、主要なブラウザ以外のサイトを人々がどのように使用するかを検討してください。—アクセシビリティ情報：WAIおよびSection508、モバイル開発：MobiForge。
• ステージング：ユーザーに影響を与えずに更新プログラムを展開する方法。1つ以上のテスト環境またはステージング環境を使用して、アーキテクチャ、コード、または抜本的なコンテンツの変更を実装し、何も壊さずに制御された方法で展開できることを確認します。自動化された方法で、承認済みの変更をライブサイトに展開します。これは、バージョン管理システム（git、Subversionなど）および自動ビルドメカニズム（Ant、NAntなど）の使用と組み合わせて最も効果的に実装されます。
• わかりにくいエラーをユーザーに直接表示しないでください。
• ユーザーのメールアドレスをプレーンテキストで入力しないでください。スパムメールで殺されてしまいます。
• rel="nofollow"ユーザー生成リンクに属性を追加して、スパムを回避します。
• 十分に考慮された制限をサイトに組み込む -これもセキュリティに属します。
• プログレッシブエンハンスメントを行う方法を学びます。
• 更新が再度送信されないように、POSTが成功した場合はPOSTの後にリダイレクトします。
• アクセシビリティを考慮することを忘れないでください。それは常に良い考えであり、特定の状況では法的要件です。 WAI-ARIAとWCAG 2は、この分野で優れたリソースです。
• 読んで私は考えてくださいしないでください。

セキュリティ

• 消化するのは大変ですが、OWASP開発ガイドではWebサイトのセキュリティを上から下までカバーしています。
• インジェクション、特にSQLインジェクションとそれを防ぐ方法を知ってください。
• ユーザー入力や、リクエストに含まれるその他のもの（Cookieや非表示のフォームフィールド値を含む）を信頼しないでください。
• ソルトを使用してパスワードをハッシュし、行に異なるソルトを使用してレインボー攻撃を防ぎます。そのようなbcryptの（時間試験）またはscrypt（さらに強いが、新しい（）のように、遅いハッシュアルゴリズムを使用して1、2、パスワードを格納するため）。（パスワードを安全に保存する方法）。NISTはまた、パスワードをハッシュするPBKDF2を承認する」、そして、それはだ、.NETで承認FIPS（詳細はこちら）。避け、直接MD5やSHAファミリを使用しました。
• 独自の派手な認証システムを考え出そうとしないでください。微妙でテスト不可能な方法で間違ってしまうのはとても簡単なことで、ハッキングされるまでそれを知ることすらありません。
• クレジットカードを処理するための規則を知ってください。（この質問も参照してください）
• 使用するSSL / TLS / HTTPSを（資格情報、個人情報、クレジットカード情報などの）機密データが入力されているすべてのサイトのために。Let's Encryptは、役立つ無料の認証局です。
• セッションハイジャックを防ぎます。
• クロスサイトスクリプティング（XSS）を避けます。
• クロスサイトリクエストフォージェリ（CSRF）を避けます。
• クリックジャッキングを避けてください。
• システムを最新のパッチで最新の状態に保ちます。
• データベース接続情報が保護されていることを確認してください。
• プラットフォームに影響を与える最新の攻撃手法と脆弱性について常に把握してください。
• 読むGoogleのブラウザのセキュリティハンドブックを。
• Web Application Hacker's Handbookを読んでください。
• 最小特権の原則を検討してください。非ルートとしてアプリサーバーを実行してみてください。（Tomcatの例）
• 置くrel="noopener noreferrer"と、すべてのユーザが提供するリンク上でtarget="_blank"、このような偽のログインページとして、どこか別の場所にページをリダイレクトから先のページではJavaScriptを防ぐために。詳細情報
• 厳格なコンテンツセキュリティポリシーの使用を検討してください。

性能

• 必要に応じてキャッシュを実装し、HTTPキャッシュとHTML5マニフェストを適切に理解して使用します。
• 画像を最適化する-背景の繰り返しに20 KBの画像を使用しないでください。
• 速度のためにコンテンツを圧縮します。brotli、gzip / deflateを参照してください（deflateの方が良い）。
• 複数のスタイルシートまたは複数のスクリプトファイルを結合/連結して、ブラウザ接続の数を減らし、ファイル間の重複を圧縮するgzip機能を改善します。
• 見てみましょうYahooの卓越したパフォーマンス、サイトのフロントエンドのパフォーマンスとその向上などの素晴らしいガイドライン、たくさんのYSlowののツール（Firefoxの、サファリ、クロムやOperaを必要とします）。また、Googleページ速度（ブラウザ拡張機能で使用）はパフォーマンスプロファイリング用の別のツールであり、画像も最適化します。
• ツールバーのような小さな関連画像にCSS画像スプライトを使用します（「HTTPリクエストの最小化」ポイントを参照）
• ツールバーのような小さな関連画像にはSVG画像スプライトを使用します。SVGのカラーリングには少し注意が必要です。あなたはここでそれについて読むことができます。
• 忙しいWebサイトでは、ドメイン間でコンポーネントを分割することを検討する必要があります。具体的には...
• 静的コンテンツ（画像、CSS、JavaScript、および一般にCookieへのアクセスを必要としないコンテンツ）は、Cookieを使用しない別のドメインに移動する必要があります。ドメインとそのサブドメインのすべてのCookieは、ドメインとそのサブドメイン。ここでの適切なオプションの1つは、コンテンツ配信ネットワーク（CDN）を使用することですが、代わりのCDNまたは代わりに提供できるローカルコピーを含めることにより、そのCDNが失敗する場合を考慮してください。
• ブラウザがページをレンダリングするために必要なHTTPリクエストの総数を最小限に抑えます。
• テンプレートエンジンを選択し、gulpやgruntなどのタスクランナーを使用してレンダリング/プリコンパイルします
• favicon.icoサイトのルートにファイルがあることを確認してください/favicon.ico。HTMLでアイコンがまったく言及されていなくても、ブラウザは自動的にそれを要求します。をお持ちでない場合/favicon.ico、これにより多くの404が発生し、サーバーの帯域幅が消費されます。

SEO（検索エンジン最適化）

• 「検索エンジンに優しい」URLを使用します。つまりexample.com/pages/45-article-title、example.com/index.php?page=45
• #動的コンテンツに使用する場合、を変更して#から#!サーバー$_REQUEST["_escaped_fragment_"]でgooglebotがの代わりに使用します#!。つまり、に./#!page=1なり./?_escaped_fragments_=page=1ます。また、FF.b4またはChromiumを使用しているユーザーにとってhistory.pushState({"foo":"bar"}, "About", "./?page=1");、素晴らしいコマンドです。そのため、アドレスバーが変更されても、ページはリロードされません。これにより、動的コンテンツを保持する?代わりに使用し#!て、このページの後にあるリンクを電子メールで送信するときにサーバーに通知することができ、AJAXは別の追加リクエストを行う必要がありません。
• 「ここをクリック」というリンクを使用しないでください。あなたはSEOの機会を無駄にしているので、スクリーンリーダーを持っている人にとっては物事が難しくなります。
• 持っているXMLサイトマップを好ましくはデフォルトの場所に、/sitemap.xml。
• <link rel="canonical" ... />同じコンテンツを指す複数のURLがある場合に使用します。この問題は、Googleウェブマスターツールからも対処できます。
• GoogleウェブマスターツールとBingウェブマスターツールを使用します。
• すぐにGoogle Analyticsをインストールします（またはPiwikのようなオープンソース分析ツール）。
• robots.txtと検索エンジンスパイダーの仕組みを理解します。
• リクエスト（使用してリダイレクト301 Moved Permanentlyを求める）www.example.comにexample.com両方のサイト間でのGoogleのランキングを分割防ぐために（あるいは他の方法でラウンドを）。
• そこには、行儀の悪いクモがいる可能性があることを知っておいてください。
• 非テキストコンテンツがある場合は、ビデオなどのGoogleのサイトマップ拡張機能を調べてください。これについては、Tim Farleyの回答にいくつかの良い情報があります。

技術

• 理解HTTPおよびGET、POST、セッション、クッキー、とそれが「ステートレス」であることの意味のようなものを。
• あなたの書くXHTML / HTMLとCSSをに従って、W3Cの仕様と、彼らは確認して検証します。ここでの目標は、ブラウザーの奇妙なモードを回避し、ボーナスとして、スクリーンリーダーやモバイルデバイスなどの非伝統的なブラウザーでの作業をはるかに簡単にすることです。
• JavaScriptがブラウザーでどのように処理されるかを理解します。
• ページで使用されるJavaScript、スタイルシート、およびその他のリソースがどのようにロードされるかを理解し、知覚されるパフォーマンスへの影響を検討します。現在、スクリプトをページの下部に移動することが適切であると広く認識されていますが、例外は通常、分析アプリやHTML5シムなどです。
• 特にiframeを使用する場合は、JavaScriptサンドボックスの仕組みを理解してください。
• JavaScriptは無効にできるため、無効になるため、AJAXはベースラインではなく拡張機能であることに注意してください。今でもほとんどの一般ユーザーがそのままにしておいても、NoScriptの人気が高まり、モバイルデバイスが期待どおりに動作せず、Googleがサイトのインデックス作成時にほとんどのJavaScriptを実行しないことに注意してください。
• 301リダイレクトと302リダイレクトの違いを学びます（これもSEOの問題です）。
• 展開プラットフォームについて可能な限り学習します。
• Reset Style Sheetまたはnormalize.cssの使用を検討してください。
• JavaScriptフレームワーク（jQuery、MooTools、Prototype、DojoまたはYUI 3など）を検討してください。これにより、DOM操作にJavaScriptを使用する場合にブラウザーの多くの違いが隠されます。
• 知覚されるパフォーマンスとJSフレームワークを合わせて、Google Libraries APIなどのサービスを使用してフレームワークをロードし、ブラウザーがサイトから重複コピーをダウンロードするのではなく、既にキャッシュされているフレームワークのコピーを使用できるようにすることを検討してください。
• 車輪を再発明しないでください。コンポーネントまたはその実行方法の例を検索する前に。誰かがそれを実行し、OSSバージョンのコードをリリースした可能性は99％です。
• その反対に、ニーズが何であるかを決定する前に、20個のライブラリから始めないでください。特に、クライアント側のWebでは、ほとんど常に常に軽量で、高速で、柔軟性を保つことが重要です。

バグ修正

• コーディングに20％の時間を費やし、その80％をメンテナンスに費やすことになるので、それに応じてコーディングしてください。
• 適切なエラー報告ソリューションをセットアップします。
• 人々が提案や批判であなたに連絡するためのシステムを持っています。
• 将来のサポートスタッフとメンテナンスを行う人々のためにアプリケーションがどのように機能するかを文書化します。
• 頻繁にバックアップを作成してください！（そして、それらのバックアップが機能していることを確認してください）単なるバックアップ戦略ではなく、復元戦略を立ててください。
• Subversion、Mercurial、Gitなどのバージョン管理システムを使用してファイルを保存します。
• 受け入れテストを行うことを忘れないでください。Seleniumなどのフレームワークが役立ちます。特に、おそらくJenkinsなどの継続的統合ツールを使用して、テストを完全に自動化する場合。
• log4j、log4net、またはlog4rなどのフレームワークを使用して、十分なロギングが行われていることを確認してください。ライブサイトで何か問題が発生した場合は、その原因を突き止める方法が必要です。
• ロギングするときは、処理済みの例外と未処理の例外の両方を必ずキャプチャしてください。重要な問題がサイトのどこにあるかを示すため、ログ出力をレポート/分析します。

その他

• サーバー側とクライアント側の両方の監視と分析を実装します（1つは事後的ではなく予防的でなければなりません）。
• UserVoiceやIntercom（または他の同様のツール）などのサービスを使用して、ユーザーと常に連絡を取り合ってください。
• Vincent DriessenのGit分岐モデルに従う

多くのものは、有用な回答ではないため必ずしも省略されていませんが、詳細すぎるか、範囲外であるか、知っておくべきことの概要を探している人には少し行き過ぎているためです。これも自由に編集してください。おそらくいくつかのミスを犯したか、間違いを犯しました。