フロントエンドの基礎知識③（パフォーマンス、セキュリティ、デザインツール、画像、レスポンシブ、OSS）

①②の続きです。
こちらの素晴らしいスクラップについての記事です。
yamanokuさんありがとうございます。
今回はパフォーマンス、セキュリティ、デザインツール、画像、レスポンシブ、OSS編です。

不十分、間違っている部分があれば教えてください

パフォーマンス

個人的な意見ですがパフォーマンスに関してはdev toolの使いかたを覚えるのが一番いいと思います。
私が読んだ本の中で一番勉強になったパフォーマンスに関する本を置いておくのでぜひ読んでみてください。

https://www.amazon.co.jp/Webページ速度改善ガイド-使いやすさは「速さ」から始まる-WEB-PRESS-plus/dp/477419400X

PRPLパターン、RAILモデルについてそれぞれ説明できる

PRPL

PRPLとはGoogle I/O 2016で提案されたもので Push(preload)/Render/Pre-cache/Lazy-loadの略です。
これはPWA(Progressive Web Application) の構築・配信のための設計アーキテクチャで、PWAというのはwebページをネイティブアプリのようにできるやつのことですね。PWAとは
要するにスペックが低くユーザー体験が低くなってしまいがちなモバイルデバイスのためのパフォーマンス改善のことです。
以下はweb.devの記事の抜粋に説明を付け加えたものです。

P(push/preload)

pushとはhttp/2のserver pushを用いることによってバンドルファイルの読み込み時間を減少させ、それにより描写速度を早くすることです。

これの理解のためにはhttp/1.1 と http/2の違いについて理解する必要があります。

簡単に説明すると、http/1.1ではリクエストを送りそのレスポンスが帰ってきてから次のリクエストの処理を行う所謂直列型のデータ転送プロトコルであったため、一度にまとめてリクエストを送くことで待ち時間を短縮していました。しかしこれにより一つのバンドルファイルに全てをまとめることが横行し、結果としてその大きなサイズのファイルが読み込まれるまで何も表示されないという事態を引き起こしていました。

http/2では接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることで複数並列でのリクエストの転送を行うことができます。これにより、一つのバンドルファイルに全てをまとめるのではなくバンドルファイルをいくつかの適切な大きさに分割することができます。

簡単にまとめましたがhttp/2では他の変更点もあるのでぜひドキュメントを読んでみてください。

preloadとは<link rel="preload" as="">をhtmlドキュメントに置くことで初期URLに必要なリソース(cssや画像などレンダリングをブロックする要素)を事前ロードし描写速度を早くすることです。
開発者であれば初期描画に必要なリソースは把握しているはずなので優先順位の高いものをブラウザに伝えることでより早く初期描写を表示できます。

詳しくはweb.devの記事に載っているのでみてみてください。

R(render)

renderでは初期描写(First Paint)をなるべく早く表示させる方法について書かれています。
dev toolからlighthouseを用いればそのページのFirst Paintの速度を低下させている原因について警告を出してくれます。

light houseとは指定したページのパフォーマンス・アクセシビリティなどについて100点満点でスコアを表示してくれるdev toolの機能です。
webフロントエンドエンジニアなら知っておくべきだと思います。
こちらから使い方を知ることができます。

ここではFirst Paintの改善をするために

• 重要なJavascriptはinline化し残りはasyncをもちいて非同期で処理し、重要なcssをinline化しレンダリングをブロックする要素を極力少なくすること
• SSR(server side rendering)することで初期描画を早くすること

をあげています。しかし、SSRの場合は初期描画は早くなるものの、クリックなどへ反応することができるようになる時間(time to interactive)が伸びてしまう点で問題が生じます。
:::warning
表示されてから操作できない時間が長い方がユーザーの離脱率は高くなると言われています。
:::

P(pre-cache)

一度読み込まれたデータがservice workerにキャッシュされるため２度目以降のページの訪問時にはキャッシュしたデータが表示されます。
そのため２度目以降は表示が早くなる他に、オフライン時でもキャッシュが効いているところは表示が可能です。

