CSS Nite LP58「Coder’s High 2018」

こちらは、CSS Nite LP58のフォローアップページです。

Facebookイベントページ

なお、ビデオ参加の方には、コンテンツが出揃った後にメールにてもお知らせします。

公開ポリシー

このページは、本イベントの参加者（およびフォローアップ参加者）限定のコンテンツです。 ただし、90日を目安に一般公開する予定です。

Twitterやブログなど

ツイートは下記にまとめました。

次のブログで取り上げていただきました。ありがとうございます。

講演者のブログなど

基調講演：技術トレンドとの向き合い方
中村 勇希（トゥーアール）

基調講演を勤めました中村です。電車遅延で聞けなかった方、早口で聞き取れなかった方、ぜひビデオ配信もご覧ください。
また、今後の情報発信はツイッターで行なっているので、ぜひツイッターをフォローしてください。

@nayucolony

アンケートでの質問やコメントへの回答

技術への好奇心・モチベーション

スキルの低い自分では、自己満足を満たせないというのが一番の原動力です。あとは、すごく尊敬しているデザイナーさんがいつか起業した時に創業メンバーに手をあげられるようになっておきたい！みたいな野望もちょっとあります。長い目で見るとそういうモチベーションはありますが、目先の小さなモチベーションでいうとお給料がたくさんほしいのでできることを増やしたいというのが大きいです。

技術情報のキャッチアップはどうしたらいいか

Twitter で片っ端からフロントエンドエンジニアっぽい人をフォローしましょう。大きめのカンファレンスで登壇している人をフォローし、おすすめユーザーを芋づる式にフォローするのをおすすめします

JavaScript フレームワークは習得しないといけないか

長くなりそうなので記事を書きました

JavaScript フレームワークは、習得しないといけませんか？という質問への回答

java 有償化が JS へ何か影響を与えることがあるか

全く別物なので影響は皆無です。ただ、もし脱 java の流れが来るならば、それに伴い一気にモダン化をすすめようという流れでフロントエンド構築の案件がくるかもしれませんね。

これから様々に自動化が進んでいくことを鑑みると、フロントエンドエンジニアもコードをかけるだけでは生活できなくなる世の中になるのでは？

明日突然仕事がなくなることはありません。しっかりと状況を追っていれば、次の何かに移行することが可能です。何も知らない間に気づいたら取り残されていた、ということを避けるために、広い視野を持って情報収拾しましょう。おすすめはツイッターです。

バックエンドの開発に Vue や React に移行するメリットを上手く理解してもらう方法

SPA のメリットと、開発上のメリットを両方伝えることになりそうです。前者は調べればいくらでも出て来ますが、後者はコストの問題が大きそうですね。私は Vue や React で開発する時にサーバーサイドの環境は特に気にしなくていいので取り掛かりが楽だなぁと思っています。

受託案件では開発プロダクトの技術はどのくらいの期間担保する想定でとりいれているか

特に気にしていません。即リニューアルの判断がくだることもあれば、クローズされることもあります。作り変えることを前提に、その時安定している技術を採用しています。

チームでの知識レベルがバラバラなのだがどうしたらいいか

私は経験が浅く、チームを組むと「チームの中央値より下」のスキル感である場合がほとんどです。ですが、スキルがある人がちょっとしたケアをしてくれていることで、うまくやれていることが多々あります。

また、これらはスキルのあるなしによらず実行可能なことですので、私も心がけるようにしています。

JS に対する苦手意識が払拭できないがどうしたらいいか

こんな本があるみたいですよ。

スラスラ読める JavaScript ふりがなプログラミング

今の会社環境ではデザインから実装まで一通りやっているが、どれかに特化したい。今の環境では難しいと感じる。転職すべきか。

私だったら転職します。複数社話を聞いて見ると本当にどうするべきかみたいなことが見えて来そうです。

組織の都合上、管理業務が多くなってしまい技術のキャッチアップができていない。その中でも、作る現場のキャリアを取っていきたいと考えているが、何から手をつけていけばいいか？

組織としての価値は、マネジメントスキルをつけることかなぁと思ってしまいます。メンバーもそちらの方が幸せですしね。どうしても手を動かしたいのならば、おすすめ書籍であげた本を読んでみてください。転職もありだなとおもいます。

使いやすい、わかりやすい、ものを作ることが好き。今後のキャリアとしてフロントエンドエンジニアか UI デザイナーか悩む。

私はフロントエンドエンジニアですが、UI デザインに関するレビューは積極的に行うようにしています。結局、実装したものが世の中に出るので、そこの責任を担えるという点でフロントエンドエンジニアという仕事は好きですね。一意見としてご参考ください。

学習するためには、目的が必要だと思うが、仕事で使う前提で考えているか

基本的にはわからないことだらけなので、学習しながら仕事に活かしています。そういう意味では、仕事で使う前提ですね。本当は、全体的な実装コストの把握などできるようにサーバーサイドの勉強などもしたいのですが、フロントエンドで精一杯になっているのが現状です。

このフレームワークはこういう案件に良い、というのはあるのか

私は「客先のチームを組むエンジニアが Vue を書いているので」とか「React の現場を多くやってきたので」とかいう理由で決めて来ていたので、社内のメンバーに聞きました。

とのことです。Vue を軸に入門するのがよいのではないでしょうか。

アプリケーション開発のロジックとかデザインパターンとか MVC モデルとかそういうのを理解していないと意味がないと思う

おっしゃる通りですね。見よう見まねで書いたコードが、後から「実は修正しにくい作りになっている」とか「実はもっとスッキリかける」とかいうことに気づきはじめたのが最近で、現在私は設計の勉強をしています。

ただ、それに気づくにはまずは無理矢理でも動かしてみるのが大事かなとおもいます。私の場合、最近設計の本を読んでいると「たとえばあのプロジェクトのあの部分を、こういう風にわけたらいいのかなー」のように、踏んだバッドパターンを例に落とし込めているという現状があります。

JS が苦手な人は JS の基本をやったほうがいいか

基本を完全に理解しないとフレームワークが扱えないとは言いませんが、基本的な記法は理解しておく必要があります。フレームワークを導入しても、結局我々が書くのは JavaScript です。そこに、フレームワークのルールがあるかないか、という話です。

jQuery でアプリケーション開発は難しいのか / フレームワークをつかっても何ができるかピンとこない

jQuery でアプリをつくる = パワーポイントでデザインをする、というたとえでピンときますか？確かに図形もかければ文章もかけます。しかし、シンボル機能もなければ、レイヤー機能、アートボード機能な「デザインをするにあたって必要な機能」が足りません。
実現するには、スライドを複製して人力アートボードにしてみたりと、無理やり作ることになりますよね。ですが、ワイヤーフレームなど、パワポで十分！な瞬間も時にはあると思います。

jQuery でアプリをつくるというのは、それに近いです。フレームワークでは、パーツごとに

などを明示的に設定することができます。また、アプリケーション開発における「あるある用途」が最初からいい感じに使えます。もしもフレームワークを使用しない場合、コメントを書いて構造化を頑張ったり、「あるある用途」を人力実装したりすることになってしまいます。ツールがあった方がいいですよね。

storybook を使っているか

一回だけ使ったことがありますが、管理コストがかかるのでビジュアル設計がしっかりしているプロジェクト以外で導入してもあまり意味ないだろうなあと思います。
逆に、ビジュアル設計がしっかりしていれば、完全なる動くドキュメントになるので、管理コストを支払ってでも導入する価値はあるでしょう。

妊娠、出産のキャリア

この辺の情報確かにないですよね。私も当事者ではないのであまり考えたことはなく。福利厚生に恵まれた会社の女性エンジニアのツイッターをフォローしておくといいと思いますよ。

初心者にオススメの本

以下がおすすめです。

JavaScript

Vue.js

ダウンロード

コーダーとデザイナーの溝を埋める、業務改善のタネ
水越 佑介（リーグラフィ）

コーダーは、プロジェクトの中盤で活躍するポジションのため、上流からの要件変更やスケジュールの調整によって、苦労されている方も多いと思います。ですので、一つ上流にあたるデザイナーとの関係性は、特に重要です。

アンケートで頂いた貴重なご意見、ご質問に関して

ご紹介した事例に共感していただけた方が多かったのですが、一方で「デザイナーがやるべきことをコーダーが負担するのはちょっと…」と感じた方もいらっしゃったようです。実際の現場では、デザイナーやディレクターからの「歩み寄り」が必要不可欠です。例えば、Adobe XDのデモでお伝えした「レスポンシブの状態を確認する」については、デザイナーの方からアプローチしてもらった方が、より確実です。無理にデザイナーが担当する業務領域に踏み込む必要はありません。

