Web ページを高速化して ユーザーに価値を届けたい 制作者のための セミナー＆ワークショップ資料公開
Web ページの高速化セミナー WCAN 2018/09/15「Web ページを高速化してユーザーに価値を届けたい制作者のためのセミナー＆ワークショップ」 - WCAN | Doorkeeper 先日、2018年9月15日にひっさびさに WCAN に登壇させていただいて Web パフォーマンスチューニング....のなかでもページロード速度の高速化を中心にセミナーとワークショップを行わせていただきました。 下記はそのときの資料です。今回は Web サイト制作者向けのセミナーとして企画したので、Web アプリ開発勢が好きそうなテクニカルな話はすべて割愛しています。 ウケが良かったような気がするネタ なにがウケるか読みがつかなかったので、とりあえず色々盛り込んでみました。会場では下記のあたりがウケが良かったような....気が...する。 格安 SIM の回線は、大手キャリアのプロパー回線と比べる
ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感（新規開発のメモ書きシリーズ2）
たくさんある道具をどのように組み合わせるか 今回はコード設計編のつもりでしたが、ビルド周りを先にまとめることにしました。主にパフォーマンス上の都合ですが、心がけたポイントは次の点です。 画一的なバンドルではなく、適切なバンドルを選択的に配信できるようにする 適当な粒度で Code Splitting できるようにする ひとつのツールに何でもかんでもやらせない（ webpack、お前のことだよ！） ビルドのパイプラインを短く、シンプルに済ませる（できることを全てやろうとしない） タスクランナーは前回述べた通り make を利用しています。同僚が使っているのを見てパクりましたが Self-Documented Makefile の手法が、タスク名忘れに優しくてよかったです。 npm run したら npm scripts が一覧で出てくるのと似たようなやつです。 このシリーズの他の記事はこちら
技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選（新規開発のメモ書きシリーズ1）
新規開発したプロダクトについて ｢世の中に URL は出ているが、まだ正式公開していない｣という微妙な位置付けなのでプロダクト名と詳細は避けつつ述べます。短めの開発期間で急いでつくって、慌てて年末にβ版をリリースしたところです。 次の動きに向けてまったりしたり、Inside Frontend の開催に向けて四苦八苦しているところでメモ書きです。 このシリーズの他の記事はこちら。 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離 依存するパッケージの厳選 新しい技術、ライブラリを試すこと、それらを使って生産性の向上にチャレンジすることは必要です。とはいえ、程度が過ぎると逆に生産性を下げかねない
Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
App Shell モデルの素振り（前編）webpack と Workbox を利用した構築
App Shell モデルという設計パターン App Shell モデルは、共通のガワ部分を構成する HTML、CSS、JavaScript をシェルと定義し、その中に入る動的なコンテンツ部分と構造的に分離して扱えるように設計されます。 アプリケーション シェル（App Shell）アーキテクチャは、ネイティブ アプリのように瞬時に、そして確実にユーザーの画面に読み込める Progressive Web App を構築する方法の 1 つです。 アプリの「シェル」とは、ユーザー インターフェースが機能するために必要な最小限の HTML、CSS、JavaScript です。これらをオフラインで使用できるようにキャッシュしておくことで、ユーザーが同じページに再アクセスした際に、瞬時に高いパフォーマンス が発揮されます。つまり App Shell は、ユーザーがアクセスするたびにネットワークからす
Web アクセシビリティ向け Node.js 製の自動チェックツールや DevTools 用の拡張機能など
アクセシビリティを担保するプロセス作り この記事は Web Accessibility Advent Calendar 2016 - Adventar の 12 日目の記事です。 UI 実装の再考と a11y - Frontrend Vol.8 LT でも述べましたが、Accessibility is a Process, Not a Project ということでアクセシビリティ対応するプロジェクトではなく、アクセシビリティを担保するプロセスを作りましょうということで、チェックツールをいくつか並べて俯瞰してみます。対象読者は自分と同じようなクライアントサイドの Web アプリケーション屋さんということにしておきます。 ちなみにアクセシビリティ評価ツールについては 3 日目のアクセシビリティ方針、報告書、試験支援ツールa11ycのご紹介 (Web Accessibility Advent C
続・パフォーマンス計測実験で Graphite も Docker に置き換えた
前回、Sitespeed.io + Docker と Hosted Graphite で Web のパフォーマンス計測実験 の続きで Graphite 周辺を Docker に置き換えたログです。 Graphite + Grafana + (StatsD) 上記がすべて入っている Docker イメージを利用します。 choopooly/grafana-graphite Repository | Docker Hub Registry - Repositories of Docker Images sitespeed.io がサポートしているのは graphite のフォーマットなので statsd は使いませんが上記のイメージではポート 2003 も EXPOSE されているので、そっちを利用します。 80: the Grafana web interface. 2003: the St
既存 Web アプリケーションのアクセシビリティを向上させるときによくあるヤツと対応方針
アクセシビリティ向上メモ 最初から考慮されているのが一番ですが、そうでもなかったプロダクトに手を入れるときのあるあるを記録します。既存プロダクトはモノが出来上がってしまっているため根治的なリファクタリングよりも基本的には省力で済ませたいので、今回書いた対応方法も完璧よりは省力路線です。 HTML やらセマンティクスに関する知識はそれなりにあるつもりでしたが、AT やマシンリーダビリティを念頭に勉強し直すと自分で作ったものも至らなかったなと振り返らざるを得ない今日この頃。初期設計のときの考慮範囲が拡がったように思うので善きかなです。 各項目について、もっと良い解法や誤り等あれば twitter とかでご指摘ください。 1. 画像に alt 属性がない場合 付けましょう。付けます。はい。 昔から基本とも言うべき、HTML/CSS 書きとしては耳にたこができるほど言われてきたことなので今更感もあ
React v0.14.x から v15.2.x へのアップデート録
react v15.2.x アップデートに関連した記録 FRESH! by AbemaTV と AbemaTV の React を v0.14.x から v15.2.x にアップデートしたので、遭遇した WARN などについてメモ。 基本的には React v15.0 | React を読めばマイグレーションガイドがありますが、今回の作業で実際に遭遇したものだけ対応を記録します。 不明な prop を渡すなエラー … Unknown props foo, bar... on <***> tag. Remove these props from the element. <div {...props} /> のように、下位コンポーネントに対する props の雑な継承で WARN が発生します。DOMAttribute として正しくない prop が要素に渡ると警告の対象です。詳細は Unk
Web サイトっぽい SPA に必要なブラウザナビゲーションのエミュレートなど
Web サイトっぽい SPA に立ち向かう 大分前の話ですが、Node学園 20時限目 今回もdots!!!!! - connpass で Client Side of なんちゃらfresh.tv としてお話した内容のうち、Web サイトっぽい SPA に関してだけこだわりを再抽出して書き留めます。 本件は、ページ全体のスクロールや頻繁なナビゲーションを伴わず、1画面におさまるレスポンシブな Web アプリを作っている場合はあんまり関係がありません。画面内の局所的な状態更新は、コンポーネントの責務分割やら何やらの設計なので実は別の話です。 総じて、Web サイトっぽいくせに大人の事情で Web ブラウザのネイティブなナビゲーションを積極的に破壊しにいくときの心構えです。 URL が変わっても最低限レンダリングできるまで画面更新を遅延させる 画面遷移に必要なのは、 URL が更新されても次の
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
iOSアプリにおけるアクセシビリティの概観メモ
iOS のアクセシビリティ Android アプリのアクセシビリティガイドライン概観メモ ::ハブろぐ の続きです。前回、iOS のドキュメントをうまく見つけられなかったので Android だけ目を通しましたが iOS も読んでみます。 プログラミングガイド iOSアクセシビリティプログラミングガイド は、幸い日本語が用意されてるので読みやすくて安心です。英語版は PDF でありませんが Accessibility Programming Guide for iOS と About Accessibility Verification on iOS に相当するものと思われます。 なお、英語の情報は Accessibility on iOS - Apple Developer に動画なども合わせてまとまっています。 Apple いわくアクセシビリティは正義 最初に目についたのは「なぜアプリ
Android アプリのアクセシビリティガイドライン概観メモ
ネイティブアプリとアクセシビリティの関係 Web が専門ではありますが、アクセシビリティを通した品質向上を考え始めると、Web だけでは社内のプロダクトの半分あるいはそれ以下程度のカバレッジしかありません。 そこで今回はネイティブアプリ、特に Android のガイドラインについて目を通したメモ。 プラットフォームのガイドライン ネイティブアプリの筆頭たる iOS と Android においては、WCAG 2.0 ほどは詳細化されてこそいないものの、各プラットフォームでガイドラインが提供されています。 Implementing Accessibility | Android Developers Accessibility for Developers - Apple Developer とはいえ、この2つ見比べてみると iOS のドキュメントはそれほど充実していないような印象です。どうも
babel な ESLint の設定をがんばった
やんなくちゃなー、と思っていたので Lint Like It’s 2015 — Medium を眺めながら、ahomu/es6-Kameita の JavaScript Linter を ESLint に乗り換えました。 Lint の設定つくるのがダルイ問題 本当にだるい。この投稿を書いている時点では .eslintrc を以下のようにしました。 スペースの入れ方については、強い意志をもって堅めの設定になっているはず。 max-params はちょい甘めです。consistent-this を全力で否定しているので、流用したい方は気をつけた方がよろしいかと。 { "parser": "babel-eslint", "env": { "browser": true, "node": true }, "rules": { "strict": 2, "default-case": 2, "no-
jit-grunt で grunt をキビキビ動作の高速化
Take Grunt to the Next Level — Jonathan Suh この記事を見て知ったのだが、jit-grunt というプラグインが中々よい。Just In Time ということで、タスクのロードを loadNpmTasks でまとめて最初にやる代わりに、各タスクの実行時までロードを遅延させるというもの。 npm の jit-grunt ページを見ると相当数がダウンロードされて利用者がいるようだが、検索するとあまり紹介されてないようだったので書いてみる。 効能 17個のタスクをロードしていた手元の環境に導入したところ、単純なタスクを実行した限りでは次のような実行時間の短縮が見られた。計測は例によって time-grunt だ。 Before loading tasks で 625ms かかっていて、全体では 651ms を要した。 % grunt concat:lib
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
AngularJS についての所感
AgularJS に対する気持ち 所感といいつつ、主に自分がつらさとして感じていることを書く。所感シリーズとしては jQueryについての所感 も併せて読みたい。 この学習曲線の中でいうと、たぶん今の自分は Very Cool! の頂点から降りている最中くらいだと思う。そして、マサカリをふりかぶった諸兄にひとつだけ言いたいのは、共感脳を養った方がモテるということだ。 チキンハート的弁解: 以下はAngularJSに関するつらさを述べることに専念するために、美点を挙げていないだけであってAngularJSを全方位的に貶めたり、何かと比べて明確にクソだというような意図はない。 画像は AngularJS: The Best Parts · Anand Mani Sankar からの引用。X軸にある www.bennadel.com は AngularJS 大好きさん。 辛1. $scope が
さくらのVPS借り直してCentOS 7でLEMP+HTTPS
お引っ越し さくらのVPSに引っ越しました ::ハブろぐ を書いたのが2010年9月28日ということで、かれこれ4年も前のはなしです。東京リージョンのメモリ1GB HDD20GBで、プラン的にもまあまあ古い。当時、CentOS 5だったのも5.9までは上げたところで6系にアップグレードする勇気と手間を出せないまま、世間ではCentOS 7がリリースされました。 今回、メモリ2GB HDD200GBのプランを新しくレンタルしてセットアップすることにしました。標準ではCentOS 6でしたが、カスタムOSインストールでCentOS 7を選べたので、CentOS 7を入れて利用します。 CentOS 7｜カスタムOSインストールガイド｜さくらのVPS｜さくらインターネット公式サポートサイト LEMP Stack + HTTPS/SPDY 以前はnginxをフロントにして、後ろでapache+mo
Sitespeed.ioのルールセットを眺めてSPOFに思いを馳せた
Sitespeed.io - Analyze your website speed and performance 大分前に見かけた気がするんですが今更ためしてみた。普通に使う分には以下のような感じでインストール＆実行できます。 # インストール brew tap sitespeedio/sitespeedio brew tap tobli/browsertime brew install sitespeed.io # 普通にたたく sitespeed.io -u http://havelog.ayumusato.com # モバイル用ルールセットで、depth=3までクローリングする sitespeed.io -u http://havelog.ayumusato.com -l sitespeed.io-mobile -d 3 これでしばらく待つと、sitespeed-result とい
Concatだけでビルドを済ませてた例（Backbone.jsとAngularJS）
Concatでどこまで戦えるのか @jxck_ browserify使ってるんだけどあんま意味ない感じになっててつらいんだよねーっていうのを昨日 @ahomu に話したら、concatで全然いけますよって言われたからさっき乗り換えた。 — Kazuhito Hokamura (@hokaccha) August 6, 2014 (＾ω＾) 全然いけますよ 依存管理をサボってconcat 以下、「依存管理に労力を割きたくない」という理由で依存管理を省略した場合に、concatだけで破綻無くビルドするためにやっていたパターンの紹介。いけますと言った手前はあるが、最終的には現場によってケースバイケースということで、どうかひとつご容赦願いたい。 Case 1: Backbone.js Backbone.jsの場合、extends に代表されるクラスベースのオブジェクト指向モデルに多少の制約が必要に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