L(lazy-load)

lazy-loadは遅延読み込みのことです、初期描写に必要のないリソースを遅延読み込みさせることで初期描写時に必要なリソースファイルのサイズを減少させ、速度を早くします。
画像の遅延読み込みについての記事

RAIL

RAILとはパフォーマンスモデルのことでR(response)、A(animation)、I(idle)、L(load)の略です。

R(response)

タップからイベントまで100ms未満

A(animation)

各フレームの処理16ms未満

I(idle)

メインスレッドのJS処理ブロックは50ms以内

L(load)

First Meaningful Paint まで1000ms以内

これらの数値はあくまで目標ですが達成することができれば素晴らしいユーザー体験のサイトであると言えます。
かなりきつい目標なのでほどほどにしつつ、個人的な意見ですがlight houseでオールグリーンなどが目標でも良いと思います。

計測ツールについて何があるか説明できる

計測ツールについて、私はchromeのdev toolしか知らないのでそれを紹介します。他にあれば教えてください。
networkタブではリソース取得の順番、それぞれのリクエストのステータスコード、通信の時間などを確認することができます。
さらに通信の環境を設定することができ、高速の回線ではなく3Gの回線での速度などを確認することができます。
詳しくはドキュメントを読みましょう。
performanceタブではデバイスの設定を変更することができ、CPUを変更することでモバイル端末使用時のパフォーマンスを確認することができます。
また、ボトルネックとなっている部分を目視で確認することができます。
詳しくはドキュメントを読みましょう。

Chrome Developer Toolsのどのタブで確認するか理解している

dev toolにはさまざまなタブがあります。
詳しく知りたい方はドキュメントを読みましょう

タブ名	できること
elements	HTMLの構成やcssの適応状況を確認することができます。cssを直接指定して確認することができ、マークアップのときにはとても世話になります
console	エラーメッセージなどが表示され、consoleコマンドの内容がここで表示されます、変数の中身のデバックで使うと思います
sources	構成ファイルがあります、エラーメッセージなどからエラー箇所に飛んだときにここに飛びます
network	上記したので省略します
performance	上記したので省略します
memory	名前の通りメモリの問題を見つけるためのタブです。メモリ使用量を時系列で確認することができ、メモリリークが怒っている場合の原因の特定が行えます
application	ストレージやキャッシュなどの確認を行うことができます
security	セキュリティの状態を確認することができます
light house	performance、a11ly、Best Practice、SEOのスコアを確認することができ、スコアの改善方法を教えてくれます

Resource Hintsを用いて実行・高速化できる

resource hintsにはDNS-Prefetch、Preconnect、Prefetch、Prerenderの四つがあります。
それぞれ必要な数だけheadタグ内に設置します。

DNS-Prefetch

DNS-Prefetchを使うと外部ドメイン名（ホスト名）の名前解決（DNSルックアップ）を事前に強制することができます。
ブラウザがドメインにアクセスする前に名前解決が済んでいるので読み込み時間を短縮することができます。
特にまとめサイトなどの外部リンクが多いサイトやソーシャルメディアのボタンを複数設置しているサイトでは有効な手だと思います。

sample.html

<link rel="dns-prefetch" href="//example.com">

この場合example.comというドメイン名についてあらかじめ名前解決を試みます。
詳しい情報はこちらのドキュメントにあります。

Preconnect

DNSルックアップ単体であればDNS-Prefetchを使えばできますが
Preconnectを使うとDNSルックアップ、TCPハンドシェイク、TLSネゴシエーションといったネットワーク接続に必要なことを事前に行うことができます。

sample.html

<link rel="preconnect" href="//example.com">
<link rel="preconnect" href="//cdn.example.com" crossorigin>

クロスオリジンでpreconnectを行う場合は下の場合のようにcrossorigin属性が必要です。
詳しい情報はこちらのドキュメントにあります。

Prefetch