（質問）各ロールの役割が曖昧になりそうですが？

役割分担については、プロジェクトによりますので、進行管理を統括するディレクターと相談してください。デザイナーからの歩み寄りが期待できる場合は、例えばふんわりした指示ではなく、具体案をデザイナーの担当領域として意識してもらってください。

（質問）気持ちコーダーに負担かけすぎでは？
（質問）コーダー側がかなり譲歩している印象でしたが、コーダー側から教育という部分では何かされていますでしょうか？

デザイナーとの協業の中で発生する「溝」を、全てコーダーが埋めることは、現実的に難しいでしょう。デザイナーが負うべき責任範囲も当然ありますので、遠慮なくデザイナーにコミュニケーションをとり、できるところはやってもらって構わないです。デザイナーが苦戦しそうなテクニカルな部分をコーダーがサポートできれば、良い関係が気づけて、お互いの負担が減るのではないかと思います。
教育という言葉が適切かわかりませんが、特にコンポーネント思考については、デザイナーにもコーダーにも共通して理解を深めるよう配慮しています。

（感想）数値でフィードバックをもらわないというやり方に、少しとまどいました。

フィードバック自体が明快で、完成後のイメージを改めて共有するまでもないシンプルな問題の場合は、数値でのフィードバックは効率的でベターですね。
でも、デザイナーにとって、その数値が想定外だった場合はどうでしょうか。改めてデザインを検討し、コーダーに返すことになります。この手間をデザイナーが負担するか、コーダーが負担するかの問題は「役割分担」の話になります。

（質問）コーダーから見るとミスに見えるが、デザイナーは意図していることが多いパターンの例はありますか？

このようなデザインに対しては、アクセシビリティや表示速度の観点で不都合になるケースが多いので、デザイナーに確認したいですね。

（質問）コミュニケーションがとれないデザイナー・コーダーとのやりとり、先回りする行動など知りたかった。

デザイナーとコーダーが全く接触できないということであれば、体制を見直してみてはいかがでしょうか。

（質問）デザイナーが気分屋の場合は？
（質問）Web制作にアジャイルはないか？

コーダーにデザインデータが渡った後でデザインがころころ変わるということであれば、その意図をまず確認してください。そもそもプロジェクトの進行の仕方に問題があるか、プロジェクトの根本部分がぶれている可能性が高いですが、アジャイル的な開発の進め方をしている場合は、そうとも言い切れません。ディレクターに協力してもらいましょう。

（質問）XDでは細かいことができなさそうと考えて、Photoshopばかり使っています。全てXDでデザインするのでしょうか？

同様の質問を多数いただきましたが、XDだけでデザインカンプの全てを完遂することは、あまりありません。写真加工やPhotoshop、ロゴなど文字間隔を調整する場合はIllustratorというように、適材適所でツールを使い分けます。

（質問）社内全てにAdobe XD導入って、お高いんでしょう？

Adobe XDは、一部機能が制限された無料版があります。（2018年9月現在）詳細は 「プランを比較する | Adobe XD」をご覧ください。

（質問）XDはSketchよりいいですか？

どちらが優れているかということについては、どちらも優れているとしか言えないです。個人的にはXD推しです。デザイナーやディレクターにとっても、とっつきやすいツールです。

（質問）デザインカンプをPhotoshop8割、Illustrator2割で作っている環境です。今後、制作において、InDesignを使用した方がいいと思いますか？その理由はありますか？

InDesignをウェブサイトのデザイン制作に利用した経験がなく、「使用した方がいいかどうか」の判断はできかねます。

（質問）デザインガイドはどのように作られていますか？

色々な手法があるかと思いますが、弊社では主にAdobe XDで、クライアントに向けて作成しています。ウェブサイトのUI策定の基準になると説明し、合意を得ておくケースが多いです。タイミングとしては、コーディングよりも上流の「UI要件」で作成します。

（質問）スライドで使用しているフォント気になる…

フォントは「筑紫A丸ゴシック」です。ちなみに、イラストは、Adobe Stockの「jesadaphornさんのポートフォリオ」から選ばせていただきました。

（質問）画面共有をするサービスを、もう一度教えてください。

appear.inです。非常にシンプルで、簡単に無料で利用できるのでおすすめです。
チャットや画像の共有のみでしたら、チャットワークやSlackといったアプリケーションもいいと思います。いずれも弊社では実案件で利用しています。

ダウンロード

実案件から学んだフロントエンドにおけるアクセシビリティ対応
植木 真（インフォアクシア）、秋山 豊志（コンセント）

秋山 豊志（株式会社コンセント）

セッション3「実案件から学んだ フロントエンドにおけるアクセシビリティ対応」の発表をしました秋山です。
「植木さんのアクセシビリティセッション」として笑いを期待されていた方、今回は笑いポイントが控えめでごめんなさい。

普段、自分達が何気なく行なっているマークアップ。
CSS や JS の表現力の強さに目を奪われがちですが、「情報の提供」という側面においてはマークアップ以上に重要なことはないと言っても過言ではありません。
表現、機能の都合を優先しそうにになることもあるかもしれませんが、そこをぐっとこらえて情報構造としての正しさとの両立を目指してください。

また、基本の「キ」「ホ」の中には、一部、コンテンツについて言及しているものも含んでいます。
これらは「コーダーが考えるものか？」と問われれば、自分は「違う」と答えます。
ただし、「コーダーが担保するものか？」であれば「イエス」と答えるでしょう。
視覚的に表現されない情報の有無にいち早く気付くことができるのもコーダーだからです。
あるべき情報が不足していた場合、コーダーが積極的に声をあげ、周りと連携をとってコンテンツをアクセシブルにするために行動する必要があると考えています。

今回のセッションで情報を提供すること、改めて「マークアップすること」の大切さに気づいていただけたのであれば幸いです。

植木 真（株式会社インフォアクシア）

セッション開始前に「アクセシビリティに取り組んでいる人？」という問いかけに手を挙げた人は、全体の1～2割程度でした。

でも、スライドを入手したら、基本の「キ」や「ホ」で紹介した合計20項目のうち、普段自分が意識していることが幾つあるか改めて数えてみてください。きっとゼロという人はいないと思います。「アクセシビリティ」だと思っていなかったとしても、半分の10項目くらいは意識している人が大半ではないでしょうか。

全国各地で「Webアクセシビリティの学校」を開催しているのですが、アンケートで最も多くいただくコメントが「意外と普通のことが多くて、イメージが変わりました」、「何気なくやっていたことに意味があることを知りました」というものです。今回の基本の「キ」と「ホ」でも、そんなふうに感じた方も多かったのではないかと思います。

2020年にオリンピック、パラリンピックが控えているせいか、アクセシビリティを確保していきたいという企業が増えています。弊社でも案件は増えてきているのですが、対応できるスキルを持った制作会社さんや制作者さんが不足しているのが現状です。今回のセッションで興味を持った方がいらっしゃっいましたら、スキルアップの1つのテーマとしても「アクセシビリティ」を意識してもらえたらと思います。

100点じゃなくていいんです。まずは、基本の「キ」と「ホ」の中で、1つでも2つでもいいので、できることから実践していきましょう。ウェブを今よりもマシンリーダブルにしていけるのは、コーダーの皆さんなのですから！

アンケートでのご質問への回答

Q1. 間違ったコーディング例はdiv要素の場合でしたが、section要素でも同じなのか気になりました。

section 要素を利用する場合においても、div 要素と同様の結果となります。スクリーンリーダーは、現時点ではsection 要素による情報のまとまりをユーザーに伝えることができません。

要素の意味から考えると「section 要素で情報のまとまりを示せる 」と考えるのは妥当ではあるのですが、アクセシビリティの観点からは見出し要素を情報のまとまりの起点とする方が、より幅広い環境へとアプローチできます。ただし、上記は「 section 要素を利用しないでください」というものではありません。

それよりも、単純に「画像1、見出し1、本文1、画像2、見出し2、本文2、...」という順序でHTMLコードに記述されていると、スクリーンリーダーはその順序通りに読み上げていくので、例えば「画像2」が「見出し1」のコンテンツであるかのように聞こえてしまいます。そういった読み上げ順序を考慮しても、見出しの前に情報を伝えているコンテンツがあることは好ましくないといえます。

