Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの？という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
初心者向けWEBアーキテクチャ入門 - masalibの日記
上記の図は、WEBアーキテクチャです。 新人などの場合はあまり経験がない人は、用語すら聞いたことない状態だと思います 全部理解する必要はないですが、googleの検索する時に参考になれば幸いです 会社の勉強会用（無給）に作った資料・・・めっちゃ時間かかった。 資料も公開しています 初心者向けWEBアーキテクチャ入門ver2018-07-23 - Google スライド （ダウンロードして修正もできます） DNS: 説明する前に前提 IPアドレスとは: ネットワークにつながっている機器はかならずIPアドレスが割り振られています IPアドレスとIPアドレスで通信することでデータをやり取りしています グローバルIPとローカルIPについて グローバルIPは世界中で重複がにあように管理されており、世界中の通信で利用されています ローカルIPは会社や家などで自由につかえるIPです ローカルIPのなかで
ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側）
どうも、鈴木です。 さて、前回は vim の使用法というじつに低レベルレイヤの出身者的な記事を書きましたが、 今回も懲りずに低レベルのお話しをしたいと思います。 というのも、先日「ブログ書くのめんどくさいよぅ」と駄々をこねていたところ、あまりにレガシーすぎる HTML/CSS/JavaScript 仕様や Flash や Silverlight といったプロプライエタリなリッチコンテンツ用プラグインに日々苦しめられている気弱く善良な一介の WEB プログラマにすぎない我々の希望の星であり、そして同時に新たな巨大クソレガシーの萌芽でもある HTML5 が、いかにイケてないのではなくイケているのであるかを盛んに啓蒙するサイトである HTML5 Rocks (http://www.html5rocks.com/) に、"How Browsers Work" というとても楽しい記事があるのを、我が
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita
先日、マイクロサービスの呼び出し方として、オーケストレーションとコレオグラフィについて書きましたが、同じく4章では、どうHTMLを組み立てるかという問題が提起されています。 ここもやや難解なので、咀嚼を試みます。 課題設定 次のようなECサイトを考えることにします。そして、4つのマイクロサービスを合成して構成します。 商品カタログサービス ショッピングカートサービス ショップサービス リコメンドサービス API合成 無垢な気持ちで設計すると、各々のマイクロサービスがWeb APIのインタフェースをもち、XMLやJSONを返して、ECサイト側で、テンプレートエンジンなどを用いて、HTMLをレンダリングするという方式になるかと思います。 そして、この形式でマイクロサービスを利用するサイト(アプリケーション)が増えていくと次の図のようになります。 これには、次の3つの欠点があるとされています。
第3回 Webセキュリティのおさらい その3 CSRF・オープンリダイレクト・クリックジャッキング | gihyo.jp
前回は、Webアプリケーションにおける受動的攻撃の代表例の1つであるXSSについて、原理や対策を振り返りました。今回は、同じく受動的攻撃の代表例であるCSRF、オープンリダイレクト、クリックジャッキングについて掘り下げて解説していきます。 CSRF（クロスサイトリクエストフォージェリ） CSRFはどのように引き起こされるのか CSRFとは、たとえば掲示板の書き込みや設定情報の変更などの機能に対して、攻撃者のサイト上に設置されたフォームなどから強制的にリクエストを発行することで、ユーザーの意図していない操作と同様の結果をもたらす攻撃手法です。Webアプリケーションに永続的な副作用がある機能が攻撃の対象となります。 たとえば、http://example.jp/上に設置された掲示板で以下のようなHTMLがあったとします。 <form method="POST" action="/board">
学生時代に知っておきたかったWeb技術の学び方の学び方 | リブセンス
「プログラミングを学ぼうと瞬間最大風速的に意識は高くなるものの、一人でいると気がついたら一日ソシャゲして夕方頃に『また今日も勉強できなかった』と自己嫌悪。」モチベーションが続かない時の対策をはじめ、学び方、学べる環境の作り方をまとめています。
SPAである価値 - nobkzのブログ
以前、少し前だが、以下のブログを読んで、SPAであるべき価値について考えたことを述べる。 anond.hatelabo.jp mizchi.hatenablog.com そもそもSPAとは? この議論をする前に、そもそもSPAとは何だろうか?という点について整理しておこう。僕は2つの点で特徴があると思っていて、 フロントエンドGUIであること Webアプリケーションであること この2点かなと思う、簡単にまとめると、 フロントエンドGUIであること まずは、「フロントエンドGUI」というのはどういうことかと言えば、サーバーサイドレンダリングとは対照に、jsによるDOM操作によって、UIを切り替えて行って構成するGUIを指す。 Webアプリケーションであること GUIではあるのだが、それは、Webアプリケーションでもある。サーバーからAjaxやwebsocketなどによって、サーバとデータのや
Web 関連仕様 日本語訳
このページは、 Web プラットフォーム関連の様々な仕様の日本語訳の一覧と， それらの日本語訳に共通な事項についての説明です。 これらの翻訳の正確性は保証されません。 これらの仕様の公式な文書は英語版であり、 日本語訳は公式なものではありません。 誤訳が無いことは保証されません。 ［ 当の仕様の策定者たちが想定している／当の仕様に期待されている ］意味論を完全かつ正確に反映することは保証されません。 翻訳なので、 語彙レベルで原文と正確に一致する意味を表すことは決してありません。 日本語は自然言語なので、 誰がいつどこで読んでも同じ解釈になることは保証されません。 ）（ 実際に誤訳が見つかることも時折あります。 それらについては見つかり次第修正され， 加えて用語の対訳や言い回しなども時折修正されるので、 これらの翻訳が「完成」する日は永遠に来ません。 逆に原文仕様が誤っていることもあり、
CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
『Web API: The Good Parts』 を読んだ - ひだまりソケットは壊れない
Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (6件) を見る 同僚から借りて読みました。 全体としては Web API の設計に少しでも携わる人間ならとりあえず読んでおいたらいいんじゃないかなーという感じです。 薄いし。 本書を読んだからと言って最高の Web API の設計ができるようになるとは思わないですが、Web API の設計をする際に知っておくべきことが一通りまとまっていて良い感じだと思いました。 学びメモ 知らなかったことや、なんとなく知ってたけど改めて調べたことなどまとめておきます。 RFC 5861 での Cache-Control ヘッダの拡張 RFC 5861 にて、Cache-Control ヘッダの 2 つの拡張が定義されています。 sta
Cloud Delivery, Performance, and Security | Akamai
コンピューティング あらゆるワークロードに対応した VM により、構築、リリース、スケーリングを迅速に実行
サーバサイドで複数Web APIを呼び出すときのデザインパターン - Qiita
最近はエンタープライズのシステムでも、Web APIによるシステム間連携が増えてきました。そうしたときに、1リクエストで複数の連携先APIを実行し、結果をクライアントに返すということがままあります。 どう作りましょうか、という問題です。 前提として、サーバサイドでHTMLレンダリングせずに、Web APIの中継することとします。中継する意義は、流量やキャッシュをサーバサイドでコントロールできるところにあります。 クライアントから直接連携先のAPIにアクセスする設計にすると、リロードボタン連打などのDDoS攻撃うけたときに、自分たちでは対処できず、連携先に迷惑をかけてしまいますよね。特に「課金の関係などで直接APIをアクセスしなきゃいけないんだ」、とかでなければ、中継するように設計しておいた方がベターです。 Web APIの呼び出し 業務システムで使う場合は、ちゃんとリクエスト、レスポンスが
初心者Webアプリケーション開発者がチェックすべき情報源2015 - ハニーポッターの部屋
毎年恒例の「初心者Webアプリケーション開発者がチェックすべき情報源」を集めているので、皆さんにもご紹介。 去年に引き続き、最低限のものに絞ってみた。 上から重要な順。★の付いている「重点」がとりあえず読んどけ、の必須。 必須のポイントは、短期間で大雑把に網羅的にポイントが整理されているものを選択。 書籍としては、徳丸本「体系的に学ぶ 安全なWebアプリケーションの作り方」、「めんどうくさいWebセキュリティ」と「実践 Fiddler」を掲載したけど，他に良い本があれば情報プリーズ。 この情報もあったほうが良いんじゃね？という情報も大歓迎。 ■重点 ★Webサイト構築 安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html 安定の第7版２刷。Web開発の委託先仕様書の代わりにも使える。 セキュリティ実装 チェックリ
アプリ開発者なら書籍「Web API: The Good Parts」は読んでおくべき - sakaharaのブログ
最近のアプリ開発においてクライアントサイドだけで完結するようなものはかなり少なくなってきたと思います。 おそらく何らかのAPIを直接もしくはSDK経由で呼び出すことがほとんどではないでしょうか。 そういった背景がある以上、すぐれたWeb APIがどうあるべきかというのはサーバサイドを担当するエンジニアだけでなく、 クライアントサイドを担当するエンジニアであっても知っておくべきでしょう。 今回読んだ「Web API: The Good Parts」はWeb APIを美しく設計する重要性、そして美しく設計するための指針を すでに公開されている様々なWebサービスのAPIを例に挙げながら、よりよい方法を提案してくれています。 Web API: The Good Parts 作者:水野 貴明オライリージャパンAmazon 個人的に印象に残っている内容をいくつか挙げておきます。 エンドポイントの設計
Webパフォーマンス管理の基本 1 - Qiita
はじめに Webパフォーマンスはパフォーマンスエンジニアリングの1つの分野 Webパフォーマンス管理は、Webサイトの非機能要求の性能や可用性を扱います。 専門用語では、コンピュータの登場と時期を同じくして登場したパフォーマンスエンジニアリングという分野に属します。 パフォーマンスエンジニアリング パフォーマンスエンジニアリングとは、Wikipediaでは以下のように記載されています。 Performance engineering encompasses the techniques applied during a systems development life cycle to ensure the non-functional requirements for performance (such as throughput, latency, or memory usage) w
GET /@:id みたいなURLで他との衝突を避ける - Qiita
Webアプリのルーティングにおいて、各ユーザの個別ページを特殊なものにしたい場合にどういうURLにすると便利かという話に触れる。例えばr7kamuraというIDのユーザ用のページは、Twitterだと https://twitter.com/r7kamura で、GitHubだと https://github.com/r7kamura というURLになっている。 GET /:id だと他のパターンと衝突してしまう もしユーザページに GET /:id というパターンを採用すると、他のURLのパターンと競合してしまうという問題がある。どんなときに困るかと言うと、例えば https://twitter.com/about でTwitterというサービスについて説明するWebページを提供しようとすると、aboutというIDを持ったユーザ用のページが提供できなくなってしまう。 この問題に対してよく
Webアプリケーションの パフォーマンス向上のコツ 実践編
社内 LT 大会で発表したスライドです。 スライドの日付が 2012/05/22 になっていますが、正しくは 2012/05/21 です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/NagaokaKenichi/items/6270e80f93c704ca9b69
Webサイト制作におけるフロントエンドの必須スキル＆開発環境はこれで決まり！ - North-Geek
Effective web performance tuning for smartphone