開発者であればページの動線がわかっているはずなので次にユーザーが訪れるであろうページがどこであるかは理解しているはずです、Prefetchを使うと指定したhtmlファイルやcssファイル、画像を事前に読み込んでおき、遷移時の表示を高速にすることが可能です。

sample.html

<link rel="prefetch" href="nextpage.html">
<link rel="prefetch" href="//example.com/next-page.html" as="document" crossorigin="use-credentials">
<link rel="prefetch" href="/library.js" as="script">

詳しい情報はこちらのドキュメントにあります。

Prerender

Prerenderを使えば指定したファイルを読み込み描画まで行っておくことが可能である、これにより遷移してすぐにページが表示されることになる。
しかし、一度に指定できるのは1ページだけであり、Chromeのスレッド全体で1つのrel="prerender"しか指定することしかできない、そのため次にユーザーが訪れるページがほぼ確定しているような場合に使用するべきだと思う。

sample.html

<link rel="prerender" href="//example.com/next-page.html">

詳しい情報はこちらのドキュメントにあります。

CDNを活用できる

CDNとはContent-Delivery-Networkの略でウェブコンテンツ配信用にネットワークを最適化することによって、アクセスが集中したりしてサーバーへの負荷が増加してもコンテンツの配信に影響が起こらないようにすることができます。

簡単にですが、具体的にはCDNではオリジンサーバーとユーザーとの間にオリジンサーバーからウェブコンテンツのコピーを取得、もしくは明示的にコンテンツを入れたキャッシュサーバーをはさみ、代理で配信することでオリジンサーバーの負荷を減少させています。

またCDNは世界中にキャッシュサーバーを置いているので、アメリカの企業がアメリカにサーバーを置いていたとしてもCDNを使用すれば日本のサーバーから
配信されるため日本にいる私たちでも早くアクセスすることができます、物理的な距離という面で速度を早くすることができます。

活用については私は一学生であり、CDNが必要なほどのサービス運営に携わったことがないため、主要なCDNの一覧を置いておきます。
どなたか知識のある方お力添えを。。。
Akamai、元祖です。
Fastly、日経新聞社さんが使用しているそうです。日経さんの速度改善の記事
Amazon cloudfront、天下のアマゾンです。
Cloudflare、こちらも有名ですね。

レンダリングブロックについて説明できる

レンダリングブロックとはブラウザの表示処理がcssファイルなどの読み込みによってブロックされることです。
ブラウザに表示が行われるためにはhtmlファイルがパースされる必要がありますが、表示するhtmlファイルに紐づくcss、jsファイルがある場合、それらもパースしてhtmlによって作成されたDOMに紐づける必要があり、これにより初期描画が遅れます。

もっと詳しいことが知りたければgoogleのドキュメントを読みましょう。

描写される順番について理解している

ブラウザのレンダリングはLoading→Scripting→Rendering→Paintingの順で実行されます。

Loading

htmlファイル、cssファイル、jsファイル、画像がダウンロードされます。
htmlとcssをパースします。

Scripting

jsファイルを解釈してjsを実行し、抽象構文木を作成します。

Rendering

cssスタイルの適応とレイアウト算出を行います。

Painting

jsを適応して最終描画を行う。

HTML→CSS→JS→画像　の順で読み込まれます。

セキュリティ

安全なウェブサイトの作り方を参照できる

安全なウェブサイトの作り方を読みましょう

同一、クロスオリジンのそれぞれの違いが説明ができる

二つのページのプロトコル、ポート番号、ホストが等しい場合同一オリジンです。

以下MDNより参照
以下の表は、各行の URL が http://store.company.com/dir/page.html と同じオリジンであるかを比較したものです。

URL	結果	理由
http://store.company.com/dir2/other.html	同一オリジン	パスだけが異なる
http://store.company.com/dir/inner/another.html	同一オリジン	パスだけが異なる
https://store.company.com/page.html	不一致	プロトコルが異なる
http://store.company.com:81/dir/page.html	不一致	ポート番号が異なる (http:// は既定で80番ポート)
http://news.company.com/dir/page.html	不一致	ホストが異なる