例えば、同じように見出しの前に画像がある場合でも、情報を伝えていない装飾の画像であれば、alt属性を空にしたり、CSSのbackground-imageプロパティを使ったりすることで十分なこともあるでしょう。

Q2. alt属性は長くてもいい、最近はそうなったんですね。今はlongdesc属性は使わないのでしょうか？

longdesc 属性は「サポートしている環境が非常に少なく、longdesc 属性を利用してもユーザーに情報の提供ができない」状態です。そのため、代替テキストの提供手段として longdesc 属性の利用はお勧めできません。
（また、html5 でも img 要素の longdesc 属性は廃止されています）

少し古いのですが、下記に longdesc 属性のサポート状況が記されています。仕様上は正しかったとしても、ブラウザや支援技術によるサポートが十分でなければ、ユーザーはそのコンテンツを利用できないことに注意する必要があります。
https://waic.jp/docs/as/info/201406/H45.html

Q3. 意味のない要素（例: ULリストの行頭記号）にCSSのcontentプロパティを使用するのはアリでしょうか？

「アリ」です。

ただ、注釈で頭に利用する ※ （米印）は、悩ましさがあります。「参照元と参照先で、一対に ※ （米印）を存在させる」という観点で、秋山は「※」を content プロパティで表現しないようにしています。

Q4. ハンバーガーメニューのbutton要素はフォームの送信用だからダメだと言われたのですが？

ご指摘ありがとうございます。
button 要素を submit として利用させないようにするためには、type 属性の指定が必要でした。
下記のように訂正させてください。

<button type="button">メニュー</button>

また、リンクを強調するために、見た目を「ボタン」的に表現する場合もあります。
この場合は下記のように a 要素を使っていただいて大丈夫です。

<a href="#" class="button">リンク</a>

ダウンロード

コーダーも知っておきたい解析事情 2018
井水 大輔（エスファクトリー）

『コーダーも知っておきたい解析事情2018』のセッションを務めました井水@190cmです。

質問させていただたた際に普段は解析に関わっていない方が半分ほどいらしたので、ちょっとドキドキしました。

しかし、終わってみればアンケートでは「解析は必要だと思った」「タグマネ使う!」「データ活用の重要さがわかって興味がわきました」など、多くの意見をいただきウェブ解析に興味持ってくれた方が増えてうれしい限りです。ありがとうございました。

アンケートでいただいた質問に関して

（質問）GAのグローバルサイトタグは<head>の直後とありましたが具体的には<title>の上とかでしょうか？

（質問）タグマネージャーのタグ、「<head>のできるだけ上の方に入れて」って言われたんだけどそれも<head>直後でいいんかな？

<head>のなるべく上の方がいいのですが文字コード指定の前にくるとよくないので <meta charset="UTF-8" /> の直後がベスト位置です。

（質問）タグマネのタグを</head>の直前に入れてますが大丈夫でしょうか？

基本的には<head>直前でも問題なしです。

Optimize系のタグをGTM（グーグルタグマネージャー）で入れる場合には、なるべく早くタグを読み込む必要があるので、head要素のなるべく前にします。グローバルサイトタグも基本的には問題ありません。

（質問）電話タップは測定できますが、発信までは測定できないのでしょうか？

発信は測定できません。あくまでタップした回数が計測さるので誤タップやその後、電話がつながらなかった回数も計測されてしまいます。

（質問）WPでヘッダー（header.php）に共通でいれている電話ボタンでもページごとにトラッキングできるのでしょうか？

（質問）TELクリック計測で、ヘッダーやフッターのような共通ファイルで同じコードの場合はどうやって分析するのか知りたい。

タグマネを使用するとページのURLを合わせてひっぱってくることができるので同じIDをふっていてもどのページで電話ボタンがタップされたか計測が可能です。

（質問）タグマネージャーを勉強するための書籍やサイトはありますでしょうか？

ウェブで読めるコンテンツとしてはGoogle公式タグマネージャーヘルプがあります。

ただし、文章が多く実際設置するとなると不明点がでてくるかもしれません。そんなときには「GTM＋設置したいタグの名称」で検索すると関連ブログを見つけやすいです

。タグマネに関する書籍は現在2冊でています。

（質問）昔からアナリティクスが入っているサイトにgtag.jsを足してくださいといわれれることがあります。2つタグが入っていても平気ですか？

同じプロパティIDのGAタグを同時に設置すると2重計測となりPVが2倍になったり直帰率が0になったりするので要注意です。

（質問）「ここにタグいれますか？」とか上流工程のときに聞いてもタグがくるのが遅いです。何の情報と一緒に渡して聞けば実装前にタグを発行してくれますか？

スケジュールの共有の際にタグの受け渡し日程も含めるとよいです。

〇〇日を過ぎると手間が増えるのでスケジュールがずれ込む可能性があるという認識を持っていただくと遅れることは少なくなると思います。

（質問）さまざまなチームでページの作成を行う環境で、それぞれがデータを取得したい場合使用する変数の管理をするのに良い方法はありますか？

今回少しだけしたお話しした取得設計書を使うと良いでしょう。

フォーマットは各チームが使いやすいように作ると良いと思いますが、一覧で確認できるシートを皆さんで共有することで重複や抜け漏れなどのミスを防ぐことに役立ちます。

（質問）GAをいれていますが、サーバーのアクセスログの方が正確だからとデータ抽出を依頼されていて、どうしたらよいか悩んでます。実際のところデータの正確性はどの程度あるのでしょうか？

おそらくサーバーログはリクエストがあった時点でアクセス情報を記録するので正確性が高いといわれていると思いますがそこでいう正確性よりどんな値を取得したいかの意見を聞いてみてはいかがでしょうか？

今回お話したようなGAでないと取得できないデータを活用したい場合はそもそもサーバーログ方式だとむずかしいという話ができそうですし。

またGAのようなウェブビーコン方式（ブラウザのクッキーを利用して計測する方式）とサーバーログ型では取得方式が違うので状況によって正確性が変わります。取得したい数値が取得できるのでればどちらでも構わないと思いますが、大事なことは100人訪問がある際に103と計測するか101と計測できるかという正確さより、同じツールで取得される数値をもとに今と過去や未来の数値を比較することです。

（質問）classでクリックを取得したいということで対応したことがありましたがすべてコーダーで対応しました。どこまでが通常コーダーで対応すべき範囲でしょうか？

基本的にはソースを書き換える部分がコーダーさんの対応範囲かと思います。タグマネの設定はマーケター、ディレクター、アナリストなどがやることが多いですがチームの取り決め次第の部分もあるので量が多い場合はどれくらい工数がかかるか共有して作業を進めると良いでしょう。また分析する人がタグマネの設定をしていないと分析する際にどうなってるかわからず困ることも知ってもらうと良いかと思います。

（質問）他にも役立ちそうなツールはありますか？ヒートマップツールを入れてますがうまく使いこなせている感がないので。

あまり次々にツールを導入すると管理しきれなくなるのでまずはGoogleアナリティクスをはじめ導入しているツールを活用することが重要です。

（質問）これだけは必ず入れておいた方が良いという解析ツールはありますか？また集めたデータはどのように分析していますか？

ひとつ数字を見る際に気を付けることは、いきなり数字を見ないことです。予め個々の数字はこうだろうなという予測をたててから結果を見ます。予想通りであれば仮説が合っていたということでそのままの方向で進めると良いですし、予測値と乖離があればなぜそうなったかを深堀出来るからです。

（質問）会社の方針でLP・解析・課題抽出・改善までサポートする動きになり勉強をはじめたのですが、この場合は「AB」テストなど改善方法に応じたテストパターンなどのところまでコーダーは理解している必要はありますでしょうか？

理解しているに越したことはないですが、それぞれ役割があると思いますので最低限どこまで理解しているとコミュニケーションがうまく進むかチーム内で確認しておくと良いでしょう。

最後に

データを活用したマーケティングは今後ますます加速していきます。クライアントや自社の予算も今後ますますデータ活用にさかれる割合が増えてくるでしょう。

ニーズは間違いなく高くなってくるので、そんな時にコーダーとしてどんな価値を提供できるかをこのセッションを通して改めて考えるきっかけになっていただければ幸いです。

SNSでも情報を発信していきますのでぜひお気軽に交流ください。

ダウンロード

Webサイト表示速度改善手法
阿部 正幸（モチヤ）

CSS Nite LP58 Coder's highに参加いただきました、皆さまありがとうございました。
Webサイトの高速化に登壇させていただきました、モチヤの阿部と申します。

