大阪 神戸 西宮 ホームぺージ制作

ラフデザイン株式会社 Web制作ガイドライン

2021/05/04

この記事の投稿者

カンスケ

no image

<第1版>

改訂履歴

版数発行日改訂内容
第1版2021/11/1初版発行
第2版2021/11/183.3.1アクセシビリティ「配色」追加
第3版2022/3/3010.4 「reCAPTCHAの導入」追加

この記事の目次

本ガイドラインについて

ガイドラインの目的

本ガイドラインは、ラフデザイン株式会社が行う Web サイト制作全般においての品質を保持するために定めたものであり、当社が本ガイドラインに基づいた Web サイト制作を行うことで、クライアントに対して常に安定した品質の納品物を提供するために策定されている。

本ガイドラインはプロジェクトの開始から納品までの各段階について、プロジェクトメンバーが考慮すべき、または守るべき指標をまとめたものであり、クライアントに対して当社の制作ガイドラインを示す際にも使用される。各プロジェクトメンバーは本ガイドラインに基づいた制作を行い、クライアントに対する一連のサービス提供、及び納品物の品質にばらつきが生じないよう努める必要がある。

なお、本ガイドラインによって策定された内容も、クライアントとの協議の結果、もしくはプロジェクトの円滑な進行、クライアントのビジネスゴール達成のためにより最適な方法がある場合は必ずしも順守する必要はない。ただし、その決断に至った経緯や結果に関しては必ず社内にて情報共有し、必要に応じてガイドラインの改善に役立てるものとする。

本ガイドラインで扱わない内容

また、コーディングにおいて、HTML や CSS をはじめとした Web 標準技術は W3C の各仕様に基づいて正しく使用することを前提としており、本ガイドライン内のコーディング規則ではその詳細について取り扱わない。

参考:https://validator.w3.org/

※コーディング後、W3Cのコーディング規約に基づいたソースコードになっているか、上記サイトで確認すること。

 

サイト設計・ディレクション

基本

ディレクターはクライアントから指定の Web サイト要件を満たし、Web サイトのビジネスゴールを達成するため、適切な情報提供、提案を行う、また Web サイトの情報設計からプロジェクトの進行管理、プロジェクトメンバーの業務管理、納品物の品質管理を適切に行うものとする。

ディレクターはクライアントを含めプロジェクトメンバー間でのコミュニケーションを積極的に取ることで円滑なプロジェクト進行を心がける。また、クライアントに対しては進捗の報告、情報共有を適時、および明確に行い、信頼関係の構築に努める。

プロジェクトキックオフ

新規 Web サイト制作案件立ち上げに際して行われるキックオフミーティングについては、下記の要領を基本として開催できれば理想(StartUPなどの低価格プランは除く)。受注額とコストとの兼ね合いを鑑みて開催を検討、提案する。

クライアントとの間では現状の把握、ゴールイメージの共有、プロジェクト進行におけるスケジュールを含めた認識の共有を主な目的とする。

また、社内のプロジェクトメンバー間においては、現状の把握、ゴールイメージの共有、スケジュールの共有の他、要件の確認に伴い、事前の意見交換を目的とする。これは例えば「事前に実装担当者、デザイナー、プログラマが知っていればもっと効率よくやる方法があった」「こうしておいてくれればもっと作業がしやすかった」といった無駄をなくすことで、生産性を高め、納期の短縮や品質の向上でクライアントに還元する。

クライアントと行うキックオフ(一例)

  • プロジェクトの要件確認
    • 求められる動作環境や検収条件などの確認
    • 納品物の内容や納品形態についての確認
    • 開発言語、環境の指定やその他要件の確認
  • プロジェクトの対象となる Web サイト等のユーザー層、ターゲット層の理解(必要に応じて下記を実施)
    • ユーザーのセグメンテーションとペルソナ
    • ユーザーインタビュー
    • カスタマージャーニーマップ
    • 既存 Web サイトが存在する場合はその分析
      • アクセスデータ解析
      • ヒューリスティック評価
      • ユーザビリティテスト
  • クライアントビジネスの理解
  • スケジュールの共有
  • 議事録の作成 (プロジェクトメンバー間で共有すべき決定事項などは 「ヒアリングシート」 としてまとめる)

社内キックオフ(一例)

  • プロジェクトの要件確認
    • 求められる動作環境や検収条件などの確認
    • 納品物の内容や納品形態についての確認
    • 開発言語、環境の指定やその他要件の確認
  • プロジェクトの対象となる Web サイト等のユーザー層、ターゲット層の理解
  • 既存 Web サイトが存在する場合はその分析結果の共有
  • クライアントビジネスの理解
  • スケジュールの共有
  • 議事録の作成

 

ドキュメント

制作過程でディレクターが作成する標準的なドキュメントは下記の通りとする。フォーマットは問わないが、クライアント環境で問題なく閲覧ができること。(当然、プロジェクトに応じて必要なドキュメントは変化する。)

  • ヒアリングシート (キックオフミーティング時に確定した内容などをまとめたもの)
  • スケジュール案(WBSや簡易のマスタスケジュールなど)
  • サイトマップ
  • ワイヤーフレーム
  • 導入プロダクトの操作マニュアル(状況に応じて)

 

プロジェクト進行における連絡手段

プロジェクト進行中のプロジェクトメンバーとの連絡・情報共有の手段は、バックログを利用する。キックオフ前後、ディレクターがバックログにプロジェクトを作成し、プロジェクトメンバーが招待される。

先に作成したWBS やマスタスケジュールをバックログのガントチャートに反映できれば理想。(例:株式会社三和建設プロジェクトのガントチャート)

アクセシビリティ

設計段階からアクセシビリティに配慮する。

例えばカルーセルパネル(数秒ごとに画像や要素がスライド等で差し替わる UI )は数秒間で要素内に記述されたテキストを把握できない可能性や要素が切り替わるまでの間に正しく操作できない可能性もあり、重要なナビゲーション機能をカルーセルに持たせるべきではないと考える。

あるいはナビゲーション機能を持たせるのであればカルーセルパネルの動作を一時停止できる仕組みを持たせるなど配慮が必要である。

また、色に依存したナビゲーション、文章の使用は禁止する。例えば「下記の赤い方のボタンを押してください」「文章内の赤い文字は重要項目です」などの表記、あるいは色を選択させるような際にカラーパレットのみで色名のラベルがない等の UI は、一部の色覚障がい者にとっては認識できない可能性がある。UI や文章作成時には配慮するものとする。

操作性

特別、スマートフォン等、画面サイズの小さいデバイスへの対応を行わない場合でも、マルチデバイスで操作しやすい UI を意識して設計する。「スマートフォンサイトではないのでスマートフォンでの操作が困難でも仕方ない」ということはない。