XSSとは何かを説明できる

XSSとは(Cross Site Scripting)のことで、CSSでないのはCascading Style Sheetsと被るからだそうです。
ウェブアプリケーションに対する代表的な攻撃手段のことで、簡単にいうとユーザーがWebページにアクセスすることで不正なスクリプトが実行されてしまう脆弱性または攻撃手法のことです。
不正なスクリプトを含むURLを踏ませることによって、その踏んだユーザーのブラウザで不正なスクリプトな実行され、Cookieなどからログイン情報などを抜き取られてしまうことが被害例として挙げられます。

多分大丈夫だとは思いますが、掲示板などの投稿型のウェブアプリケーションなどを運用している人は気をつけましょう
wanko5296さんの記事の図がわかりやすかったです。

対策方法についてコードベースで説明できる

sample.html

<!-- 属性値を引用符で囲む -->
<!-- 良い例 -->
<input type="text" value="$data">
<!-- よくない例 -->
<input type="text" value=$data>

<!-- urlが投稿できる場合、事前にスキームをhttp、httpsであるかを確認する -->
if ($data !~ /^(http|https):/) {
  エラー文
}

vue/reactそれぞれのフレームワークでのXSS対策のページがあったので共有します。
vue
react

ブラウザ側での脆弱性対策について理解している

対策の方法としてはフォームなどにスクリプトを埋め込むことができないようにすることです。
具体的な説明をすると

• 入力できる値を制限する（バリデートする）こと
• &，<，>，”，’といった文字をエスケープしてスクリプトを無害化すること
  が挙げられます。

詳しくは安全なウェブサイトの作り方に全て載っています。

CSPとは何かを説明できる

CSPとはContent Security Policyの略で、該当するウェブページについてContent-Security-PolicyHTTPヘッダーを返すように設定し、実行を許可するスクリプトの正しいドメインをブラウザーに向けて指定することによりXSSの発生する箇所を削減・根絶することができます。

もう少しいうと、HTTPヘッダーやmetaタグを設定すだけで<script>～</script> などのインラインスクリプト、onclick="～" などのイベントハンドラ、href="javascript:～" や eval() によるスクリプト実行が禁止され、実行するスクリプトファイルも許可されたものだけにできます。
詳しいことはMDNにあります。

SameSite Cookieについて説明できる

SameSite CookieとはCookieの送信を制御するSameSite属性の仕様のことで、「現在のドメイン」から「遷移先ドメイン」へCookieが送信されるのを制御することです。ドメインをまたぐリクエストに対してCookieを自動付与しないようにすることで、安全性の向上につなげていきます。
これにより「偽装されたリクエスト」に対してCookieを送らなくなるので、CSRF（Cross Site Request Forgeries）」や「Timing Attack」への対策となります。

MDNです。

npmモジュールの脆弱性をチェックをする方法を知っている

まずは脆弱性を調べたいプロジェクトに移動してnpm auditをします。
そうすると

こんな感じで脆弱性のあるパッケージについて表示してくれます。
high moderate low の三つのレベルがあってhigh moderateは解消した方が良いです。

npm auditにはnpm audit fixというコマンドもあり、大抵の脆弱性は自動で解消してくれます。
治らない脆弱性は手動で直す必要があります。
hibikikudoさんの記事を読むのをお勧めします。

npmのモジュールの問題で動かなかった場合の個人的な解決法

まず

• npm auditで脆弱性がないかを確認して
• npm outdatedでバージョンが古すぎていないかを確認するようにしています、古かったら依存関係に注意しながら更新します。

大体これで直ります。
依存関係の場合とかだとエラー文で探したらgithubのissueとかが出てきて解決したこともあります。

それ以外だとグローバルに変なのが入っている（グローバルにnode moduleがある）、vscodeのバージョンが古すぎて言語のバージョンがずれてるとかが自分が過去経験しています。

デザインツール

デザインツールに関してですが、ほとんど参考リンクを貼るだけになってしまいました。