セッションでは若干緊張しており、伝えもれてしまったことがありますので、こちらでフォローアップさせていただきます。

今回のセッションで一番伝えたかったこと

今回のセッションで一番お伝えしたかったことは、Webの高速化を行うには、なぜ遅いかを知るための原因調査がもっとも重要です。
原因を調査し高速化の対策を実施します。

速度調査ツール

まずはバックエンドに原因があるのか、フロントエンドに原因があるのかの大雑把な調査を行うためには、速度調査ツールを使うと良いでしょう。

バックエンドに原因がある場合

今回私のセッションでは主にバックエンドの施策の話をさせていただきました。
バックエンドで重要になるのが、キャッシュと、データベースの効率化で、下記の対策があります。

「サーバー引っ越し（スペックアップ）、サーバー内部キャッシュを入れる、データベース設計見直し、キャッシュを入れる」　は、インフラエンジニアが必要ですので、今回のセッションは説明を除外させていただきました。

データベースインデックス作成について

データベースのレーコード数が多い場合、データベースインデックスを作成することにより高速になることが多くあります。
インデックスの確認や作成は、レンタルサーバーでも利用ができる、phpMyAdminからでできます。

インデックス作成時の注意点

セミナー中は、気軽にインデックスの作成をしてみようと捉えてられてしまような発言をしてしまいましたが、インデックスの作成はメリットもありますが、デメリットも存在ます。

インデックス作成の目安は、スロークエリ（Slow query）を使って、遅いSQLの箇所を特定し、そのSQLのWHERE（検索条件）に対して行うのが有効です。
多くのシステムは適切なインデックスが作成されており、検索を高速に行っています。

またSQLの書き方によっては、インデックスを作成しただけでは早くならないケースも存在ます。原因がSQLにあると分かった時点で、一度エンジニア相談してみると良いでしょう。

インデックス作成のデメリットについて

上記でインデックス作成は必ず検証をしてくださいとお伝えしたのは、デメリットも存在するからです。
デメリットは下記の通りです。

検証

様々な施策を行ったあとは負荷をかけて、速度検証を行うことが重要です。

Apache bench

Apache benchはWebサーバーの性能をしらべることができます。
Macの場合はターミナル画面を起動し下記のコマンドを実施してください。

ab -n 250 -c 50 https://example.com/

LOAD IMPACT

LOAD IMPACTは、1日5回までの検証が無料で行うことができます。

質問の回答

サーバーをホスティングで運用していて、.htaccessで、なかなかキャッシュコントールやgzipがやりたくてもできない場合はどうすれば良いか。

昨今のホスティングはデフォルトでgzip圧縮配信されています。もしサーバーが対応していない場合は使えませんので、ウェブサーバーの引っ越しを検討してください。
ブラウザキャッシュについては、ウェブサーバー側でデフォルトの設定がよく入っていますので、ChromeのDevToolsから確認をしてみてください。
（確認方法スライドに追加いたしました）
入っていない場合は、.htacessに下記を追記することで、追加できます。

<Files ~ ".(gif|jpe?g|png|ico|svg)$">
	    Header set Cache-Control "max-age=1209600, public"
	</Files>

キャッシュのクリア方法

キャッシュのクリア方法は、キャッシュの設計と同じくらい重要です。
理由は、キャッシュのクリアタイミングが適切でないと、お客様から「記事更新したんだけど反映されない」と必ずクレームに繋がります。
ですので、記事が更新されたら、同時にキャッシュがクリアされるようにシステムを設計する必要があります。

例えばWordPressと、CDNを導入している場合は、WordPressの記事が更新されたことをフックにCDNのキャッシュをクリアするAPIをたたいて削除します。
DBの内部キャッシュを使っている場合も同様に、記事が更新されたら、DB内のキャッシュをクリアするようにプログラミングしておきます。

Lazy Loadの画像遅延読み込みに関してSEOでは非推奨と聞いたがどうなのか。

Lazy Loadは、コンテツサイズが大きいものに関して使うと有効です。
例えば動画をトップに表示したい場合、実案件で下記のような要件がありました。

デメリットとしては、PCの場合は別途で通信が発生してしまいます。しかし昨今のサーバー環境はHTTP2や、画像圧縮での配信など、ものすごく画像数が多くない限り問題になることは少ないです。

遅延読み込みがSEOで非推奨な理由は、Googleは遅延読み込みをした画像を検索用インデックスに登録できないからです。
その画像がSEOに必要ない場合は、遅延読み込みをしても問題ないですし、表示速度を落としてまで、画像を沢山読み込みたいということも無いでしょうから、適切に導入しても良いのではないでしょうか。

さいごに

イベントに参加いただきました皆さまありがとうございました、また皆さまにお会いできることを楽しみにしております。
下記は私のソーシャルアカウントです、お気軽にフォローいただけると幸いです。

ダウンロード

フロントエンドでサイトスピードUP！
佐藤 あゆみ（ism／PentaPROgram）

たくさんのご意見、ご質問をいただき、本当に参考になりました。ありがとうございます。

フロントエンドの高速化は取り扱う範囲が広く、環境差による例外も多く発生します。
すべてを網羅して説明しようとすると「※ただし〜の場合は○○」という注釈だらけになって本文の量以上になってしまいます。

何か違和感を持ったり、うまくいかないことがありましたら、お調べいただくか（図解入りで丁寧に説明された素晴らしいサイトがたくさん存在します）、ご質問をいただければ幸いです。

私は、常に世界は移り変わり、そして人間が改善のための試行錯誤を繰り返す限り、永遠に完成しないものだと捉えています。

そして、ウェブ制作に関するすべてを「完璧」に行う必要はないと考えています。

バリデーターで100点を出せなくても、運用してみて、成果が出ればよし。

結果よければすべてよし、です。その時点でのベストを探ります。

作る側としては完璧な状態というのは気持ちがよいものですが、「ベスト（最良）」と「パーフェクト（完璧）」は異なります。

最終的に人間にみてもらうために制作しているものですから、制作過程で機械的に割り切れなくとも仕方がありません。

高速で表示したい、というのも元をたどればSEOではなく人のため。

サーチエンジンは、人間の後を追って成長しています。

人間を大事にしていれば、サーチエンジンにも評価される（であろう）時代がやっとめぐってきました！

Twitter(@PentaPROgram)

ismでの紹介ページ

セミナー内容への補足

スライド中では直接触れていない内容について補足します。

「消したいけど消せない」への対処はGitで

｢大切にしていたものを失うこと｣は、脳では、体で感じる痛みと同じように処理されている

引用：なぜ僕らはムダなものを買ってしまうのか：部屋も頭も整理するために私が作った4つのルール

という研究もあるそうです。

…さまざまな事情があるかと思いますが、もし周囲の反対にあってコンテンツを消せない場合、こう提案してみてはいかがでしょうか。

「少し外して様子をみてみませんか？　戻すのは、いつでも戻せますから」

消すのではない、少し外して、様子をみてみるだけ。

これなら失うものは何もありませんので、少し和らぐのではないでしょうか。

※ちなみに個人的には削除後に「戻して」といわれたことはありません。消したら消したで忘れていくようです。

そして、（この件に限らず）もちろんきちんと常にバックアップを取って、必要であれば戻せる状態にしておくことが必要です。

そういった場合に便利なのがGit等のバージョン管理システムです。

いつ、誰が、何をしたのかを、HTMLソースを汚すことなく記録に残していけます。

Gitを使えば、例えば「2017年9月29日の状態のWebサイト（静的コンテンツ）をまるごと復元」することも可能です。

また、「去年やってた○○キャンペーン、今年もやるから今からサイトに載せ直して！」という依頼が来たときも、過去メールログやフォルダを漁る必要はありません。

Gitの履歴（コミットメッセージ）をめぐって「…○○キャンペーンは…あった、これだ、この日に削除したこのソースをコピペしよう！」という風に復活させることも可能です。

便利そうだなと思ったら、ぜひ一度、お試しください。

アンケートでいただいたご質問への回答（サーバー編）

以下のサーバー編の回答にあたりまして、同日に「Webサイト表示速度改善手法」セッションで登壇いただいた阿部 正幸（モチヤ）さんにご協力いただきました。アドバイスいただき誠にありがとうございました。

.htaccessですべてのキャッシュを無効にする

テスト・ステージング段階で、クライアントに「リロードしてくださいね」という手間を省くために.htaccessですべてのキャッシュを無効にしたい場合は、下記のような記述にします。