文字サイズの変更ボタン

Web ページ内の文字サイズ変更を Web サイト側で提供するいわゆる「文字サイズ変更ボタン」の提供は原則として行わない。文字サイズの変更はブラウザ UI に任せるべき。

ページタイトルやURL

各ページのタイトル、およびディレクトリ名はディレクターが実装担当に指示すること。実装担当者が勝手に決めたりはしない。

サイトマップ(各ページタイトルや URL を記載した)をワイヤーフレームと同一箇所などに作成(XDにまとめることを推奨)し、実装担当者はそれを基準に各ページを作成する。

必要に応じて、ページ内に記述する <meta name="description" > の値なども決められる場合は記述しておく。

なお、この一覧に CSS や JavaScript 等、ページで読み込まれる各リソースのパス指定などは不要(これらに関しては別途コーディング関連のセクション で定める)。

文言の統一

案件の状況やクライアントの要望により異なるものの、原則的には下記のように Web サイト内で使用する文言を統一する。表記のブレによる品質の低下を防ぐ。

特にクライアントからの明確な指定がなく、迷ったときは、例えば下記を参考に統一する。

  • Webサイトのトップページに移動するリンクのラベル: ホーム (×ホームページ、×トップ)
  • お問い合わせ (×お問合せ、×お問い合せ)
  • メールアドレス (×Mailアドレス、×アドレス、×email、△E-mail)
  • 英数字は原則半角、URLや数値、英単語を全角で記述しない
  • 文章内の全角スペースは半角に統一

その他、サイト内で複数の文言が混在しないように注意すること。

  • 例)弊社|当社、貴社|御社、お客様|クライアント、~します|~いたします …etc

アクセス解析

制作する Web サイトに対して、アクセス解析ツールの導入が必要な際は、クライアントからの特別な指定がない場合、Google Analysis を導入する前提とする。

ディレクターは、Web サイト公開前に必ず Web サイトへの Google Analytics トラッキングコードの設置、及び設定が行われていることを確認する。

また、Web サイトには必ず個人情報保護方針 (プライバシーポリシー) を掲載し、その中で、Google Analysis の使用、およびクッキー (Cookie) を使用したアクセスログ収集に関する掲示を行うものとする。その際、Google 社のプライバシーポリシーページへのリンクもあわせて掲載すること。(詳しくは 個人情報保護方針のセクション を参照)

個人情報保護方針

Web サイトには個人情報保護方針 (プライバシーポリシー) のページを必ず用意する。

(右の引用で可:https://kiyaku.jp/hinagata/privacy.html)

クライアントによってすでに個人情報保護方針が策定されている場合はそれに準じるが、アクセス解析に Google Analysis を用いる場合は、必ず Google Analysis の利用規約に則り、クッキー (Cookie) を使用したアクセスログ収集に関する掲示を追加で行うものとする。

その際、Google 社のプライバシーポリシーページへのリンクもあわせて掲載すること。下記の記述をサンプルとして利用可能。

アクセス解析について

当サイトにおけるアクセスログの収集、および解析には Google Analytics を使用しています。Google Analytics ではクッキー(Cookie) を使用してアクセスログを収集しますが、これは個人を特定する情報を含みません。

なお、収集されるアクセスログは Google 社のプライバシーポリシーに基づいて管理されます。

Google Analytics で収集したアクセスログに関するプライバシーポリシーについては、下記をご確認ください(外部サイト)。

ユーザーが Google パートナーのサイトやアプリを使用する際の Google によるデータ使用

Google 社のプライバシー ポリシー

上記サンプル文章は、下記ページの内容を参考にしたもの。

個人情報保護方針 : バーンワークス株式会社

 

デザイン関連

アクセシビリティ

デザイン時にもアクセシビリティに配慮すること。

配色

背景色とテキストのコントラスト、色覚障がい者向けの配色等に考慮する。

コントラスト(最低限レベル)の達成基準

テキスト及び文字画像の視覚的提示には,少なくとも 4.5:1 のコントラスト比がある。ただし,次の場合は除く(レベル AA)。
a) 大きな文字 サイズの大きなテキスト及びサイズの大きな文字画像には,少なくとも 3:1 のコントラスト比がある。
b) 附随的 テキスト又は文字画像において,次の場合はコントラストの要件はない。アクティブではないユーザインタフェース コンポーネントの一部である,純粋な装飾である,誰も視覚的に確認できない,又は重要な他の視覚的なコンテンツを含む写真の一部分である。
c) ロゴタイプ ロゴ又はブランド名の一部である文字には,最低限のコントラストの要件はない。

WCAG 2.0 解説書から引用

コントラストのチェックに関しては、下記のツール等を推奨。

https://webaim.org/resources/contrastchecker/

 

フォントサイズやボタンサイズ

フォントサイズは、最小サイズを 12px 相当とする。ただし、重要でない注釈等に関しては 10px 相当まで許容する。

現在のディスプレイサイズ等を考慮すれば、標準的なフォントサイズは本文で 14px 相当~ 16px 相当が妥当と考える。(Googleもこれを推奨)その他、ボタンサイズ等についてはタッチデバイスのセクションを参照。

デザインデータ

基本的には Adobe 社の XD を使用して作成するものとする。できる限り最新バージョンのソフトウェアを使用し、プロジェクトメンバー間でのデータ互換性による作業遅滞を避けるよう努めること。

デザインデータには「指示」レイヤーを追加し、リンクカラー(通常、ホバー時、訪問済み、アクティブ時)の指定をはじめ、実装担当者向けの指示の記載があるとベスト。