プロダクトのデザインツールで何が使われているか理解している

デザインツールに何が使われているかはチーム、会社によって異なると思いますが、AdobeXDやSketch、Figmaが多いと思います。
わからない場合は確認しておきましょう。

ここから先はデザインツールごとの話になるので、上記したデザインツールを使用したことがない方はどれか一つを選んで使い方を練習してみるといいと思います。
（すでに作成してあるウェブアプリケーションのデザインを作成してみるなど）

私自身sketchを使用したことがないですが、AdobeXDもFigmaも無料で使用することができるので一度触ってみることをお勧めします。

画像の書き出し方について理解している

それぞれのツールごとにやり方があります。
AdobeXDでのやり方
Sketchでのやり方
Figmaでのやり方

2倍や3倍の解像度書き出し方が分かる

ディスプレイによって解像度が異なります、例えば最新のmacbookなどはretinaのディスプレイで解像度が高いです。
このような解像度の高いディスプレイではきちんと対応しないと画像がぼやけてしまいます。
その対応のために解像度を2倍、3倍で書き出す必要があります。
AdobeXDでのやり方
Sketchでのやり方
Figmaでのやり方

un-Techさんの記事が解像度についてわかりやすかったです。

アイコンの場合、SVGにて抽出できる方法を知っている

SVGはScalable Vector Graphicsの略で利点としては、GIF PNG JPGのようなビットマップ画像ではなくベクター画像なので画像を拡大しても粗くなりません。
そのため上記したような解像度の対応は必要なくレスポンシブの対応をしても一つのファイルで対応できます、しかしベクター画像は計算式によって画像を表現しているため、写真などの多くの色を使うものには不向きです。
なのでアイコンなどのあまり多くの色を使わない際に使われます。
また写真のように色を変える際にわざわざデザインツールを通さなくてもcss上で色を変更することが可能です。

AdobeXDでのやり方
Sketchでのやり方
Figmaについては上記したURLと同じです。

CSSを抽出できるものの場合、どこから確認すればいいか理解している

おそらくAdobeXDしかできない？と思うのでXDのリンクを貼っておきます
AdobeXDの場合

スポイトツールで色の抽出ができる

スポイトツールを使うと他の部分で使われているカラーコードを取得することができます。

AdobeXDでのやり方
Sketchでのやり方
Figmaでのやり方

要素間の空きや余白がどれくらいあるか確認することができる

全てのツールで同じだと思いますが、始点としたいオブジェクトを選択した状態で、比較したい要素をホバーすると間がピクセル数で表示されます。
remやemを使っている場合は別途計算が必要ですが、ピクセルパーフェクトが求められる場合はこれがわかっていればcssを書くのがとても楽になります。

画像

ベクター画像とビットマップ画像の違いを説明できる

SVGのところでも説明しましたが、ベクター画像は点と線を数値化しそれを計算式によって画像にしているため、拡大したりしてもそれに応じて計算式の結果が変動し画像が粗くならないです。
一方で写真などの多くの色を使うものには不向きでアイコンなどに用いられることが多いです。
ビットマップ画像は点の集まりで構成される画像のことで点の集まりであるため拡大すると点の細かさに限界がきて画像が粗くなります。
一方できめ細やかな色表現を行うことができ、写真などは全てビットマップ画像です。

各画像圧縮方式についてざっと説明できる

圧縮は、非可逆圧縮と可逆圧縮の2種類があります。

非可逆圧縮

圧縮前の状態に戻すことができない圧縮方法です、つまり圧縮済みのファイルを解凍しても圧縮前の状態に戻すことができないです。
データの一部を除去します。画質が悪化する為、画像をどれだけ圧縮するかに注意する必要がありますがファイルサイズは大幅に減らすことができます。

可逆圧縮

圧縮前の状態に戻すことができる圧縮方法です、つまり圧縮済みのファイルを解凍することによって圧縮前の状態に戻すことが可能です。
データを圧縮します。画質が悪化しませんが、レンダリングする前に画像を圧縮解除する必要があります。