# キャッシュ設定
<IfModule mod_headers.c>
  Header set Pragma no-cache
  Header set Cache-Control no-cache
</IfModule>

ただし、以前同じサーバーのファイルにアクセスしたことがある場合、前回の配信時にExpires、Last-Modified や ETag などの指定があった場合は、指定の時間までローカルキャッシュはクリアされません。

また、過去に検証した際に各ブラウザによって動きが異なることがあり、一部ブラウザではキャッシュがクリアされない可能性もあります。

deflateで圧縮してからレスポンスで返す場合、サーバーへの負荷はどの程度？

負荷を測定したことがなく、ご質問への直接的なご返答はできかねます。申し訳ございません。

ただし、gzip圧縮が入っていないサーバーは昨今はほぼないと認識しており、そしてモジュールが入ってるサーバーはデフォルトでonになっていますので、こちらに関しては気にする必要はないと考えます。

.htaccessはフロントエンドエンジニアでも扱えないとまずい？

キャッシュの制御や、リライトルールなど、書けた方がもちろんよいと思います。

アンケートでいただいたご質問への回答（フロント編）

CSS配信の最適化って大変じゃないですか？

とても多くいただいた質問でした。

無理そうであれば行う必要はない、と前置きした上で、回答させてください。

全ページ同じCSSインライン化しちゃってもよい、と考える

まず、私は

同じウェブサイト内のファーストビューのパターン例

トップページは特殊なレイアウトになることが多いですが、ヘッダーのデザインやページの背景色、見出しのスタイル等は、サイト内でパターンとして統一されていることが多いのではないでしょうか。

厳密にやろうとすれば、1ページずつ、それぞれのファーストビュー内のCSSを探っていくのが理想的だと思います。

ですが、そもそも端末ごとに異なるのがファーストビューですし、人力で厳密にすべてに対応しようとするとかなりの労力を使います。

そこで、まず、サイト内で統一されているデザイン部分のCSSをすべてのページ内のheadタグ内に書き込んでしまうことで、大体のページのファーストビューは網羅できます。

除外しなくてもよい、と考える

厳密にやろうとすれば、headタグ内に書き込んであるスタイルは、後から読み込む外部CSSからは消しておくべきですが、それも「被っててもいいんじゃない」とおおらかにそのままで対応してもよいと考えています。

まずテスト環境で試して、実際のレンダリングを比較して、それから取り入れるか考えてもよいと思います。

「いやー、取り入れるほどでもないわ」と思えば、元に戻せばよいのです。

gulp等の自動化ツールを使っているとインライン化したCSSの管理が面倒そう

私はgulpを使用したことがありませんが、gulpにはcriticalというライブラリがあるそうです。

※癖があるのでまったくお勧めはしないのですが、私はJekyllというRuby製のテンプレートエンジンをカスタムしたものをコッソリ好んで使っています。

CSSの非同期部分でnoscriptで読み込んでいる部分は？

JavaScriptが動作しないブラウザでもCSSを読み込めるようにしています。

CSS の配信を最適化する(ソースコードの引用元)

CSSを複数読み込んでいる場合にインライン化するには？

Critical Path CSS Generatorを使用する場合、読み込んでいるCSSをすべて2の「FULL CSS」の入力欄にぺたぺたコピペすればOKです。

PageSpeed Insightsの判定が99点でしたが、100点にするにはどうすればよかったのでしょうか？

事例で出したサイトが99点だった理由は「外部サーバーのファイルを読み込んでいるから」でした。

解析タグなどの外部サーバーのファイルをページ内に読み込む場合、外部サーバーの設定は変更できないため、外部サーバーの設定内容で検査項目に引っかかると減点されます。
ただ、100点でなくても気にしなくてよいと思います。

PageSpeed Insightsはページが遅い理由を示しているわけではないですよね？

はい、PageSpeed Insightsでは、速度の計測や「こうすると速くなるかも」という提案はしてくれますが、未実行の提案がページが遅い原因になっているとは限りません。

何がボトルネックになっているかは、先の阿部さんのセッションで触れられている調査方法で調べられます。

では、なぜPageSpeed Insightsを出したかといいますと、私自身が、クライアントからPageSpeed Insightsの結果を見せられ「うちって遅いんじゃない？」と相談されたエピソードにあります。

URLを入力するだけで簡単に実行できるツールのため、誰でも分かりやすく「採点」できます。

ウェブ制作について学習する前の段階でも、速度を意識するきっかけのツールとして一つの指標になるものと捉えています。

画像はどこまで圧縮すべき？

悩みどころですね。

効果が目にみるような容量削減を目的とする場合、バレない圧縮方法というのは、申し訳ありませんが、思いつきません。

ツールによって圧縮精度は異なるものの、JPEGもPNGも「非可逆圧縮」することになり、画質が劣化します。

わざわざ圧縮NGと明確に指示されている場合、チェックの目も相当厳しいと思われます。

ただ、例えば買う気満々100%で商品の詳細ページをじっくりみている場合や、アーティストのファン専用サイト等では、たとえ表示に時間がかかったとしても、待ってくれるとは思います。

何がなんでも圧縮しなければということではありません。

もし私だったら、デザイン優先であれば、それはそういった戦略として受け止めてコーディングします。

その代わりに表示が遅くなることはあらかじめ断りを入れます。

縦長ページであればlazyloadで画像を遅延読み込みさせて読み込み速度を意識させないというのが現実的な落としどころになってしまいそうです。

その上で、私はキービジュアルのような大きな画像の場合は200KB前後を目安にしています。

経験上は下記のようなJPEG画像は劣化が目立ちやすいです。

文字入り画像で、特殊なフォントを使用している場合は「背景画像(JPG)＋文字(PNG)」に分離してからそれぞれ圧縮した後にCSSで重ねる対応をしたことがあります。

ビデオ圧縮ノイズを目立たなくさせる話、気になります

背景に動画を使う場合、きつく圧縮すると動画の画質が汚くなってしまいます。

そこで、圧縮してあることを目立たなくさせるために、背景動画に網掛をして目をだまそう！というテクニックのお話でした。

当フォローアップページ下部、「その他」の「鷹野さんのいっていた『動画の市松模様…』」をご参照ください。

商材の関係で動画がトップにあり、遅いのですが、どうにかなりますか？

※サイト名の記載がありましたが、私の判断で伏せました。

実際に拝見しましたが、確かに表示されるまでに間がありました。動画部分で計3MB位でしょうか、特にケータイ回線では瞬時には表示できないでしょう。

一つ上でお応えしているような「高圧縮にして網掛でごまかす」テクニックも使えるとは思います…が、そもそもこんなにたくさんの動画を再生しなくてもよいように思いました。
特にスマホでは、動画が現れる前に、ただの白背景だと思って動画が表示される前にさっと下にスクロールしてしまいそうです。

個人的には動かさずとも美しく商材が伝わる「勝負画像」1枚でよいなと思ってしまいます。
正確には横長のPC用と縦長のスマホ用の2枚ですね。
その上で、「サンプル動画ギャラリー」のページを設けて、興味がある方にはそちらでじっくりみてもらうという形はいかがでしょうか。

そもそも画像を使用しないという選択肢があるのではないでしょうか？

そうですね。

画像を使用する必要がない、もしくはCSSで表現できる、アイコンフォントを使用するなどの代替手段がある場合は、画像を使用しなくてよいと思います。

asyncとdeferの違いは？

asyncは非同期、deferは延期です。

asyncの場合は、記述した順序に関わらず、読み込みが完了したスクリプトからすぐに実行されます。

deferの場合は、ページの読み込みが完了した後に順次実行されます。

asyncで非同期読み込みをするとブラウザレンタリングがブロックされないという認識でいいでしょうか？

はい、そうです。

どんなJSでも非同期にしてしまってよい？

表示を開始した時点で実行される必要があるスクリプト、また、主にファーストビュー内で直接的にレンダリングに影響するスクリプトは、非同期にしない方がよいです。

解析系のタグは、原則として記述をいじることなく指示された通りに設置しましょう。

FMPはどこで確認できるのでしょうか、ChromeのDevToolsのAudit (Lighthouse)でしたっけ

はい、ChromeのDevTools内のPerformanceやLighthouseにて、どのようにレンダリングされているかを確認できます。

ダウンロード

現場で役立つCSSアニメーション
伊藤 由暁（まぼろし）

この度はCSS Niteにご参加いただきありがとうございました！　スライドの一部でテキストが重なって読めないミスがあり、大変申し訳ありませんでした…！

