Webサイトパフォーマンスの振り返り 2016 - Webパフォーマンスについて
やっと表示速度の認知に火がつき始めた 2016年も、残り一ヶ月となりまして、WebサイトパフォーマンスのAdventカレンダーがスタートしましたので、今年のWebサイトパフォーマンスの動向を振り返ってみます。 今年の1月から3月、日本のECサイト売上上位150社に営業をかけて、色々とお話したのですが、ECサイト関係は、まだまだ表示速度の重要性を認知していない事が分かりました。 4社が興味を示してくれましたが、「配信品質管理」という認識まではやっぱり無かったです。 「日本はこのまま品質管理としてのWebサイトパフォーマンスが普及せずに今年も一年が過ぎてしまうのか？」と危機感を抱き、今年は、以下のカンファレンス等で講演の機会を頂きました。 関西フロントエンドUG主催 frontend conference 2016 「Webサイトパフォーマンスの基礎知識」 Movable Type Devel
サイト高速化の「戦略」と「戦術」- GradeAのその先へ | ゆっくりと…
サイト高速化をネタにした記事は星の数ほどありますし、YSlow や PageSpeed、あるいは両方同時にチェックできる GTmetrix のおかげで、アドバイスに従って問題点を一つ一つ潰し込んでいけば、着実にスコアを「Grade A」に近づけられるようになりました。 またベスト・プラクティスなんて知らなくても、「CloudFlare 導入、一発 OK！」なんていうお手軽なサービスもあります。 一方、これら個々の Tips、テクニックを断片的に積み上げていくアプローチやブラックボックス方式では、サイト全体を通して「本当に最適なの？」という疑問も生じます。 別な言い方をすれば、「Grade A は取ったけど… その先は？」に対する処方箋が必要なんじゃないかと思っています。 そこで今回は、「スコア」だけでは見えてこない、サイト高速化の「戦略」と「戦術」の話にチャレンジしてみたいと思います。これ
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Speed and Performance Optimization
大規模分散システム ”Amazon Web Services” の使い方