ディレクター、およびデザイナーはデザインの進行、確定にあたり、実装面からの意見を必ず実装担当者に聞くこと。それにより実装時になってデザインの不具合により手戻りが発生するなどの無駄を省き、実装面の負荷を低減する。(実装担当者が判断できないメンバーの場合(知識・経験が少ない等)は、ディレクター及びデザイナーが判断する。

デザインデータは、レイヤーの分け方や名前の付け方など、他の人が見てもわかりやすいように配慮すること。これは実装担当者の作業効率も向上させる。

スタイルガイド

スタイルガイドの作成を行う。ワイヤーフレームに特に指示がなかった場合でも、各見出しレベルのデザイン(h1~h6)、リスト(ul, ol, dl)、表組み(table)、引用(blockquote)など、頻繁に使用される HTML 要素のデザインはスタイルガイドとして用意する。

また、各要素が配置された際の他要素とのマージンなどもスタイルガイド内にセットする。この際、例えば同じレベルの見出しにもかかわらず、配置される場所によってマージンが異なるなど、1つの要素に複数のスタイルが混在するような事態は避けること。

加えて、デザイン内で使用している基本カラーの一覧、および使用フォントの一覧もスタイルガイド内に記載することが望ましい。

画像素材のライセンス

画像の著作権には十分配慮し、著作権、モデルリリース等の権利関係がクリアされていない、あるいは明確にされていない画像素材の使用は一切禁止。また、画像の使用にあたり、提供元サイトへのリンクが必須の素材 (いわゆるリンクツール)、およびサービスの利用も禁止とする。

素材として使用する画像のライセンスは、原則として「ロイヤリティフリー」のものとする。ただし、クライアントの許可を得た上で、「ライツマネージドライセンス」 の画像素材を購入することは問題ない。

SVG

アイコン、簡単な図版などに関しては、SVG の使用を推奨する。Illustrator等でデータを作成し、SVG での書き出しは実装担当者が行う。実際のデザイン上での表示サイズなどはデザインデータ内で明確に指定すること。

長いテキストの可読性など

行間や行長

Web ページ内に表示するテキストの行間は 140〜190% (line-height: 1.4;  line-height: 1.9;)の値となるように調整する。

1行あたりの文字数 (行長) は、最長で 30~40 文字程度になるよう調整することが読みやすさの点から望ましい。

上記はデザインの要件や文字サイズ等によって変動、もしくは Web ページを閲覧する環境に依存するため、あくまで基準とするが、1行あたりの文字数が極端に多すぎる場合、逆に少なすぎて改行が多すぎる場合などは可読性を低下させるため注意が必要。

デバイスフォントの利用

画像処理が適当である箇所を除いては、なるべくデバイスフォントを使用する前提でデザインすること。また、デザインデータ内では、画像処理すべきテキストとそうでないものが実装担当者にわかるようにする。

Web サイトのパフォーマンス、メンテナンス性や CMS の利用も考慮し、テキストの不要な画像化は避ける。

Favicon

新規構築の Web サイトに関して、デザインには Favicon のデータも含めること。既存のデータがある場合はそれを使用する。サイズは最低限、下記を実装担当者が生成する前提でデザインを用意すること。基本的にはすべて同じデザインとするため、最小サイズでも認識しやすいようにデザインする。

  • favicon.ico (16×16, 32×32, 48×48)
  • favicon.png (64×64)
  • apple-touch-icon.png (152×152)

favicon.png は 64×64 の画像を作成せず apple-touch-icon.png (152px×152px)のファイル名だけ変更して同じ画像を使用してもよい。 実装担当者は上記サイズの画像をデザイナーのデータを基に生成する。例えば下記など。

参考:https://favicon-generator.mintsu-dev.com/

スマートフォン関連

基本

明確にスマートフォン対応が要件に含まれていない案件においても、スマートフォンやタブレットによる操作を想定したデザインや実装が求められる。特に後述するタッチデバイスの特性に関しては十分配慮すること。

画面サイズが小さいデバイスでは、モーダルウィンドウ形式の UI は操作性を著しく低下させる可能性があるため避ける。あるいは画面サイズが小さい場合は無効にするなどの配慮が必要。

タッチデバイス

タッチ操作を考慮したデザインや実装を行うこと。マウスオーバーに依存した UI は避ける他、タッチ操作により表示非表示を切り替えるアコーディオン形式の UI は、数が多くなると操作が煩わしくなるため、はじめからすべて開いた状態にするなど配慮する。

画面の縦サイズが長くなることよりもタッチ操作が多くなりすぎないことを重視すること。

また、タップ可能な要素(ボタンやリンク)には、最低でも 44px × 44px 以上のサイズを持たせること。もし視覚的にそのサイズを持たせることが難しい場合はタップ可能領域を広げるなどして対応する。また、タップ可能な要素同士の間には十分な余白をもたせること(ただし十分にサイズが大きいタップ可能要素同士であれば問題はない)。

タップ可能な要素は視覚的にわかりやすいよう配慮する。

ブレイクポイント

要件説明時に特別な指定がないレスポンシブ Web デザイン対応案件では、ブレイクポイントを 2つ、1024px(タブレット最大幅) と600px(タブレット最小幅)に設定することを基準とする。スマートフォンの最小画面サイズは横幅 320px とする。

ただし、上記はプロジェクトの要件によって変動する場合がある。

高精細ディスプレイ対応

いわゆる Retina 対応。

前提として、スマートフォン向けページのデザインに際しては、レイアウトの基準は、最小横幅を 320px での表示とし、そのサイズで文字サイズやレイアウトが最適化されていること。

ブレイクポイント のセクションで指定されているとおり、複数のブレイクポイントを指定しない案件におけるスマートフォン向けデザインの最大サイズは横幅 768px での表示となるため、320px ~ 768px までの間でデザインの整合性がとれるように配慮する事(この間の画面サイズによってレイアウトが変わるような指定は避ける。要素のサイズ可変で対応する)。

よって、Retina 対応が必要なスマートフォンサイトのデザインデータの作成は、ブレイクポイントとなる 768px の 2 倍の横サイズ(1,536px)で行うこととなる。その際、アイコンフォントや CSS を利用し、極力画像の使用を避けるデザインを心がけることで実装時の負担を低減する。また、Web サイトの表示速度面も配慮すること。

PC 向け Web ページに関しては、Retina 対応は不要とする。対応する場合は画像のファイルサイズ増加に十分注意すること。

コーディング全般

基本

納品は、HTML、CSS、JavaScript 等ファイル、及び画像を含む、Web サイトを構成するリソース一式を、当社管理サーバーおよびクライアントサーバにアップロードした状態とする。別途、指示があった場合はそれに従う。

上記以外に、使用した各種ライブラリ、jQuery や Movable Type 等、CMS のプラグインを 1つのドキュメントにまとめてディレクターに提出すること。

ディレクトリ構成

既存の Web サイトを踏襲する場合やクライアントからの指定がある場合等を除き、基本的なディレクトリ構成は下記の通りとする。

  • documentフォルダ
    • index.html
    • assets
      • css
        • style.css
        • reset.css
      • img
        • common
          • logo.png
        • top
          • image.png
      • js
        • script.js
    • lib
      • css、js等(外部ライブラリ)
        • ◯◯.css

スタイルシートは css ディレクトリへ、同様に、画像、JavaScript ファイルをそれぞれのディレクトリに格納する。画像は全ページ共通で使用するものを common ディレクトリへ、その他は使用するページのディレクトリ構成に合わせて格納する(top、lower等)。外部ライブラリを使用する場合は、libディレクトリを用意しそこに格納することとする。

ファイル名の基本ルール

画像などのファイル名は下記の基本ルールに則って付ける。

  • 区切り文字はハイフン (-) を使用する。
  • 大文字小文字を混ぜず、すべて小文字で付ける。
  • 同じ種別のファイルは頭に同じ接頭辞を付ける。例えば、バナー関連なら bnr- など。
  • 背景画像は頭に bg- という接頭辞を付ける。
  • 例えば同じ内容の画像でサイズが異なる場合はサイズを入れたり (例: example-200x50.png)、デバイスピクセル比を入れたりしてわかりやすくする (例: example-x2.png)。
  • ある class 名に対応する画像は、class 名と同じファイル名を付けるなどわかりやすくするとよい (例: bg-module-section-header.png)。

ディレクトリ構成のルールとあわせて、第三者が見てもわかりやすいファイル名を心がけること。

動作検証ブラウザ

当社が標準で保証する動作環境ブラウザは下記の通りとする。

パソコン

  • Google Chrome 最新版
  • Mozilla Firefox 最新版
  • Safari 最新版
  • Microsoft Edge 最新版

スマートフォン

  • iOS Safari 14.x 以降 (iOS 13 以降)

(以下は状況に応じて)

  • Android 5.x 以降 標準ブラウザ
  • Android 5.x 以降 Chrome

なお、Android OSのバージョンは、グローバルなシェアデータに基づいて決定している。

 

プログレッシブエンハンスメント

上記、動作検証ブラウザに含まれない旧式ブラウザに関しても、最低限必要な操作、情報の取得ができるよう、スタイルシートの調整は行うこと。多少のレイアウト崩れや装飾目的の画像の表示がされないといった問題に関しては気にする必要はない。旧式ブラウザとは主に IE10 ~ IE11 や Android 4.1.x や Android 4.2.x 系の標準ブラウザを指す。

 

文字コード

Web サイトの文字コードは、特別な指定がない限り UTF-8を使用すること。HTML 文書においては、<meta charset="utf-8"> を head 要素内の可能な限り上部 (基本的には最初の子要素として) に記述すること。

インデントルール

インデントを行う場合、タブ文字は使用しないこと。エディタの設定等で 1タブ = 2or4半角スペース に設定し、1階層の字下げは 2or4半角スペースを基準とする。HTML のインデントは任意。CSS は宣言ブロック部分に必ずインデントを入れること。

<!-- 推奨 --> 
<ul>
  <li>HTML</li>
  <li>CSS</li>
</ul>
/* 推奨 */ 
.example { 
  color: red; 
}
/* 非推奨 */
.example {color: red;} 
.example{ 
color:blue; 
}

ただし、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物からインデントや改行が削除されていてもよい。元のコーディングファイル、あるいは中間制作物はこのフォーマットに従うこと。

大文字小文字

HTML の要素名、属性名、および CSS 内のカラーコード等はすべて小文字で統一すること。また、画像をはじめとしたファイル名などでも大文字小文字を混在させたりしないこと。

<!-- 非推奨 -->
<A HREF="/sample/"><IMG SRC="sampleImage.png" ALT="Sample" /></A>

<!-- 推奨 -->
<a href="/sample/"><img src="sample-image.png" alt="Sample" /></a>
/* 非推奨 */
.example {
  color: #E5E5E5;
}

/* 推奨 */
.example {
  color: #e5e5e5;
}

コメント

HTML、CSS、JavaScript 共にわかりやすくコメントを付けること。ただし、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物にコメントが含まれなくてもよい。元のコーディングファイル、あるいは中間制作物にコメントが残るようにすること。

HTML において、要素の閉じタグを認識するためにコメントを入れる場合は、下記のように「/」に続けて該当する要素の class 名、id 名を記述するルールに従う。

<div class="example">
  <p>...</p>
</div><!--/example-->

<div id="example">
  <p>...</p>
</div><!--/example-->

また、HTML 文書内で不要になった要素ブロックや、CSS ファイル内の不要なスタイル宣言等を、一時的な場合を除いてコメントアウトで長い期間運用することは推奨しない。基本的にはリリースの際に削除する。

viewport

viewport に関しては、原則として下記の記述を標準とする。

<!-- 推奨 --> 
<meta name="viewport" content="width=device-width,initial-scale=1.0" />

ユーザーによる拡大縮小ができなくなるため、下記の記述は推奨されない。

<!-- 非推奨 -->
<meta name="viewport" content="width=device-width,initial-scale=1.0,user-scalable=no" />

 

スキームの記述

外部 CDN からの JavaScript ライブラリ読み込み等を行う場合、URI のスキーム(http: / https:)はすべて https:// から記述すること。

ただし、読み込むファイルが HTTPS で提供されていない等、状況によってはこの限りではないが、原則として HTTPS で提供されない第三者サーバからのライブラリの読み込みは禁止する。また配信先ドメイン所有者の信頼性については事前に確認すること。

<!-- 非推奨 -->
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

<!-- 非推奨 -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

<!-- 推奨 -->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

<!-- 推奨 -->
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.11/angular.min.js"></script>

/* 非推奨 */
@font-face {
  url(http://www.example.com/fonts/example) format('woff');
}

/* 非推奨 */
@font-face {
  url(//www.example.com/fonts/example) format('woff');
}

/* 推奨 */
@font-face {
  url(https://www.google.com/fonts/example) format('woff');
}
ライブラリ・フレームワーク

CSS / JavaScript ライブラリやフレームワークの利用はプロジェクトの要件に応じて選択可能。ただし、使用するライブラリやフレームワークに関してはメンテナンスが継続されていること、バグフィックスや脆弱性への対応等が、適切に行われていることを重視して選択すること。

HTMLコーディング

基本・バリデーション

基本的な考え方

HTML はメンテナンス性を考慮すること。各ブロックのモジュール化を意識し、CSS の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても(ul 要素 → ol 要素や段落の追加など)、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。

また、input 要素の type 属性値などについても、属性値を用途に応じて適切に使い分けること(type="mail"type="number"type="tel"type="search" など)。

id 属性は適切に使用すること。セレクタとしての利用も特に制限しないが、多用しすぎてメンテナンス性や再利用性が妨げられてはならない。

バリデーション

各要素は、HTML5 のコンテンツモデルや使用できる文脈に基づき適切に記述すること。またアウトラインが適切かについて必ず確認すること。

確認ツール:https://gsnedders.html5.org/outliner/

また、納品前の HTML ファイルは、必ず The W3C Markup Validation Service によるチェックを行うこと。特に HTML タグの閉じ忘れといったミスは避ける。

アクセシビリティ

JIS X 8341-3:2016 の、適合レベル A に準拠することを社内基準とする。ただし、Web サイトの特性や要件によっては、適合レベル A 対象となる全項目にわたる準拠を必須とするものではなく、また逆に 適合レベル AA、適合レベル AAA 項目を無視してよいということではない。JIS X 8341-3:2016 の全項目に関して適切な知識を持って制作にあたる。

ただ、現状全てを網羅するのは工数がかかりすぎるので、ひとまず段階的に基準を上げていくこととする。

現時点では最低限、下記の事柄についてはクリアすること。

  • 各ページにはページの内容を推測しやすい適切なタイトルを必ず付けること。ページ分割等を行う場合も、(1/2ページ)などとページ数表記を入れるなどして、ページタイトルは Web サイト内で重複しないようにすること
  • 画像には適切な代替テキストを付与する。代替テキストは、画像の内容を具体的に示すものとする(下記サンプル 1)
  • 文字間隔の調整を空白文字を用いて行ってはならない
  • 英単語をすべて大文字で記述することは避けること。text-transform: uppercase; などを適切に使用すること。
  • 略称にはなるべく正式名称を abbr 要素を用いて付与する (下記サンプル 2)。
  • 背景色と文字色には適切なコントラスト比を持たせる。
  • ブラウザによる文字サイズの変更が可能なように実装すること。また、10px 以下のサイズの文字は重要でない注釈等を除いて原則として使用しないことが望ましい。
  • 文字サイズ変更ボタンを Web ページ側で独自に提供しないこと(ブラウザの UI に任せる)。
  • JavaScript が無効な環境を常に配慮すること。アコーディオンメニューなど、JavaScript によって開閉するような UI については、JavaScript が無効だった場合には開いた状態になるなど、重要な操作が JavaScript の無効によって不可能になるような実装は行わない。
  • リンクアンカーとなるテキストは適切に選択すること。アンカーテキストに制約がある場合は、title 属性を併用すること (下記サンプル 3)。
  • リンク領域、ボタンのサイズ等は適切なサイズを考慮すること。また、各リンクのマージンは適切にとり、誤クリックを誘発するような実装は行わないこと。
  • PDF ファイルなど、HTML 以外のフォーマットへのリンクを提供する場合は、そのリンク先のフォーマットやファイルサイズがわかるようにしておくことが望ましい。
  • フォームコントロールは、label 要素を適切に用いてラベルとの関連づけを行うこと。
  • キーボードによる操作を考慮した実装を行うこと。
<!-- サンプル 1 -->
<img
  src="photo.jpg"
  alt="熱海に行ったときに撮影した写真。海をバックに白壁の民家とペットの黒猫が写っています。"
 />

<!-- サンプル 2 -->
<p>
 <abbr title="World Wide Web Consortium">W3C</abbr> は World Wide Web で使用される各種技術の標準化を推進する為に設立された標準化団体です。
</p>

<!-- サンプル 3 非推奨 -->
資料のダウンロードは<a href="/dl/">こちら</a>から

<!-- サンプル 3 推奨 -->
<a href="/dl/">資料のダウンロードはこちらから</a>

また、ある要素 (例えばナビゲーションなど) の位置固定表示 ( position: fixed;) を行う場合は、画面サイズが小さいときなどに画面外に要素がはみ出して閲覧できなくなるなどの可能性を十分に配慮する。

文書型宣言

新規に作成する HTML 文書は、特別な指定がある場合を除いて HTML5 を使用すること。文書型宣言は <!DOCTYPE html> と記述。大文字小文字も左記の通りとする。

 

要素や終了タグの省略

HTML における省略可能な要素、あるいは終了タグの省略は原則として行わないこと。

<!-- 非推奨 -->
<title>example page</title>
<article>
  <h1>Example 1
  <p>This is example page.

<!-- 推奨 -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>example page</title>
  </head>
  <body>
    <article>
      <h1>Example 1</h1>
      <p>This is example page.</p>
    </article>
  </body>
</html>

本セクションにおける 「省略可能な要素」 とは、ある要素のコンテンツモデル上は必須だが、条件を満たすことで記述を省略することができるとされている要素 (html 要素、head 要素、body 要素) がその対象となる (詳しくは下記参考リンクを参照)。記述が任意の要素、例えば table 要素内における thead 要素、tbody 要素などはこの限りではない。

なお、要素に関わらず、終了タグの省略は禁止する。

 

セマンティクス

要素の意味と異なる動作を与えたりしないこと。例えば div 要素や p 要素をクリックすることでリンクとして機能させたりといったことは行わない。リンクを設定したい場合は a 要素を使用すること。

<!-- 非推奨 -->
<div onclick="allEntries();">すべての記事一覧へ</div>

<!-- 推奨 -->
<a href="/all/">すべての記事一覧へ</a>


また、class 名や id 名を要素に付与する際も命名規則にはセマンティクスを意識すること。

<!-- 非推奨 -->
<span class="red">注意してください</span>

<!-- 推奨 -->
<span class="elm-coution">注意してください</span>
class 名や id 名の命名規則に関して詳しくは セレクタの命名規則セクション を参照。

CSS や JavaScript ファイルの読み込み

CSS を外部ファイルとして読み込む場合、パフォーマンスを考慮して 1ファイルにまとめること。また、link 要素に対する media 属性の使用は原則として行わず、CSS ファイル内に @media規則を用いて記述すること。また、原則として CSS ファイル内での @import 規則の使用、および HTML 文書内でのインライン・スタイルの記述は原則禁止する。

JacaScript の読み込みは、script 要素を body 要素の終了タグ直前に記述する。また、可能な場合は async 属性や defer 属性を付与してレンダリングブロックを避ける。

<!-- 非推奨 -->
<link rel="stylesheet" href="base.css" media="screen" />
<link rel="stylesheet" href="grid.css" media="screen" />
<link rel="stylesheet" href="print.css" media="print" />

<!-- 推奨 -->
<link rel="stylesheet" href="style.css" />

<!-- 非推奨 -->
<head>
  <script src="plugin.js"></script>
  <script src="function.js"></script>
</head>

<!-- 推奨 -->
  <script src="plugin.js" async="async" defer="defer"></script>
  <script src="function.js" async="async" defer="defer"></script>
</body>

ただし、async 属性、defer 属性はスクリプトの依存関係等によって正常に動作しなくなる場合があるため、スクリプトの動作を優先してよい。

パフォーマンスのセクション もあわせて参照のこと。

 

メタデータや OGP

メタデータ

<meta name="description"> に関しては、主要なページでは設定しておく事。その際、重複が発生しないように注意。主要でないページで description が重複するくらいであれば最初から記述しない事。

<meta name="keywords"> に関しては特にクライアントからの指定がない限り省略しても構わない。あるいはトップページのみ記述するなどでよい。

OGP

トップページに関しては原則として OGP の記述を入れておく事。その他、商品ページなど重要なページに関してはクライアントとの取り決め、もしくはディレクター、実装担当者の判断で記述する。下記に標準的な OGP 設定のサンプルを示す。

<!-- トップページへの記述例(MT タグ使用例) -->
<meta property="og:title" content="<$mt:BlogName$>" />
<meta property="og:url" content="<$mt:BlogURL$>" />
<meta property="og:description" content="<$mt:BlogDescription$>" />
<meta property="og:image" content="http://example.com/img/1200x630.png" />
<meta property="og:type" content="website" />

<!-- 個別ページ(商品ページやニュース記事)への記述例(MT タグ使用例) -->
<meta property="og:title" content="<$mt:EntryTitle encode_html="1"$>" />
<meta property="og:url" content="<$mt:EntryPermalink$>" />
<meta property="og:site_name" content="<$mt:BlogName$>" />
<meta property="og:description" content="<$mt:EntryExcerpt encode_html="1"$>" />
<meta property="og:image" content="http://example.com/img/article/1200x630.png" />
<meta property="og:type" content="article" />

ページ上部に移動するためのページ内リンク (アンカーリンク) として使用する a 要素の href 属性値には #top を指定すること。HTML5 においては、#top を指定することで自動的にページ上部へのリンクとして機能する。

<a href="#top">このページの上部へ</a>

参考リンク

SVG

スクリプトを伴わない SVG データに関しては img 要素での埋め込みを推奨する。スクリプトを伴う場合は、iframe、もしくは object 要素による埋め込みを推奨。文書内への svg 要素による直接記述は、メンテナンス性の面から推奨しない。

 

CSSコーディング

基本・バリデーション

基本的な考え方

CSS はメンテナンス性と再利用性を考慮すること。各ブロックのモジュール化を意識し、HTML の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても(ul 要素 → ol 要素や段落の追加など)、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。

セレクタによる詳細度を極力高くしないように心がけ、単一セレクタによる記述を基本とする。また、要素セレクタの使用はなるべく避け、HTML 側の変更によって CSS の変更まで行わなければならなくなる事態を極力避けるよう配慮すること。基本的には全てのセレクタにclassを付与することが望ましい。

/* 非推奨 */
.block-header ul.block-main-nav li a {...}

/* 推奨 */
.block-main-nav a {...}

ベンダープレフィックスは、コーディング時に最新となる各ブラウザのバージョンから、2 世代前を基準に、有無を判断する。また、仮にサポートするブラウザが存在しない場合でも、必ず標準仕様に基づいた記述も併記すること。

フォーマット

・CSSは宣言ブロック部分に必ずインデントを入れること。
・セレクタと “{” の間には半角スペースを1つ入れる。さらに、プロパティと “:” は続けて記述し、その後ろに半角スペースを1つ入れた上で、値を記述する。
・すべての宣言ブロック末尾には “;” を付与すること。
・規則集合ごとに1行改行を入れて記述する。
・複数のセレクタをカンマ区切りで記述する場合は、セレクタごとに改行する。
・プリプロセッサやビルドツールによる最終納品物からの改行やインデント等の自動削除は問題ない。

/* 非推奨 */
.example {
color:red;
margin:0
}
.sample{color:red;margin:0}

/* 推奨 */
.example {
  color: red;
}

.sample {
  ...
}

/* 非推奨 */
h1,h2,h3 {
  font-weight: normal;
  line-height: 1.2;
}

/* 推奨 */
h1,
h2,
h3 {
  font-weight: normal;
  line-height: 1.2;
}
バリデーション

W3C CSS 検証サービスによるバリデーションを行うこと。特にスペルミスや記述ミスは確実にチェックし、排除すること。

 

デフォルトスタイルシートのノーマライズ

デフォルトスタイルシートのノーマライズにはNormalize.cssを使用する。

原則そのまま使用するが、加筆や修正案がある場合は社内提案の上許可が降りればカスタマイズを許可する。

 

セレクタの命名規則

セレクタとなる class 属性名、id 属性名は、セマンティクスを意識した命名規則を用いること。また、キャメルケースは用いず、”-“(ハイフン)による連結を原則とする。

/* 非推奨 */ 
.blockHeader {...} 
.mainNavigation {...} 
.red {...} 
.h1 {...}

また、レイアウト、モジュール、テキストへの意味づけ等、用途別に先頭文字列を分類するなど、class 名や id 名からセレクタの用途がある程度推測できるなどが望ましい。

セレクタの命名規則に関しては、現状明確に基準を設けないが、今後の検討課題とする。

 

ショートハンド

極力ショートハンドプロパティを使用する。

/* 非推奨 */
font-family: "Hiragino Kaku Gothic ProN", Sans-Serif;
font-size: 100%;
font-style: normal;
font-weight: bold;
line-height: 1.6;
margin-bottom: 1em;
margin-left: 1em;
margin-right: 1em;
margin-top: 1em;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;

/* 推奨 */
font: normal bold 100%/1.6 "Hiragino Kaku Gothic ProN", Sans-Serif;
margin: 1em;
padding: 0 1em 2em;

ただし、font 関連プロパティのショートハンドに関しては、記述順などが煩雑なことや、スタイルの継承が複雑になる場合もあるため、メンテナンス性や記述ミスのリスクを考慮して、無理に使用する必要はない。body 要素に対しての指定のみにとどめるなど、実装時に判断する。

margin、padding、backgroundなどは推奨。

 

@media 規則

HTML ガイドラインにて、link 要素に対する media 属性の使用は原則として禁止しているため、メディアクエリに関しては CSS ファイル内での @media 規則のみ許可する。

ちなみに、以下が一般的だが、

@media screen and (max-width:600px){}

以下の記述で適用が可能なので、こちらの利用を推奨。

@media (max-width:600px){}

※極力短い記述を行い、レンダリング速度の低下防ぐことが目的。

 

単位などの省略

値が 0 となるプロパティに関しては、単位を省略して記述すること。

margin: 0;
padding: 0;

また、line-height プロパティの値も原則として単位を省略して記述すること。

line-height: 1.5;

値が 0 以下の数値となる場合、0 は省略して記述すること。

opacity: .8; font-size: .875em;

リンクの文字色は、:link:visited:hoverそれぞれに必ず異なる文字色を設定すること。

a { 
 color: #52a437; text-decoration: none; 
} 

a:visited { 
 color: #428bca; 
} 

a:hover { 
 color: #fc4f00; 
 text-decoration: underline; 
} 

a:active { 
 color: #fc4f00; 
}

リンクの下線はデザイン要件により非表示にしてもよいが、文字色などで通常のテキストとの差異を明確にし、リンクがわかりやすいように配慮すること。

 

font-family の指定

font-familyプロパティの指定は下記を標準とする。

body { 
 font-family: "メイリオ", "Meiryo", "ヒラギノ角ゴ ProN W3", "Hiragino Kaku Gothic ProN", Sans-Serif; 
}

z-index の値

z-index プロパティの値は下記の範囲、及びルールに従い指定する。

  • 使用可能な数値の範囲:0~5000 まで、10 刻みを基本とする。
    • 10 刻みとする理由はメンテナンス等でどうしても既存要素の中間となる値を指定しないといけなくなった場合に備えて。
  • スタート数値はある要素群の役割ごとに変えてもよい。
  • オーバーレイなど、確実に他の要素より上部に表示されないと困る要素群に対しては 4000 以上の値を指定する。
  • 大規模サイトで上記ルールでは数値が足りなそうなことが想定される場合はこの限りではない。

 

Web フォントやアイコンフォントの利用

Web フォントやアイコンフォントの利用は可能。特にアイコンフォントに関しては、Font Awesomeを推奨する。

第三者が提供するフォントを使用する場合は、ライセンスのセクションも確認すること。

 

CSS3 プロパティやセレクタ

CSS3 で追加された新しいプロパティなどは積極的に利用して構わないが、多くのブラウザにおいてベンダプレフィックス付きで先行実装されている機能については仕様の変更などの事態に配慮し、慎重に判断すること。

例えば、border-radiustext-shadowbox-shadowlinear-gradientなどについては、ブラウザのサポートも一般的になっているため、特に問題なく使用可能。

なお、サポート対象ブラウザよりも古いバージョンのブラウザに関しては、未対応のプロパティやセレクタを使用することで、閲覧に支障が出るほどレイアウトが大きく崩れたり、アクセシビリティを損ねるような状態になることが予想される場合には、フォールバックを用意すること。

 

中間制作物

ビルドツールやプリプロセッサを使用する場合、最終納品物(Web サイトで読み込まれる CSS ファイル)と、実際に編集している Sass ファイル等の間に、改行、コメントを残し、1ファイルにまとめた CSS ファイルを中間制作物として必ず出力するようにすること。CSS によるコードレビューが必要な場合などに配慮して。

通常は、中間制作物となる CSS ファイルからコメント、改行等を取り除いた(Minify した)ものが最終納品物となる。

 

JavaScript

基本・バリデーション

基本的な考え方

操作、および情報の取得に影響する部分については、常に JavaScript が無効な環境を考慮すること。それらに影響のない、装飾的な部分に関してはその限りではない。

Web サイトのパフォーマンスを重視し、本質的でない不要な処理を入れないこと。例えば古いブラウザ向けに box-shadow を適用させたいからと言って JavaScript で処理するようなことは無駄と考える。

また、jQuery の場合、セレクタの記述でパフォーマンスに影響が出るケースがある。文書内で唯一の要素を操作するのであれば id セレクタを使った方が高速な可能性が高い、またセレクタはシンプルに記述すること。

$('div.sample ul li#item');

$('#item');

バリデーション JSHint による構文チェックを推奨する。

※JavaScriptに関しては基本的にバリデーションチェックは不要とするが、JavaScriptの記述が多い案件などは別途指示の上実施することとする。

.jshintrcの設定例
{ 
"camelcase": true, 
"curly": true, 
"eqeqeq": true, 
"forin": true, 
"immed": true, 
"indent": 2, 
"latedef": true, 
"newcap": true, 
"noarg": true, 
"noempty": true, 
"nonew": true, 
"plusplus": true, 
"quotmark": true, 
"regexp": true, 
"undef": true, 
"unused": true, 
"strict": true, 
"trailing": true, 
"browser" : true, 
"devel" : true, 
"globals": { "jQuery": false } 
}

 

シングルクォーテーションとダブルクォーテーション

統一感の問題から、シングルクォーテーションを基本とする。

$('div').add('p').css('background-color', 'red');

$('div').add('<p id="sample">new paragraph</p>').css('background-color', 'red');

セミコロン

セミコロンの省略は行わないこと。JavaScript ではセミコロンの省略が許されるが、セミコロンの挿入を処理系に任せた結果、自動補完が意図せず行われたり、または行われないことでエラーが発生し、デバッグが困難になる等の問題が想定されるため。

 

変数 / 関数の命名規則

変数名 / 関数名は原則として、キャメルケースを使用する。変数名 / 関数名における「$」は使用禁止。

var firstName = 'taro';

function getListElement() {
 ...
}

定数

定数はすべて大文字で記述し、単語間をアンダースコア(_)で接続する。

var API_KEY = 'b6lC50HCr4mA';

jQuery

jQuery を使用する場合は原則として 3.x 系の最新版を使用すること。jQuery の読み込みは Google Hosted Libraries より行う。

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.x.x/jquery.min.js"></script>

 

プラグイン

jQuery プラグインの利用に特に制限はないが、メンテナンスが継続されていること、軽量であることを重視して選択すること。またプラグインを使用しなくても実装可能な方法があればそちらを優先すること。

また、アクセシビリティやユーザビリティに影響のない範囲での表示誤差 (角丸やグラデーションの有無) のためだけにプラグインを使用するようなことは避ける他、例えばフォームのプレースホルダは placeholder 属性を使用するなど、HTML で実現可能な機能にプラグインを使用したりしない。

プラグインの動作を理由に読み込む jQuery のバージョンを下げることは禁止する。最新の jQuery で動作しないプラグインは利用不可。

 

CMS

プロダクトの選定

WordPressが主。現状他のCMSは検討しなくて良いかと思われる。

 

プラグイン

CMS のプラグイン利用に特に制限はないが、メンテナンスが継続されていること、脆弱性など、不具合への対応が適切に行われていることを重視して選択すること。

プラグインの動作を理由に CMS のバージョンを下げること、あるいは CMS 本体のプログラムの改変を行うことは禁止する。最新のバージョンで動作しないプラグインは利用不可。

 

セキュリティ

強固なパスワード

CMS インストール時のアカウント設定など、新規でアカウントを設定する際は推測されにくいアカウント名、および強固なパスワードを設定すること。

パスワードは 12 桁以上が望ましいが、状況に応じて 8 桁以上であれば許容する。必ず英数字を混在させ、数字だけのパスワードや英単語によるパスワードは禁止する。また、同一のパスワードを複数のサービスやアカウントで使い回すことも禁止。

上記は、クライアントの要望によらず厳守すること。

推測されやすいアカウント名の例

  • admin
  • root
改善案
  • example-admin(”example” 部分はクライアントに応じて変えるなど)

不適切なパスワードの例

  • 12345(数字のみ/桁数も不足)
  • companyname(社名そのままなど)
  • 0312345678(電話番号など外部からわかりやすいもの)

強固なパスワードの例

  • oGZ2BL0ZLjl@

管理画面のパスワード保護

サーバに設置した管理画面をもつプログラムへのログインページは、可能な限りパスワードによって保護する。認証方法はベーシック認証でよい。状況に応じて IP アドレスでのアクセス制限なども検討、実施する。

参考:https://www.itra.co.jp/webmedia/basic_authentication.html

生成ツール:https://www.luft.co.jp/cgi/htpasswd.php#:~:text=%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF%E8%AA%8D%E8%A8%BC%EF%BC%88Basic%E8%AA%8D%E8%A8%BC%EF%BC%89%E3%81%A8,%E9%96%B2%E8%A6%A7%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%80%82

 

SSL の利用

原則導入する。

サーバへの SSL 導入をクライアントに提案し、見積時に制作費用とは別にべつに計上しておくことが望ましい。

暗号化されていない状態でのデータ送信は原則として行わないこと。

(StartUPホームページ制作プランはこの限りではない。)

 

reCAPTCHAの導入

WordPressプラグインのコンタクトフォーム7を導入しているサイトの場合、セキュリティ対策として原則reCAPTCHAを導入する。

バージョンはv3を利用する。

自動生成されるreCAPTCHAのロゴは、CSSで削除しておくこと。

 

参考:https://webst8.com/blog/contact-form-recaptchav3/

 

パフォーマンス

基本

Web ページの表示速度、反応速度に関して、フロントエンド側で対応できる部分に関しては可能な限り配慮すること。(ここは現状自社の課題であり、課題認識を持ち日々改善にあたる。良案があれば社内で共有すること。本ガイドラインに記載した事柄は、原則全て実施すること。[2021/11])

HTML 側での配慮

HTML での配慮については、CSS や JavaScript ファイルの読み込みのセクション を参照のこと。

パフォーマンスチェック

PageSpeed Insights によるパフォーマンスチェックを必須とする。目安は PC で 85 点以上、モバイルで 80 点以上。

ただしこれを下回った場合でも、すでにやるべきことができているのであれば問題はない。特にスマートフォン向けに最適化されていないサイトのモバイル項目の数値は低く出るので、実機テストにおいて著しく操作性が低いといった問題がない場合は不問とする。

パフォーマンス向上のヒント

以下のセクションで説明する。

画像の最適化

画像は基本的に PNG 形式の画像を使用すること。ただし、写真に関してはJPEG形式を使用。画像は、下記等の最適化ツールを用いて、必ずファイルサイズの最適化を行う。

PNG

JPEG

JPEG 画像は、retina 対応(表示サイズの 2 倍サイズで画像を用意)した上で、画像の圧縮率を高くするという方法が、見た目とファイルサイズのバランスで最もよい場合がある。

 

CSS の最適化

CSS は必ず1ファイルにまとめ、CSS ファイル内での @import 規則は使用しないこと。また、セレクタは簡略に記述し、スタイルの上書きが頻繁に行われないように配慮することでパフォーマンスは向上する。

Sass 等を使用する場合は、ネストが深くなりすぎないように注意。またはメディアクエリが複数の場所に分散したりしないように配慮すること。また、実際にページで読み込まれる CSS は必ず Minify すること。

また、メンテナンス等により、使われていないスタイル宣言が大量に残ったままになるなど、ファイルサイズを無駄に肥大化させる記述は、ツールなどを用いてなるべく早期に排除するよう心がける。

 

JavaScript の最適化

jQuery プラグインを複数使用する場合は、なるべく 1 ファイルにまとめること。実際に読み込まれる JavaScript は必ず Minify し、ファイルサイズを最適化すること。

Google Analysis のトラッキングコード、各 SNS のシェアボタン系コードなどは、必ず最新のコードを使用すること。また、CSS や JavaScript ファイルの読み込みのセクション を参照し、async / defer 属性を可能な限り使用する。

 

Google タグマネージャ

可能な限り、Google タグマネージャの利用を推奨する。Google Analysis のトラッキングコードも Google タグマネージャから配信すれば個別にコードをページに入れる必要はない。(参考記事

 

サーバサイドでの設定

下記の設定がサーバ側で可能な場合はできる限り行うこと。

圧縮転送

gzip によるファイル圧縮は、Web サーバ側で mod_deflate が有効であれば .htaccess に下記の記述で有効にできる。

<ifModule mod_deflate.c> 
 SetOutputFilter DEFLATE 
 BrowserMatch ^Mozilla/4 gzip-only-text/html 
 BrowserMatch ^Mozilla/4\.0[678] no-gzip 
 BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html 
 SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary 
 SetEnvIfNoCase Request_URI _\.utxt$ no-gzip 
</ifModule>

キャッシュ設定

Web サーバ側で mod_expires が有効であれば .htaccess に下記の記述で有効にできる。画像など、一度公開されれば変更される可能性が低いファイルはキャッシュを長めに設定する。

<ifModule mod_expires.c> 
 ExpiresActive On 
<Files ~ "¥.(gif|jpg|png|ico)$"> 
 ExpiresDefault "access 1 months" 
</Files> 
 ExpiresByType text/css "access 10 days" 
 ExpiresByType text/javascript "access 10 days"
 ExpiresByType application/javascript "access 10 days" 
 ExpiresByType image/svg+xml "access 1 months" 
 ExpiresByType font/ttf "access 1 months" 
 ExpiresByType font/x-woff "access 1 months" 
</ifModule>

    情報管理体制

    機密情報の管理

    クライアントから提供された機密情報は、担当者の責任において厳重に管理する。

    また、紙で提供された情報は、不用意に書類ケースに放置したり、シュレッダーにかけずに廃棄したりするようなことがないように注意すること。

     

    その他

    映像、写真、音楽など、他者が創作したものを Web サイトで使用する場合は著作権の侵害を行わないよう十分に注意すること。映像や音楽等、他者が創作したものを公の場で利用する場合は、原則として創作者に対する利用許諾が必要なため、クライアントから提供された素材だとしても、必ず著作権の問題がクリアされているかを確認の上、使用する。

    その他、フレームワークやライブラリをはじめとしたプログラムのソースコード等、ライセンスに則った適切な利用を行うこと。

     

    ライセンス

    案件で使用する JavaScript (jQueryプラグイン等)、CSS (Normalize.css等)、アイコンライブラリのライセンスは必ず確認し、ライセンスの元に正しく使用すること。また、ソースコードに記載されたライセンス表記は削除しないように注意すること。

     

    ブランドロゴ等の利用

    Web サービスなど、ブランドロゴをバナーやボタンに使用する際は、各ブランドロゴの利用規約、ガイドラインを必ず確認し、それに従って利用する事。下記に代表的なブランドロゴの利用規約を挙げる(一部は素材画像やロゴデータのダウンロード時に規約が表示される)。

    以上

    お問い合わせ・ご相談はこちら

    アーカイブ

    健康経営優良法人

    CONTACT
    お問い合わせ

    サービスや見積りのご相談を承っております。お気軽にお問い合わせください。