ウェブ制作の現場では、CSSアニメーションは不可欠な存在となりつつあります。アニメーションの追求には専門知識が必要で、それを習得しているデザイナー、エンジニアは多くはありません。にも関わらずウェブではアニメーションが「おまけ」のように扱われている側面があります。

おまけでちょっとしたアニメーションを入れたい、そういうオーダーを言ってくるクライアントが多いけど、「おまけ」で「ちょっとした」アニメーションで合意を取るのがどれだけ難しいかは、うなずいていただける方も多いでしょう。

とても幸いなことに、ウェブには素晴らしいCSSアニメーションがあふれています。それらを探し、再現し、ストックする。それだけで自分の武器が増えます。

CSSアニメーションはCSSで作られていますので、同じようにコードを書けば同じように動きます。この時点で難しさというのは極限まで下がっていると言って過言ではありません。あとは「なぜ素晴らしいと感じたのか」がわかれば、合意形成までの距離はぐっと縮まりますね。

発表の中の「ウケるアニメーションとは」でお話しした通り、全てのキモは「イージング」と「複数の動き」です。まずはイージングを工夫し、次に複数のプロパティーでアニメーションできるかどうか考えてみると良いです。

スライドと質疑応答の補足

easings.netをベースにイージングをカスタムする

cubic-bezier.comで3次ベジェ曲線を自分で調整するデモをお見せしたかったのですが、うまく行かず申し訳ありませんでした。

cubic-bezier.comでは青いハンドルと赤いハンドルをドラッグすることで自由にイージングをカスタムすることができます。Adobe Illustratorでのベクターツールをお使いの方なら調整にはさほどハードルは感じないかと思います。

ベジェ曲線がどうなっていると動きにどう違いが出るのか、体感できる非常に良いウェブサイトなので、少し時間を作って触ってみてください。

流行りのCSSアニメーションの探し方は？

僕が普段チェックしているのはCodePenですが、能動的に見に行くタイミングは「CodePen Spark」という無料メルマガが届いたときです。Sparkではデザインや機能が素晴らしいものやTIPS、ハック的なものが週一で紹介されており、その中でCSSアニメーションで作られたものがあります。それらをfavしておいて、あとで見返して詳しくコードを読み解き、手元にストックしています。

CodePenにも日本のユーザーはいます。アニメーションのクオリティと量共に、下記のお二方のCodePenは要チェックです。

僕のアカウトもあります！　CSSアニメーションは全然作ってませんが、先日「写真エリアの中央のボタンにhoverすると、ボタンの外側の写真エリアもtransitionする」というのを作りました。ただしクライアントにはそんなにウケませんでした。

CSSアニメーションとJSライブリのアニメーションはどっちがいいの？

複数のアニメーションを連続で順番で再生したい場合、3ステップ以上あるアニメーションならJSで管理したほうが調整が楽です。CSSでは順番でアニメーションさせたいもののdelayが１つ変わったら後のアニメーションの全ての記述を見直さないといけないのでとても大変です。

前のアニメーションが終わったことをちゃんと検知して次のアニメーションを始めたいなどの場合はJSでの処理が必要です。その時はアニメーションは全てJSで管理するようにした方が楽です。実装時に見るべきファイルが少ない方が開発しやすさも上です。

表示パフォーマンスの面ではWebGLやcanvasを利用できるJSライブラリの方が上です。使い分けや各ライブラリの特徴はICS MEDIAの「現場で使えるアニメーション系JSライブラリまとめ(2018年版) – TweenMax, CreateJS, WebAnimation, Velocityなど」の記事で非常にわかりやすくまとまっているので、参考になります。

アンケートへの回答

デザイナーさんとアニメーションを決めるときはどのようにしているか？

デザイナーさんからアニメーションを入れたいと言われたときは、まず「具体的にこのサイトで使われているやつなどあったらリンクを教えてください」と伝えています。そこでリンクを教えていただけたらそのまま利用するだけなので最も話が早いです。その上にこちらの提案を被せてもコミュニケーションが増えるだけですので、それはせずにありがたく指示を受け入れましょう。

アニメーションは入れたいけど、相手が詳細なイメージを持っていない場合、まず「どんな系統のアニメーションなのか」をヒアリングし、それに応じてアニメーションさせるtransition-propertyを決めます。

ここからはクライアントに見せられるサンプルが必要になります。

例えば透明度が変わる系では、まずはピュアに要素丸ごとのopacityをアニメーションさせるサンプルを作り、そこからバリエーションを2つほど派生させ、それに応じた質問もあらかじめ用意しておきます。

このように、サンプルは極力少なくし、どれかをベースにしたコミュニケーションでアニメーションを調整して行くと意外とすんなり決まっていきます。

もちろん、もっと細かいバリエーションを見て決めたいと言われてしまったら、頑張って作りましょう…！

アニメーションがユーザーに与える影響の違いがあれば知りたい

「視線の誘導」としてのアニメーションがユーザーに与える影響が大きいです。わかりやすい例としてはブラウザの高さいっぱいにメインビジュアルが置かれたコンテンツです。ページを下にスクロールできることを示すアイコンや装飾を「スクロールヒント」と言いますが、それがゆったりアニメーションしていると、メインビジュアルを邪魔しすぎず、存在に気づいてもらうことができますね。

スマホコンテンツでも、一見すればスワイプできないエリアでも、指先のイラストが左右に動くアニメーションが表示されれば、ユーザーはそれによってスワイプできることを知れます。動いていることで視線を誘導し、動きの様子でユーザー操作を補助しているわけです。

アニメーションがユーザビリティを高めるシーンは多々あります。何がどのように変化するか、その先に何があるのかを知っているのは制作サイドの人間だけですので、アニメーションを活用すれば誰にとってもわかりやすいサイトが作れます。

サイト訪問者に効果があるのかわからない、うまく使えなさそうで悩む

発表では「CSSアニメーションは結論必要です」とでっかくお伝えしましたが、ない方がいい場合もあります。

こうなってしまうとユーザービリティが下がるだけですので不要です。一番重要視したいのは、アニメーションがあることでユーザーの助けになることです。あってもなくても同じであれば、制作側の自己満足にしかなりませんので、まずはその線引で分けてみましょう。

「回っている寿司は美味そうに見える」ともお伝えしましたが、回転寿司がイマイチ美味そうに見えない気がするのは、寿司が「全て」「linearで」「ずっと動いている」からです。情報が平坦化されて、どれも大事に見えなくなってしまうわけですね。イージングが違うレーンで旬のネタが流れてきたら、美味そうに見えるでしょう。

hoverやfocusをトリガーするアニメーションはあくまでPCベースのもので、スマホサイトでCSSアニメーションをどう活用できるか？

リンクボタンやハンバーガーボタンは、スマホでは指で隠れてしまってアニメーションに気づかない場合はあります。しかし、スマホサイトをスマホだけで見るとは限りません。CSSメディアクエリでスタイルを書き分けている場合、デスクトップブラウザでも画面幅を狭めればスマホレイアウトの状態を確認できます。ブラウザを見ながら執筆などの並行作業をしているときに、画面幅を狭くしている人はそれなりにいます。そういったユーザーにはスマホレイアウトでもhoverやfocusは有効ですので、スマホサイトだからアニメーションはいらない、と切り捨ててしまうのは早計です。

発表ではボタンのCSSアニメーションしか紹介できませんでしたが、ページ内リンクのスムーススクロールやドロワーナビのスライドインでも、イージングの活用は可能です。

SPA（Single Page Application）で現在いるページがアニメーションで消えてから次のページを表示する場合なども、ただopacity :0にするだけのアニメーションより、各要素がtransform: scaleY(0)にもなる、テキストと画像が順番に画面外へフレームアウトして消えるなど、様々なパターンが考えられますね！

デモを作るときに凝りすぎてしまってやめどきがわからない

鬼の心で止めましょう。「やりすぎかな？」と思ったらほぼ確実にやりすぎています。

僕が担当してきた案件では、CSSアニメーションは下記の5種類のパターンが多いです。

これらそれぞれで派生があればサンプルとしては十分です。似たパターンをたくさん用意してもその違いを判別できるクライアントは多くはありません。派生は、複数の動きを持つものと、イージングが違うものがあれば3つ程度で良いです。

また、アニメーションさせるトリガーとしては