詳しい説明は省きますが、オリジナルの画像だとファイルサイズがとんでもないことになってしまうので圧縮は必須です。
きちんと圧縮してから画像は使うようにしましょう。

JPG, GIF, PNGの拡張子それぞれの特徴について説明できる

JPG

JPG（ジェイペグ）はJoint Photographic Experts Groupの略で名前の通り写真に適した画像形式です。
ファイルサイズが小さくても綺麗に写真を写せます。一方で非可逆圧縮を使用しているため上書き保存するたびに画像が粗くなります、さらに背景を透明にすることができないです。
似たような拡張子にJPEGがありますが、違いはないです、JPGの方がよく使われているのでどちらかに統一する場合はJPGに統一しましょう。

GIF

GIF（ギフ）はGraphics Interchange Formatの略でアニメーションでよく使われている画像形式です。
データ容量がとても小さく、背景を透明にすることも可能ですが、色を256色しか使用できません。ロゴやイラスト、アニメーションに使われます。

PNG

PNG（ピング）はPortable Network Graphicsの略でGIFが特許問題で自由に利用ができなくなった際に専門家達によって作成されました。
JPG、GIFの問題点を解消するために生まれたので高画質の画像を生成し、透過、画像の劣化にも対応しており、GIFの問題点であった256色しか使えないという問題点も解消していますが、ファイルサイズが大きくなってしまいます。

普通の写真はJPG
ロゴやアイコンはSVGかGIF
高画質な画像を使いたい場合、写真だけど背景を透過させたい場合はPNG
などと使い分けられると良いと思います。

WebPを用いることのメリットについて説明できる

WebP（ウェッピー）はGoogleが開発している新たな画像フォーマットです、2010年ごろからあるらしいです。現在IE以外の主要ブラウザは対応しています。

WebPを用いることのメリットは非可逆圧縮であるにもかかわらず透過させることができる点です。つまり透過画像をWebPで書き出せます。
またファイルサイズを非可逆圧縮であるJPGより小さくすることができます。（25%~34%小さくできるそうです）

WebPへの変換方法についてはGoogleが提供しているcwebpがあるのでこちらを使うと良いと思います。

レスポンシブデザイン

レスポンシブデザインにする必要について説明できる

ユーザーがページを閲覧する際に使用する端末として、パソコン（ラップトップ、デスクトップ）、モバイル、タブレットが挙げられますが、レスポンシブ対応をすることによってパソコンのユーザーとモバイルのユーザーのためにわざわざ別ページを用意したりする必要がなくなります。

また現在のブラウザなどへのアクセスはスマートフォンなどのモバイル端末の普及率の高さからも無視できる量ではないですし、むしろそちらからのアクセスの方が多い可能性まであります。
この辺はGoogle Analyticsなどを導入していればどの端末からのアクセスが多いのかを理解できると思います。
もしスマホからアクセスした時にPC用のページが出てきてブラウザバックされてしまうととても勿体無いです。

この辺りのユーザーを取り込むためにレスポンシブデザインにする必要があります。
もちろんユーザーが100％パソコンからのアクセスなどであるのならば対応する必要はないです。

中間幅についての挙動を考慮した提案ができる

中間幅というのは例えばスマホとタブレットの間の中途半端な画面サイズなどの時の話です。

この記事が全てだと思います。この記事を読んで実践するべきです。
Thinking About The In-Between Design Cases

日本語訳されているものがあるのでこちらも貼っておきます。
日本語訳版

どのブレイクポイントがあるとよいか理解して説明できる

ブレイクポイントはレスポンシブの境界です、例えば767px以下はスマホ用の画面など
@media (max-width: 767px) {}

これはどの端末のユーザーに向けてサービス・ページを作成しているかに依るのでひとくくりにはなんとも言えないです。
個人的には

• ラップトップ 1080px ~
• タブレット 429px ~ 1079px
• モバイル ~ 428px
  です。

もちろん私の経験が足りていないことは百も承知なので意見があればいただきたいです。

