ちいさな Web ブラウザを作ってみよう（オンライン講義版） / Build Your Own Web Browser本資料はセキュリティ・キャンプ全国大会 2021 B1 の講義で利用したものです。お問合せは Twitter アカウント 宛によろしくお願いします。
Sign-up form best practices | Articles | web.dev
Sign-up form best practices Stay organized with collections Save and categorize content based on your preferences. Help your users sign up, log in and manage their account details with a minimum of fuss. If users ever need to log in to your site, then good sign-up form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designe
Modern Web Development on the JAMstack を読んでまとめた - console.lealog();
https://www.netlify.com/pdf/oreilly-modern-web-development-on-the-jamstack.pdf Netlify社が2019年に公開した本？PDFです。 せっかくJamstackの会社に入ったので、読んでおかないといけない気がして。 あとJamstackは人によって解釈が違ったりするとし、Jamstackの真髄について知っておきたいですよね？と思い。 ただこれなんと127ページもあるんですよね〜。 全編もちろん英語なので、読むのも中々に大変ですよね〜。 てなわけで、ざっくり訳してまとめまておきました。（それでも長いけど） はじめに ここ最近のWebの進化はすさまじい ブラウザもJavaScriptもパワフルになった その分ユーザーの要求も増える やることが増えると処理は遅くなる 遅いページは見向きもされないモバイル当たり前の世界だ
HTML標準仕様の策定についてW3CとWHATWGが合意発表。今後はWHATWGのリビングスタンダードが唯一のHTML標準仕様に
HTML標準仕様の策定についてW3CとWHATWGが合意発表。今後はWHATWGのリビングスタンダードが唯一のHTML標準仕様に W3CとWHATWGは、HTML標準仕様の策定について合意したことを発表しました。 いわゆるHTML5と呼ばれるHTMLの最新仕様には、WHATWGが公開しているものとW3Cが公開しているものが併存しており、しかも両者には一部で異なる仕様があったために混乱を招いているところがありました。 今回の合意によりW3CはHTMLとDOMに関する標準策定をやめ、今後はWHATWGが策定するリビングスタンダードがHTMLとDOMの唯一の標準となります。 両者が合意した主な内容は下記となります。HTMLとDOMのリビングスタンダード、すなわちつねにアップデートされていく標準仕様はWHATWGがメンテナンスをし、W3Cはそれに協力していくこと、W3Cは今後単独でのHTMLとDO
Chrome Dev Summitに参加しました！ - from scratch
Chrome Dev Summit に初参加しました！色々トピックとして気になったものを紹介してます。後直接 Addy Osmani とか Paul Irish とかに聞く機会があったので、色々ついでに聞いてきました。 Chrome DevRel teams create a Chrome cake #ChromeDevSummit [pic.twitter.com/5u6VPZ0oHb](http://pic.twitter.com/5u6VPZ0oHb)— Yosuke FURUKAWA (@yosuke_furukawa) November 12, 2018 Chrome も 10 周年なんですよねー。感慨深い。 1日目は「現在のChromeでできること、やってること」という感じで、ケーススタディやツールチェインの話が多めでした。 2日目は「未来のChromeでできること、今後やるべ
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、**改善施策ってまず何をどうすればいいの？**という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。
中級者向け Service Worker Tutorial | blog.jxck.io
Intro Service Worker の初心者向けのチュートリアルや、使ってみた系のエントリも増えてきました。 しかし、 Service Worker は通常のブラウザ用 JS の開発と少し経路が違い、慣れるまで開発やデバッグもなかなか難しいと思います。 そこで特に難しい部分、そして分かっていないと実際にデプロイした際に難しいと思う部分について、実際に動きを確認しながら解説したいと思います。 なお、 Service Worker の基本的な概念などについては、他のチュートリアルなどを見て理解している前提で進めます。 思いつきで撮ったので色々ミスも有ります、また Chrome Dev Tools の UI はどうせ変わるのでそのつもりで見てください。 TODO になっている動画は、そのうち撮って追加します。 List claim controllerchange updatefound
TLS1.3だとハンドシェイクがどれくらい早くなるか測定した | GREE Engineers' Blog
こんにちはインフラの後藤です。 今回はTLS1.3を実環境で試してみました。 TLS1.3はTLSのメジャーバージョンアップとも言われるように、様々な改善が含まれています。 例えば、以前「TLS1.3のハンドシェイクがもう来てる」で書いたように、TLS1.3ではハンドシェイク時のパケットの往復回数が減っており、より早くコネクションを確立できます。 すでに、ブラウザや暗号ライブラリはTLS1.3に対応してきておりますので、実環境で具体的にどれくらいコネクションの確立が早くなるのか確認してみました。 TLS1.3 バージョンネゴシエーションとネゴシエーション 測定の前に今回利用したTLS1.3 draftバージョンについて補足します。 TLS1.3は draft-28 版が最新のバージョンです。こちらが文章上の修正を経て将来的にRFCとなります。 TLS1.3はファイアウォール等の中間装置の不
IETF報告会で「TLS 1.3とその周辺の標準化動向」について発表してきた
先週金曜日に開催されたIETF報告会にて、「TLS 1.3とその周辺の標準化動向」について発表する機会をいただきました。その際のスライドが下のものになります。 TLS 1.3や関連する提案の技術的特徴とともに、スノーデン事件以来のテーマである通信内容のプライバシー保護とオシフィケーション（硬化）対策がどのように進んでいるか、ご理解いただける一助になれば幸いです。 なお、本スライドは会社のテンプレートを使用していますが、会社としての見解を表明するものではありません。 Most schools also offer drama studies, music and physical education but these are usually not examined or marked. Home economics is sometimes taught to female studen
日経電子版を支える広告技術 — HACK The Nikkei
本稿では、現在の日経電子版モバイル Web（以下、日経電子版）における広告掲示の技術について解説する。 広告とサイトパフォーマンスの関係 dev.to に代表されるような「高速」と言われる Web サイトは、CDN や ServiceWorker などを駆使して表示に関して適切なチューニングを行っており、日経電子版もほぼ同じ思想の元チューニングを行っているが、一点大きな違いを挙げるとするならば、広告表示の有無が挙げられる。 現在の日経電子版では 7 タイプの広告を表示しており、うち 4 タイプは外部 DSP からの配信を行っている。 その他にも様々なサイトトラッキングのサードパーティスクリプトを導入しているが、ご存知の通りこれらはメインとして打ち出したいコンテンツとはほぼ関連性はなく、パフォーマンス観点から見れば劣化させる要因でしかない。広告が無ければもっと速く表示できるのに…と思ったこと
結局 PWA は来るの？来ないの？
昨日 Twitter でこんな記事を発見しました。 PWA が来るって言っているエンジニアは今すぐ辞めろ 「instagram の PWA が最高〜！ネイティブと見分けつかない！！とかほざいているグー○ルのエバンジェリストだかエンジニアが騒いでいたので触ってみたのだが、オワコンであった。」 もしかしてこれのことかな？ Instagram PWA is sooooooo impressive. I probably won't be able to distinguish it with its native app. InstagramのPWAが、デキが良すぎて感動してる。ネイティブアプリと見分けられる自信ない。 pic.twitter.com/DS8TfceBZ6 — Eiji Kitamura / えーじ (@agektmr) 2018年1月26日 確かに、この言い方は若干煽り気味のと
BFF/SSRの話
Mercari Web / Frontend meetupで話した BFF/SSR の話です。
“Web Componentsだけ” で新サービスを実装して見えたこと - Qiita
Double O というサービスを作りました。 フロントエンドはピュアな Web Components を採用していて、バックエンドは Lambda と DynamoDB のみで構成しました。 (厳密には CloudFront とか API Gateway とかもあるけどそこは省いていいよね？) REST API 以外の Util 系の Lambda 関数はすべて AWS Cloud9 で管理することで環境構築も不要な Lambda ができて楽でした。 TL;DR サーバーレスについてはごく普通のことしかしていないので、詳しくは触れないでおきます。 ピュアな Web Components だけでサービスを成立させることができた。 HTMLElement クラスを継承するだけなのでメジャーライブラリは不要になった。 Web Components の Custom Elements は標準仕様
Hayato.io
Hayato.io This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: music videos All Inclusive Vacation Packages Healthy Weight Loss Anti Wrinkle Creams Top 10 Luxury Cars Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
リニューアルした日経電子版が高速すぎてヤバイ件｜こんぴゅ
日本経済新聞は国内を代表する経済誌だ。その電子版はwebでの継続課金を大成功させ、いまや50万以上の有料会員を擁するモンスターサイトだ。 その日経電子版が11月6日に全面リニューアルしたのだが、公開後、web業界がにわかにざわついた。表示速度が爆速だったのだ。日経公式もモバイルで2倍の表示速度を達成したと堂々と宣言していた。 webサービスは継続率こそ神KPIで、その継続率には速度が大きく影響する。 これはチェキらないとヤバイと感じ、友人のkitakさんとスピードの秘密を調査してみた。 Fastlyをコンテンツキャッシュに使う殆どのデータはFastlyを経由して取得されていた。Fastlyは最近注目を集めているCDN（世界中にエッジサーバーを配置し、高速にコンテンツを配信するサービス）で、非常に高機能でユニークなサービスだ。 一般に、CDNはいったん世界中にコンテンツをばらまくと、それを無
やっぱりサーバーサイドレンダリングなんかしなくていいやという気持ち - console.lealog();
個人の意見 aka ポエムです。 界隈的には今さら感がすごいけど。 そんな今さらポエった事情としては、 とある案件でSPAをReactで作りつつサーバーサイドレンダリング（以下SSR）をすることになるかも SPAじゃないページもまとめてReactでSSRすることになるかも ただ個人的にはSPA+SSR不要論者 サーバーサイドのテンプレートとしてのReactも冗長なだけやろ派 でも仕事なのでしゃーない（お客様がそう申されるなら・・ なのでやるからには再考察してみて、前向きにやれる要素を見つけたい！ けどどんだけ考えてもやっぱり意義が見つけられなーい( ´Д｀)=3 という感じで、SSR自体の是非はまあどうでもよくて、ただ個人的に「しなくていい」と思ってる気持ちをまとめたものです。 技術に是も非もないです。大事なのはどう使うかなのです。 ちなみにやってみた結果・・とかいう話ではなく、やってない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2で 速くなるとき ならないとき
2018年のフロントエンドエンジニアを取り巻く課題とチャレンジ
加速するフロントエンドとPWA