が主だったものです。hover以外を再現するにはJavaScriptの助けが必要になりますが、サンプルとして見せるならどれもhoverにしておいたほうが、すぐにアニメーションを発動させられるので確認がスムーズになります。

それらを見せながら「スクロールで画面に入ったときに、大きくなりつつopacityが0から1になる感じですね」などといったコミュニケーションが取れるようになれば、サンプルとして十分役割を果たせています。

もし差し支えなければ、レビューしますのでご連絡ください！　コードの良し悪しではなくサンプルとしての過不足をお伝えできます！

CSSアニメーションのパフォーマンスについて聞きたい

CSSアニメーションのパフォーマンスというと、transform: translate3d(0,0,0)のような、Null Transformと呼ばれる「おまじない」を利用してGPUレンダリングさせる手法が古くからあります。

.elem {
	  width: 50%;
	  height: 50%;
	  background-color: tomato;
	  transform: translate3d(0,0,0); /* 強制的にGPUレンダリングさせる */
	}
	.elem:hover {
	  width: 200%;
	  height: 10%;
	  background-color: gold;
	}

GPUレンダリングで表示パフォーマンスが向上することは事実です。特に座標が変わる系では効果が顕著です。

僕がこれまで案件をやってきて、CSSアニメーションの表示パフォーマンスの改善が難しかったのは以下のパターンです。

上記のパターンはNull Transformを利用してもほとんど改善できません。GPUレンダリングをしていても、その範囲が大きいとか数が多いと効果が出にくいようです。

さらに、ラスター画像を動かす場合は transform: translate3d(100%,0,0) で要素を画面の右へ追いやるよりも、left: 100%の方が表示パフォーマンスが良いケースも過去にありました。

一方、ボタンなどのマイクロインタラクションでは、Null Transformを意識しなくても表示パフォーマンスに体感で影響が出ることはほとんどありません。ですので、今回のデモでもNull Transformは使用しません。

CSSアニメーションをオーダーされた時は、必ず「表示が重くなる可能性」と「表示パフォーマンスを改善できない可能性」を説明します。それを理解した上でやりたいならば、もちろんやります。

BEMでElementの中にも要素があるので、そのElementもBlockにしたいがどう命名すれば良いか？

CSSアニメーションの話ではないのですが、僕はBEMが大好きなのでこれには答えざるを得ません。

ElementもBlockである場合とは、例えば、下記のようなHTMLでしょうか。

<div class="p-split">
	  <div class="p-split__col  p-code"><!-- p-split__col が p-code を兼ねている -->
	    <div class="p-code__header">...</div>
	    <div class="p-code__body">...</div>
	  </div>
	  <div class="p-split__col  p-view"><!-- p-split__col が p-view を兼ねている -->
	    <div class="p-view__header">...</div>
	    <div class="p-view__body">...</div>
	  </div>
	</div>

個人的にBEMでElementとBlockを兼業させるのはオススメしません。なぜならば、p-code やp-view Blockのスタイルがp-split__colに依存するCSSで構成される場合があり、別の場所でp-codeやp-viewだけで使ったときにスタイルが成立しなくなる可能性があるからです。依存があるのかないのかがまちまちですと、メンテナンス性は下がりますね。

ですので、「依存がない」に統一するために、ElementとBlockを兼業させず、Blockだけで常に独立しているHTML構造にするべきです。

<div class="p-split">
	  <div class="p-split__col"><!-- p-split__col でしかない -->
	    <div class="p-code"><!-- p-code でしかない -->
	      <div class="p-code__header">...</div>
	      <div class="p-code__body">...</div>
	    </div>
	  </div>
	  <div class="p-split__col"><!-- p-split__col でしかない -->
	    <div class="p-view"><!-- p-view でしかない -->
	      <div class="p-view__header">...</div>
	      <div class="p-view__body">...</div>
	    </div>
	  </div>
	</div>

では、ElementとBlockを兼業させないことを守った上で、p-code Block が p-split__col Elementの中にあるゆえに必要なスタイルは、どう書かれているべきでしょうか？　Modifierで管理しがちですが、Modifierは使いません。理由はいくつかあります。

まず命名が難しいです。先ほどのHTMLの、p-split__colの中にいるp-codeにどんなModifierをつければ妥当でしょうか。--inSplit__colでしょうか？　--blackBack でしょうか？　悩む時間の無駄さが半端ないです。ただでさえElementの命名で悩んでいるというのに。

そして悩んで命名したけど p-split__col の中以外の場所では使わないModifierになったりしませんか？

シングルクラスBEMにしているとSassのextendを使わないとしんどいですよね。そのときもextendを使うルールも決めておかないとあとあと管理できなくなってきます。

かと言ってマルチクラスBEMでModifierつきの名前をHTMLに併記すると、これがまた冗長すぎて苛立ってきませんか。

ということで、普通に子孫セレクタにして良いです。

.p-split__col .p-code {
	  margin: 30px;
	}

scssファイルはBlockごとにファイル分割し、_p-code.scss のファイルに p-split__col の中にいるときのスタイルを記述しましょう。

.p-code {
	  .p-section__col & {
	      margin: 30px;
	  }
	}
	
	.p-code__header {...}
	.p-code__body {...}

これらの管理手法は「細かすぎるけど伝わってほしい私的BEMプラクティス30（ぐらい）」を参考にしています。

さて、BEMの理解でつまづくのが、「Element＝Block直下の要素」という先入観です。これは明確に誤りで、ElementはElementを入れ子にすることができます。

<ul class="menu">
	    <li class="menu__item">
	        <a class="menu__link" href="https://">...</a>
	    </li>
	</ul>

https://en.bem.info/methodology/html/#nesting-of-elementsより

ですので、「Elementの中にも要素がある」からといってBlockにしなければならないわけではなく、そのままElementを増やして良いです。その際に命名に困るというのがBEMあるあるですが、そこは割り切っていくと気持ちが軽やかになるでしょう。割り切りとは、以下のような命名を受け入れることです。

<div class="p-split">
	  <div class="p-split__inner">
	    <div class="p-split__inner2"><!-- 割り切りポイント -->
	      <div class="p-split__col">
	        <div class="p-code"></div>
	      </div>
	      <div class="p-split__col">
	        <div class="p-view"></div>
	      </div>
	    </div>
	  </div>
	</div>

おわかりでしょうか、 p-split__inner2です。 __innerの中に別の「インナー的なもの」が必要になったとき、こうして番号をつけてしまうことで考える時間をぐっと減らせます。無理して命名しなくてもいい、命名で困ったらブロックにしてもいい、そんなくらいに考えると良いです。もちろん別の場所で独立したBlockとなるものはちゃんとBlockにしましょう。

ElementはElementを入れ子にできると書きましたが、「Elementを繋いだセレクタを作って良い」とは言っていませんので、注意してください。Elementを繋いだセレクタとは、.menu__item__link とったものです。これはBEM的にもやってはいけないとされています。

終わりに

アンケート全体として、easings.netのcubic-bezier() を見比べられるサンプルにご好評をいただく声が多く、大変嬉しく思います。

ウェブサイトとして参照するだけでなく、リポジトリをフォークし、自分の客先に提案しやすいように色や大きさを自由にカスタマイズしてご利用ください。

ありがとうございました！

ダウンロード

もう一歩踏み込んで現場で使うCSS Grid
鹿野 壮（ICS）

今回はご参加ありがとうございました。各モダンブラウザで使えるようになって1年経ったCSS Grid。2018年のオススメの書き方、採用事例、IE 11の対応方法、未来のCSS Gridまでを解説しました。アンケートでは「現場で使ってみようと思った」「CSS Gridの環境が便利になっていて驚いた」などの声をいただき嬉しく思います。新しい手法や技術を知ることは、自分自身の表現力や作業効率を上げることに直結します。ワクワクしながら新しい技術を一緒に学びましょう。

フォローアップでは、発表での補足とお寄せいただいた質問をいくつかピックアップして回答します。

アンケートでいただいた質問に関して

（質問）縦にコンテンツが並んでいるケースでも使うことはあるか？

はい、あります。今回紹介した案件では、固定幅のヘッダー・フッター、可変幅のメインコンテンツ、gapプロパティを用いたレイアウトの際に使用しました。サンプルコードは次のとおりです。

（質問）チームの学習コストはどれくらいかかったか？

CSS Gridを案件に導入した2017年は、本セッションで紹介したエリア名の行列定義ができなかったため、覚えてもらうことに苦労しました。Autoprefixerの進化でエリア名の行列定義が可能になると、他のCSSによるレイアウトよりも簡単だという声もあり、数回使用するだけでCSS Gridを覚えてもらえました。

