保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
こんにちは、Software Engineerの @yui_tang です。 3月7-8日にニューヨークにて開催されたAMP Conf 2017に参加してきましたので、そのレポートを書きたいと思います。 メルカリでのAMPの取り組み まずは、現在までのメルカリにおけるAMP(Accelerated Mobile Pages)の取り組みについて簡単にお話します。 2016年7月にメルカリのWebサイトの一部に導入を開始し、現在AMPページには数万PV/日のアクセスがあります。 メルカリ内の商品毎のページが全てAMP対応しているため、そのページ数は相当数に上ります。 流入経路ですが、現在元ページにlink rel="amphtml"を設定しているのみで、メルカリのサービス内にAMPページへのリンクは露出していません。 よって全てが検索流入となっており、事実上ランディング用のページとして機能して
帳票といえばPDFとして生成するのが一般的でしょうか? でも、2015年の今、あえてHTMLで描くのがホットです(個人的に)。ミリ単位で設定された高度な帳票も、CSSを駆使して簡単に作ることができます。業務システムでもモダンブラウザを選択することが増え、@pageなども積極的に使えるようになったこと、SPA(Single Page Application)の台頭、いろいろと条件が揃ってきました。 書いてたら結構長くなっちゃったので、さくっとコードだけ見たい方は、Paper CSSリポジトリをどうぞ。 はじめに HTML帳票のメリット 2015年現在、HTML帳票を選択する幾つかのメリットがあります。 ライブリロードで、リアルタイムなスタイル調整 バックエンドではなくフロントエンドで生成できる 前者は、gulpやGruntの普及で、CSSにしろHTMLにしろ、リアルタイムにプレビューできる環
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
Last updated: May 2021 Table Of Contents Introduction How was it done before? How to use 3.1 Interlude: PerformanceTimeline 3.2 ResourceTiming 3.3 Initiator Types 3.4 What Resources are Included 3.5 Crawling IFRAMEs 3.6 Cached Resources 3.7 304 Not Modified 3.8 The ResourceTiming Buffer 3.9 Timing-Allow-Origin 3.10 Blocking Time 3.11 Content Sizes 3.12 Service Workers 3.13 Compressing ResourceTimi
HTML5 Experts.jpはなぜこんなにパフォーマンスが悪いのか…全てお見せします！ーWebパフォーマンス改善企画（改善編） 吉川 徹 Webパフォーマンス改善企画（改善編）は、実際の改善内容とその結果をお伝えします！パフォーマンス分析を行った解析編は、こちらからご覧ください。本記事はHTML5 Experts.jpがいかにして速くなったのかを包み隠さずお伝えします！ 今回の前提条件と改善ポイント 実際の改善を行う前にいくつか前提条件を説明しなければいけません。まず動作環境ですが、HTML5 Experts.jpは、WordPress上で動作しており、改善内容はプラグインの導入やPHPのコード修正が主になっています。ただ、そういったWordPressの泥臭いチューニングは本題ではないので、細かく解説するのではなく大まかな改善内容とその方針を説明したいと思います。また、改善内容に関して
ちなみに後日談…計測対象の個別記事ですが、計測のためのアクセスがかなりの頻度あるため、PVランキングでは常に1位を独占していました（笑）。また、Google Analyticsについても、計測開始前に除外設定しておかないと、正確なデータが得られなくなりますので、ご注意下さい。 計測して問題点を洗い出す ファーストバイトダウンロードタイムの遅延問題 ということで、竹洞さんに一定期間サイトのパフォーマンスデータを計測してもらいました。その結果を見ながら、早速現在のHTML5 Experts.jpの問題点を洗い出します。 竹洞：これがある日の、ブロードバンド回線でChromeを用いてアクセスした時の計測結果です。 見ての通り、ID1のhtmlの取得にすごく時間がかかっていることがわかります。この水色は、ファーストバイトダウンロードタイム（Time To First Byte、以下、TTFB）とい
Webサイトの制作に役立つ便利なブックマークレットを紹介します。 ブラウザの機能拡張も便利ですが、入れすぎると重くなったり、Chromeで使えるけど他で使えないなどあるので、ブックマークレットもなかなか重宝します。 ページにグリッドを表示した確認 レスポンシブWebデザインの確認 デザインの確認をピクセル単位でできる ページで使用しているフォントをチェック ページをワイヤーフレーム化 ページの構造が正しいか確認 マークアップのいまいちな箇所を指摘してくれる 背景を素敵なテクスチャに変えてみたい ページのパフォーマンスを確認 minifyされたCSSを見やすく表示 SEOやソーシャルメディアに大切な項目を確認 コードとアクセシビリティをチェック ページにグリッドを表示した確認
[対象: 全員] スマートフォン端末での表示に最適化されたページがモバイル検索結果に表示されるときに、「スマホ対応」というラベルをGoogleはスニペットに追加するようにしました。 また将来的には、”モバイルフレンドリー”の条件をランキング要因として利用する可能性があります。 「スマホ対応」のラベル スマートフォンで適切に表示できるように最適化してある状態をGoogleは「モバイル フレンドリー (mobile-friendly)」 と呼んでいます。 モバイルフレンドリーなページには、英語の場合は「Mobile-friendly」、日本語の場合は「スマホ対応」というラベルがスニペットの先頭に付きます。 この新しい仕様は、今後数週間かけて世界中で展開してきます。 もちろん日本も含まれます。 僕の環境では、米Googleでは確認できますが日本のGoogleではまだ適用されていません（そんなわけ
「HTML5 Advent Calendar 2013」の24日目の記事です。 Webアプリのパフォーマンス改善と言えば、JavaScriptやDOMアクセスなど、既存の技術ベースな改善手法を想像する方も多いでしょう。最近では、こうした改善のあり方を、別の視点からもう少し広げようというアイデアが存在感を持ち始めています。それは「Web標準」です。 そこで今回、Web標準側でできるWebアプリのパフォーマンス改善について、掻い摘んで紹介します。全てを説明となるとキリがないので、キーワードを中心とさせて頂きます。最近になって、結構実用化が進んできているので、悩んだ時には試してみる価値はあるでしょう。 1. リソースを先に読み込む linkタグにてURLなどを指定することで、これから先に読み込ませる可能性が高いWebページのリソースを予め読み込むWeb標準があります。ニュースサイトでは次のページ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Measuring the Performance of Firefox Quantum with RUM - Akamai Developer Blog