Hashimotoさんの記事がとても勉強になりました。
特に一覧をまとめたPDFがとてもわかりやすかったです。

OSS

セマンティック バージョニングにおいて各数字が何であるか理解している

セマンティック　バージョニングにおいては　major.minor.patch　とします。
APIをすでにプロダクションとして提供しているのであれば1.0.0からはじめれば良いと思います。

major

APIの変更に互換性のない場合はメジャーバージョンをあげます。
major番号が0のものは開発段階を指し、この時はどの数字が上がっても後方互換性はないです。

minor

後方互換性があり機能性を追加した場合はマイナーバージョンをあげます。

patch

後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。

rc

rcはrelease candidateのことで最終確認バージョン（プレリリース）のことです。

例えばcomposition-apiは@vue/composition-api": "^1.0.0-beta.22となっています

プレリリースは、通常バージョンより低いバージョンです。
1.0.0-beta.22 < 1.0.0　となります。

プレリリース文字列にも順番があります。
1.0.0-alpha < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-RC < 1.0.0

composition-apiのバージョンがbeta.22となっているように2までというわけではないです。
みたことないですがgammaとかもあります。

なぜセマンティックバージョニングを使用するのかは読むべきです。

ライセンスの有無を理解している

GitHubなどで新しくリポジトリを作る時にライセンスファイルを作るかどうか選べると思います、あれです。

ライセンスに則った使用をしている

年末にTatamoさんの記事が上がっていたのでこれがとてもわかりやすかったです。

使用しているバージョンがEOL（End of Life）かどうかを確認できる

witchcrazeさんの記事がよかったです。

EOLになる場合のアップデート対応や方針などを説明できる

EOLになってもその日付にサービスが終了するわけではありませんが、その後に発生するエラーやセキュリティの脆弱性などへの対策が行われなくなります。
アクシスさんの記事がEOLについてまとまっていてよかったです。

場合によってはIssueやPull Requestなどで提言できる

おそらくみなさんGitHubは使ったことがあると思うのですが、リポジトリのIssueにエラーの報告を行ったり、自分で発見したエラーを解決するPull Request(以下PR)やすでにバグとして挙げられているIssueを解決するPRを出すことで自分の使用しているライブラリやフレームワークに貢献することができます、
このZennでもIssueをたてるところがあるのでもしよければ活用してみてください。
Zenn Roadmap

運用している場合、どのようにメンテナンスしているか説明できる

運用していないので全くわからないです、どなたか助けてください。

よくあるライセンスの種類について知っている

ライセンスごとのコンテンツの利用制限について知っている

全然知らなかったのでloveeさんの記事を参照します。

ライセンスの種類としては
copyleft系 permissive系があります。
copyrightが権利という意味なのでそれに反する(自由にして良い)という意味でcopyleft、それに寛容という意味のpermissiveという言葉で系統があります。

copyleft系の代表的なライセンスにGPLがあります
GPLライセンスの特徴としてはGPLライセンスで配布されているOSSを改良したりしてそれを公開する場合は必ずGLPライセンスで配布しなければなりません

permissive系の代表的なライセンスにBSD、MIT、Apacheがあります。
permissive系のライセンスはcopyleft系と異なり、permissive系のソースコードを改変して公開する場合にも必ず元のライセンスと同じもので公開しなければならないというような制限はありません。
BSDライセンスはライセンスの原文を手動で一部（年数と著者）を変更しなくてはならないようです。
MITライセンスはBSDと違って手動で変更する必要がありません
Apacheライセンスは上記のふたつと二次改変についての制限は同じですが、ゆるすぎたために企業にとって逆に使いにくいという状況になったそうです。
その点で特許や商標に関してだけ制限をかけることができるのがApacheライセンスです。

最後に

セキュリティの部分が知識なさすぎて調べながら書いたのでかなり時間かかりました、しっかり知識を蓄えていこうと思います。
まとめてどこかにおいておきたいのでQiitaに投稿するかもしれないです。