（質問）Sassを使用した場合、Autoprefixerをどのタイミングで使えばよい？

Sassのコンパイル後に、Autoprefixerによる変換を実行します。

（質問）要素が重なる表現は可能か？

同じ行・同じ列にアイテムを配置すると、アイテム同士は重なります。z-indexで重なり順を制御することもできます。

（質問）repeat()メソッドを使った場合、IE 11でアイテムがすべて左上に並んでしまうがどうしたらいいか？

行・列の繰り返しに使用するrepeat()メソッドは、AutoprefixerによるIE 11向け変換が可能です。しかし、アイテムの配置の際に注意点があります。IE 11を除くブラウザでは行・列の左上から順にアイテムが配置されていきますが、IE 11では自動的に配置されないので次のように配置位置を指定する必要があります。

▼ CSS

/* 1行目・1列目に配置する */
	.item:nth-child(1) {
	  grid-row: 1;
	  grid-column: 1;
	}
	
	/* 1行目・2列目に配置する */
	.item:nth-child(2) {
	  grid-row: 1;
	  grid-column: 2;
	}

行数、列数が増えると手動で記述するのは煩わしいので、我々の案件ではSassを使って次のように対応しました。$rowNum、$columnNumを変更すればコピペで使えるので是非ご利用ください。

▼ Sass

.item {
	  // 行数（3行）
	  $rowNum: 3;
	  // 列数
	  $columnNum: 5;
	  
	  // 左上から順番に配置する
	  @for $row from 1 through $rowNum {
	    @for $column from 1 through $columnNum {
	      $index: ($row - 1) * $columnNum + $column;
	      &:nth-child(#{$index}) {
	        grid-row: $row;
	        grid-column: $column;
	      }
	    }
	  }
	}

また、gapのIE 11向け変換はrepeat()メソッドを使った場合は不可能です（2018/10/01時点）。我々の案件では、repeat()メソッドを用いる場合はmarginやpaddingでアイテム間のスペースを設けることにしました。

（質問）repeat()メソッドで、行数・列数を固定して行幅や列幅が動的に変化するレイアウトがしたい

3行5列の行列を作成するには、次のようなコードを書きます。grid-template-rowsは行のサイズのみを指定するプロパティ、grid-template-columnsは列のサイズのみを指定するプロパティです。

▼ CSS

.container {
	  display: grid;
	  grid-template-columns: repeat(5, 1fr);
	  grid-template-rows: repeat(3, 1fr);
	}

「repeat()メソッドをIE 11で使う場合の注意点」で紹介したアイテムの配置を行えば、IE 11でもレイアウトが可能です。サンプルを用意しました。

（質問）repeat()メソッドで、画面サイズに応じて行数や列数が動的に変化するレイアウトがしたい

repeat()メソッドの第一引数にauto-fillを指定すると、コンテナーのサイズに応じて行数や列数の変わるレイアウトが可能です。詳しくは、記事「これは便利！CSS Gridのauto-fillとauto-fitの使い分けでRWDが捗る - WPJ」を参照ください。

▼ 画面サイズに応じて100pxサイズの列の数を変えるCSSコード

.container {
	  display: grid;
	  grid-template-columns: repeat(auto-fill, 100px);
	}

ただし、auto-fillはIE 11では使えないので、repeat()メソッドではなくgrid-templateプロパティなどで行数・列数を書き換えるか、Flexboxでレイアウトします。

感想

いただいた感想の中から、とくに印象深かった感想をいくつかピックアップします。Gridの便利さが伝わったようで何よりです。

さいごに

次の媒体でWebデザインやフロントエンドの情報について発信しています。こちらも是非ご覧ください。

もしCSS Gridの学習をしていて不明な点があれば、Twitter等で気軽にご相談くださいませ。

ダウンロード

クロージングトーク：UI開発者の生存戦略
木達 一仁（ミツエーリンクス）

アンケートにご記入いただいた感想すべてを、やや緊張しながら（なにせCSS Niteでは10年以上ぶりの登壇でしたので……）拝読させていただきました。「仕事のモチベーションが上がった」「コーディングを楽しんでいきたい」といった感想を複数いただき、イベント全体を締めくくる役目をある程度は果たせたのかなと、ホッとしています。

タイトルに含めた「生存戦略」……だいぶ堅苦しい印象の言葉ではありますが、要は技術の変化にどう向き合うべきかを提案したつもりです。UI開発者はともすると、学ぶべき技術の量やその変化に圧倒されそうになりますが、闇雲に焦る必要はありません。Webやその周辺がどう変化しようとしているか、表層的な流行り廃りに振り回されすぎることなく、大局を見定めたうえで、いつ何を学ぶべきか取捨選択しましょう。

そしてユーザーへのフォーカスについて。講演では「CSS in JS」を引き合いに、ユーザーという言葉をUI開発者自身という意味でお話ししましたが、開発されたUIを使う立場のユーザーについても同様です。ユーザーの課題をUI開発者が正しく認識できなければ、UIを改悪しかねません。だからこそユーザーにフォーカスし、解決すべき課題は何か、その課題解決に適した技術は何かを、都度考えることが重要です。

またいつか、10年後かもしれませんし来年かもしれませんが、ご縁がありましたらCSS Niteの場でお目にかかりたいと思います。改めて参加された皆様、そして鷹野さんはじめ運営側として尽力くださった皆様に、感謝申し上げます。ありがとうございました。

ダウンロード

その他

鷹野さんの行っていた「動画の市松模様…」が気になった

秋山さんの所属されているコンセントのサイトのトップページにて使われています。必ずしも市松模様である必要はありませが、動画の上にタイリングしたドットを敷き詰めることで動画の画質を下げてもそれっぽく見えるというテクニックです。

cssnite marketplaceのフォントおじさんより

marketplaceのFONTPLUSブースにお立ち寄りいただき、ありがとうございました。

デザイナーだけでなく、コーダー/フロントエンドエンジニア等の方々にも、フォントの楽しさ、奥深さを知って欲しく、フォントにまつわるグッズの展示、見本帖やもじもじトートバック等の配布をしました。

今回ご用意した配布グッズは以下の通りですが、最初の20分の休憩で、ほとんどが配布終了になりました。申し訳ありません。ありがとうございました。

今回の参加者の半数以上の方がエンジニア層と思いますが、文字やフォントに興味を持たれる方が多かったことに感激しました。

FONTPLUSためし書き

FONTPLUSは2018年7月3日に全面リニューアルを実施しました。TOPページが、「Webフォントを探して、試して、シェアできる」ウェブアプリケーションになりました。

まずは、フォントおじさんの作品をご覧ください。

文字を触ると、フォントボックスが選択され、フォント設定ウェジェットが出てきます。文字色、背景色、フォント、サイズ、カーニングON/OFF等の変更操作ができます。Webフォントの試し書きがバリバリできるのです。

会員ログインすれば、試し書き画面の共有だけでなく、CSSスニペットをデザイナーとコーダー間で共有できます。

詳しい操作方法は、こちらをご覧ください。

フォントおじさんのWebフォント講座

とある専門学校のWebデザイン科で実施した「フォント講座」のスライドです。前半では、書体の適材適所、フォントソムリエ感を高めるセッションです。後半で、Webフォントの導入事例と技術情報を掲載しました。ぜひ、ご一読ください。

フォントおじさんの誕生までの話

今年秋にHTML5 Experts.jp編集長の白石さんが寄稿したフォントおじさんの取材記事を紹介します。この記事がきっかけで「フォントおじさん」Google検索1位を今年ずっとキープしています。

また、どこかでお会いできることを楽しみにしております。

関口 浩之（せきぐち・ひろゆき）

スペース【A1】マンガでわかるWebデザイン・Git・GA・Docker

『わかばちゃんと学ぶ』シリーズを知っている方が多く、とても嬉しかったです。また、本イベントで初めてこのシリーズを知ったという方にも興味を持っていただけてよかったです。

Git、Docker、Googleアナリティクスが人気！

本の売れ筋は、Git、Docker。次いでGoogleアナリティクスでした。『マンガでわかるDocker』は、続編の『開発環境を構築してみよう編』を12月のCSS Nite Shiftでも頒布予定です。お楽しみに！

CSSniteイベント用.png (634.8 kB)

湊川あい

お問い合わせ

ご不明点やお気づきの点がありましたら、フォームからご連絡ください。

お問い合わせ

このページの上部に戻る