marmooo's blog: 4月 2019

2019年4月19日金曜日

JavaScriptのグラフ/チャート描画ライブラリの機能比較とまとめ

JavaScriptのグラフ表示ライブラリに困ったので、まとめてみました。

あくまで私にとって良さそうなものを選びたかっただけなので、いくつかのライブラリは比較から除外しています。まずHighCharts, CanvasJS, Chartwork.jsとった高機能だけど有料なライブラリは比較していない。あまり有名でないものとしてはFusionCharts, Plottable, n3-charts, dygraphs, WebCola, amCharts, ember-charts, ZingChart, EJSCharts, uvCharts, tauCharts, Stardust, QuickChartなどもあるけど、GitHubの4000スターで足切り。有名なものではReact限定のRecharts、jQuery限定のFlot、仕様が複雑なVegaを除外した。他にもいくつか気になったものがあるけど、絶賛開発中でよくわからないところは除外した。

私がグラフ描画ライブラリで重要と思っている機能面での比較項目は以下。 ◯◯チャートに対応しているかどうかなどは、ファイルサイズとの兼ね合いもあるので考えない。

1. 凡例クリックで表示切替: 理解の手助けに便利

最近のライブラリでは凡例クリックで表示切替は標準装備されつつある。この機能があるとグラフがグッと見やすくなる。 Google Chartsは標準搭載されてないけど、自作で実現は可能です。ただこのような追加実装は複雑なので、好ましい状態ではありません。

2. View Finder: グラフ内のx軸が増えるほど必要

時系列データのようにグラフ内のデータが増えると、特定のレンジだけを表示したいという需要が高まります。グラフ外のボタンから調整すれば一応は何とかなるけど、スマホなどでは非常に手間なので、表示領域をマウス操作だけで調整できると嬉しいです。

3. Annotation: グラフ内のカラム数が増えるほど必要

カラム数が増えてくるとグラフのデータそのものをきちんと見る事は難しくなります。重要な部分に何らかのAnnotationを、「簡単に」付けられると嬉しいです (下図)。ちなみにこのグラフ、意外と作れないライブラリが多い。

4. スマホでの綺麗な表示

Google Chartsはカラム数が増えてくると、まずスマホでの凡例の表示が酷い事になります (下図)。 Google Chartsでは可能な限り配置を変更しないようにする結果、収まりきらなくなった凡例によってグラフが崩れてしまうのです。たぶんスマホでは凡例を消して表示するのが一番綺麗かなあ。凡例の実装の仕方はライブラリによって大きく異なるので、表示の綺麗さを独断と偏見で評価付けてみました。イメージを掴みたい人のためにテストページも作ったので参考にしてください。

その他の比較項目は自分の感じた印象値によるオレオレ採点です。まず実装の簡単さに関してはドキュメント、サンプル、仕様のわかりやすさを重視して評価しました。 ◯評価なら仕様を眺めて2-3分でグラフを表示できるくらいわかりやすいし、複雑な事をしようとしてもすぐにわかるライブラリと思う。 更新頻度も一応載せました。

前置きが長くなったけど、以下に比較表を載せます。

名称	凡例で表示切替	View Finder	Anno tation	スマホ表示	実装の簡単さ	更新頻度
EChart.js	◎	◎	△	◯ (色々と問題)	◎	◎
C3.js	◎	×	△	◎	◎	◎
Chartist	◎	×	◯	◎	◎	△
Chart.js	◯	×	◯	◯ (縮小時が汚い)	◯	◎
Google Charts	△ (要自作)	×	◎	×	△	◎？
D3.js	◯	×	△ (要自作)	◎	×	◯
dc.js	◯	◯	△ (要自作)	◎？	△	◎
NVD3.js	◯	◯	×？	◎？	△	△
Plotly.js	◎	◯？	◎	△ (量次第)	◯	◯
Vis.js	◯ (要自作)	×	◯	△ (見にくい)	◯	×
ToastUI Charts	◎	×	×	◯？	◯	◎
Rickshaw	◎	◎	◯	◯ (CSS面倒)	◯ (CSS面倒)	×

機能が増えれば当然ながらファイルイズも増えるので、調べてみました。依存ライブラリも含めたサイズになっているので注意してください。ついでにGitHubのスター数も執筆時点の状態で比較しました。またあまり当てにはならないですが、簡易的なベンチマークも載せました。左がキャッシュなしで、右がキャッシュありの描画速度です。 D3.js系の実装が面倒なものは確認しなかった。データ数1000のレンダリング速度について書いていますが、他のデータ数についてはテストページを参考にしてください。

名称	JavaScript Size	CSS Size	GitHub Star	Speed (ms)
EChart.js	747390	0	33523	1039/339
C3.js	443752	57344	8299	811/209
Chartist	40214+	11508+	11521	198/77
Chart.js	156721+	521+	42931	265/90
Google Charts	1171133	14245	-	1393/501
D3.js	242740	0	83961	N/A
dc.js	360607	4126	6542	N/A
NVD3.js	496092	8419	6844	N/A
Plotly.js	3050363	0	10005	4119/368
Vis.js	69022	23777	7823	1455/148
ToastUI Charts	489065	25911	4097	not work
Rickshaw	232616	6009	6347	871/45

総評

何も設定せず高機能なグラフを作りたいならPlotly.jsが良さそう。ただし素の状態ではあまりにも重いので、カスタムビルドしたほうが良いと思う。 plotly-basic.min.jsを使うだけでもキャッシュに載っていない時の表示が400msくらいに短縮できる。
EChart.jsは少し設定必要だけど、高機能なのに凄く使いやすい。公式のカスタムビルドを適当に使うと、288182 Bytesとまあまあのサイズになった。カスタム化するとキャッシュに載っていなくても300msくらいで表示できるので、なかなか凄い。
軽量なレンダリングを目指すならChartist, Chart.jsが良さそうに思います。キャッシュに載りさえすればRickshawも早い。機能とバランスが良いのはChart.jsかな。

データ数を増やしても一番安定していたのはPlotly.jsでした (テストページ参照)。やたら安定しているのはstack.glの効果なのだろうか。
C3.jsは見栄えが綺麗で仕様もシンプルで、サクッと動かすぶんにはとても使いやすいライブラリに見えます。カラムのデータをまとめて表示してくれるのも便利。
D3.js系は色々なものがあるのですが、D3.jsの仕様変更と進化が早いせいで、更新に追随できていないライブラリが多いのが気になります。あとカスタムビルドしにくいのは難点かも知れません。

私自身もグラフ描画と言えばGoogle Charts, Chart.js, D3.jsの3強という刷り込みがあったのですが、他にも凄いライブラリがたくさんありました。ファイルサイズも「こんなに違うのか…」とも驚きました。レスポンシブ表示への最近のライブラリの取り組み姿勢も凄いなと感じました。きちんと比較してみないとわからないものですね。

参考:

様々なJavaScriptのグラフ/チャート描画ライブラリの表示テストページを作った

JavaScriptのグラフ/チャート描画ライブラリの機能比較とまとめというページを作ったので、そこで比較したライブラリの実装をサクッと確認できるページを作りました。コードは右クリックから「ページのソースを表示」で見やすいようにしてある。

表示テストのサンプルはどれも多数のカラムを持つLineChartです。 C3.jsの表示例は以下。

他のライブラリも実装が面倒ではない範囲でなるべく同じ表示になるようにしています。またカラムを多めにする事で、凡例の表示テストも兼ねている。簡易的なものだけど描画速度も計測できるようにもしてある。

実装を確認できるライブラリのリストは以下。

このリストを使ってデータ数1e2〜1e7のベンチマークをしてみました (下図)。 JavaScript/CSSはあらかじめキャッシュされている状態を想定してます。数回しか実行してない簡易的なベンチマークなので参考程度に留めてください。

上記の比較では、データ数を増やしたらすべて表示するようにしています。表示数を調整しやすいライブラリの場合、部分的にしか表示しない事でかなりレンダリング速度を向上できます。同様の理由により、まず部分的なデータでレンダリングして、後からバックグラウンドで更新しやすい仕組みがあると良いと思います。

何となく作ったページですが、ライブラリごとに微妙に異なるデータの扱い方や、初期状態でどれくらい高機能なのかをすぐに比較できて、割と便利かも。

2019年4月13日土曜日

フリゲ紹介: クリエイティブストーリー

クリエイティブストーリーはコンテストパークWebで金賞だったアクションRPG。コンテストパークの受賞作品は今でもたまに遊んでいます。 10年以上前の作品ですが、今やっても普通に面白いですね。アクション系の作品は何年経っても楽しめるのが良いところだと思う。

ストーリーとしては、ゲーム開発に目覚めた主人公のサブローが脳内で開発していくゲームを、プレイヤーが楽しむという内容になっています。なぜ脳内かというと隕石でPCが壊れたからです (笑)。脳内設定なので色々ぶっ飛んでいるところがありますが、それもまた面白い (左下)。マッピング形式のダンジョン (右下) を探索していくゲームになります。

実際のアクションパートは様々な武器を選択ができるようになっていて、その特性を活かしながら戦う仕組みになっています (左下)。ザクザクと敵を倒せるので爽快感がある。魔法もありますし、ダンジョン内での謎解きなどもある。ボス戦も当然あるのですが、大量の敵を相手にする事が多いです (右下)。

面白いゲームは時代を超えても面白いものだなあと思いました。

フリゲ紹介: VampunishX

VampunishX (ヴァンパニッシュX)は、悪魔城ドラキュラに影響されて制作されたアクションゲーム。 Twitter経由で知った作品ですが、歯ごたえのある作品で、とても面白い。

ステージ選択画面 (左下) を見てもまさに悪魔城ドラキュラという作品ですが、可愛いドットの作品になっている。ステージ選択画面に出ている女の子リサが今回の主人公です。
悪魔城ドラキュラと少し違うのが、ステージが画面切り替えごとに区切られていて、その切り替えごとにオプション装備を選択する点です (右下)。これはボス前にオプション武器が変えにくいオリジナルの問題を解消したものなのかな。

アクションは非常にサクサク動いて、音楽もカッコイイし、プレイしていて気持ちが良いです (左下)。基本の武器はやはり鞭で、オプション武器も色々なものがある。当然ボス戦もあります (右下)。右下のボスは1面の最初のボスですね。

私はまだクリアはしていませんが、かなり歯ごたえのある作品です。私の腕だと3面のボスが意外とギリギリでした (ちなみに私は初代悪魔城ドラキュラをクリアした事はある)。その後はスムーズに進めているので、ステージ自体はきちんとクリアでき、ボス戦だけは難易度が高いという事だと思う。ボス戦も何回かやり直せばギリギリ感を味わえるくらいの難易度なので、アクションが得意な方にはおすすめできる作品だと思う。

2019年4月8日月曜日

lxml Cheetsheet

最近はlxmlをよく使ってXMLのパースをしていたのでチートシートを作りました。既に色々なチートシートがあるので、自分の使いやすさだけ重視してます。

from lxml import etree

# I/O
tree = etree.fromstring('<xml>...</xml>')
parser = etree.XMLParser(remove_blank_text=True)  # many options
tree = etree.XML('<xml>...</xml>', parser)
tree = etree.parse('test.xml')
root = tree.getroot()
print(etree.tostring(root), pretty_print=True)  # many options

# search
node = tree.xpath('a')     # [<Element>]
node = tree.find('a')      #  <Element>  faster than xpath
node = tree.findall('a')   # [<Element>]
node = tree.iterfind('a')  # [<Element>]

# search node/attr/text
node = tree.xpath('description')
attr = node.attrib['about']
text = node.text

# search node/attr with namespaces
rdfNamespace = { 'rdf': 'http://www.w3.org/1999/02/22-rdf-syntax-ns#' }
xlinkNamespace = { 'xlink': 'http://www.w3.org/1999/xlink' }
node = tree.xpath('rdf:description', namespaces=rdfNamespace)
href = node.xpath('@xlink:href', namespaces=xlinkNamespace)[0]

# iteration, sibling, etc.
for node in root.iter('node'):
  print(node)
node = node.getprevious().getnext().getparent()

# edit
title = etree.Element("title", href="https://lxml.de/tutorial.html")
root.append(title)
etree.SubElement(root, 'child')  #=> <root><child/></root>
etree.SubElement(xhtml, "{http://www.w3.org/1999/xhtml}body")
node.getparent().remove(node)

複雑な事をしようとしなければ、かなりあっさりした仕様なのは良いところ。編集操作はもっと色々な機能があるみたいですが、あまり使ってないのであっさりにしときました。その他の機能は公式のチュートリアルを参照。

2019年4月6日土曜日

コンビニはどれくらい利益が出るか

コンビニの取組事例調査が出ていたので軽く計算してみました。ちなみに参考になったのは平均売上が2億くらいというところだけ。決算発表資料などを読んでも規模がデカ過ぎて意外とよくわからない部分ですから、ちょっと嬉しい。

平均売上が2億で、原価率が一般的に30%なので、そこから50-70% (仮に60%) のロイヤリティと、 2-4% (仮に3%) の廃棄率を考慮すると、一時的な利益は以下になります。

2億円 x 0.4 x (1 - 0.6) - 2億円 x 0.03 = 1,800万円

ここから人件費、電気代、賃料などを引いていく事になりますが、土地代が一番キツイから地主のほうが得でしょう。賃料は1Fの50㎡を20万円とすると60万円/月はしそう。地方なら半分で済むかも知れないし、駐車場付けるともっとしそう。電気代は24時間付けっぱなしで色々使うから10万円はしそう。
他のサイトだと処分費用などを含めて20万円くらいの想定が多かったですね。 24時間稼働するので最低1人/8時間のバイトも必要です。普通に考えれば2人は必要でしょう。これらを適当に考慮し、最終的に得られる利益が以下になります。

(60+10)万円 x 12 = 840万円
1,000円/1h * 8 * 2 * 365 = 584万円
1,800万円 - 780万円 - 584万円 = 376万円

だいたいこんな感じなのかな。このざっくり計算の中で重要なのは、土地代、原価率、ロイヤリティ、人件費の4つとわかると思います。このあたりをうまくやってるところはもっと稼いでると思う。ただ案の定と言うか、人件費の配分を間違えると死にますね。

2019年4月5日金曜日

Webサービスの運用コストざっくりまとめ

Webサービスの運用コストを安い順にまとめてみました。

	月額料金	ディスク上限	転送量上限	備考
Google Sites	0円	100MB	∞	静的ページのみ
GitHub Pages	0円	1GB以下推奨	∞	静的ページのみ
Netlify (無料枠)	0円	GitHub等に依存	100GB/月	1ユーザのみ CGIは遅め
Firebase (無料枠)	0円	1GB	10GB/月	CGIは遅め
ZEIT (無料枠)	0円	GitHub等に依存	100GB/月	CGIは遅め
GAE (無料枠)	0円	5GB	1GB/月	無料枠は遅め
GCE (無料枠)	0円	5GB	1GB/月	無料枠は遅め
Heroku (無料枠)	0円	-	-	1プロジェクトのみ
無料HP	0円	100MB〜∞	1-10GB/月	広告/SSL/CGI/SSH の制限が多い
無料レンタルサーバ	0円	100MB〜∞	1-10GB/月	広告/SSL/SSH の制限が多い
レンタルサーバ	99円〜	プラン依存	プラン依存	安いと速度問題があるディスク容量大
クラウドストレージ	0円〜	∞	∞	転送/保存/リクエスト料が掛かる
CDN	0円〜	∞	∞	転送料が掛かる
ZEIT	0円〜	GitHub等に依存	∞	CGIは遅め転送量/保存料
VPS	500円〜	プラン依存	プラン依存	300円〜も一応あるだけどSLAには注意ディスク容量小
専用サーバ	2000円〜	プラン依存	プラン依存
クラウドサービス GAE, GCE, AWS, Netlify, Firebase, etc.	3000円〜	プラン依存	プラン依存	転送量/保存料が掛かる

ここに書いていない無料枠のあるサービス一覧としては、良いまとめがあったのでそちらを参照。 AWS LambdaはNetlify/ZEITに、Cloud FunctionsはFirebaseに含まれるとも考えられるけど、DBやメッセージに限定すれば他にも色々あるみたい。

クラウドストレージの料金は転送量や保存料に依存するので表では比較しにくいです。クラウドストレージのまとめがあったので、執筆時点での料金で、よくありそうなサービス想定のコストを計算してみました。月額ドル建て料金 (保存料 + 転送料 + リクエスト料) です。

想定: データ容量20GB、10万GETリクエスト、転送量100GB、主な転送先が日本

Amazon: 20*0.025 + 100*0.09 + 100*0.00037 = 9.537$
Google (tokyo): 20*0.023 + 100*0.14 + 0 = 14.46$
Microsoft (tokyo): 20*0.02 + 100*0.09 + 10*0.0004 = 9.404$
Oracle (US only?): 20*0.0204 + 100*0.102 + 100*0.0043 = 11.038$
Rackspace (US only): 20*0.10 + 100*0.12 + 0 = 14$

どれも転送料が高いので、レンタルサーバと料金的にはおそらく大差ないです。違ってくるのはレスポンスタイムや信頼性。

レスポンスタイムと信頼性を高める仕組みとしてはCDNがよく使われます。 CDNの料金は0.10$/月〜でAmazon S3 (クラウドストレージ) とそんなに変わらないのですが、利用するとレスポンスタイムが劇的に変わります。様々なサービスがありますが、50msくらいでレスポンスが得られる。これくらいのレスポンスで返せるレンタルサーバはたぶんない。

クラウドサービスは割高ですが、スケーリングできる利点があるので結局のところ利用用途に応じた選択が大事です。またレンタルサーバは安いんですが、CGIで開発するのはかなり辛いので、VPSの値段が基本になると思っています。 VPSはまともなサービスの運用には500円/月は掛かると思っています。格安VPSとして有名だったTIME4VPSが値上げをし、AlphaRacksもなくなった (2019-06-13) ので、最近はどんなに安くても300円/月はします。

クラウド系はちょっと仕組みが複雑になり過ぎてきたので、最近はFirebase/Netlifyが私のおすすめです。高速なレスポンスが必要な時はバランスの良いVultrというVPSをよく使っています。 Vultr、実はCDNよりレスポンスが早かったりする。

2019年4月2日火曜日

小さなサイトならBootstrapではなくBulmaも良いかも

今回作った小さなサイトでは、CSSフレームワークはBootstrapではなくBulmaを使いました。 BulmaはCSSのみで構成されているのが売りのCSSフレームワークです。利用シーンを選べば便利なライブラリと思うので、使用感をまとめます。

実は私、少し前にCSSフレームワークはやっぱりBootstrapが良いかもと書いたし、そこに書いた事は「たくさんの機能を持つサイトでは」ブレていません。ただ今回作ったサイトのように小さなサイトではBulmaも良さそうでした。そこで今回は、サイトの大きさによってどのようにフレームワーク選びに違いが出るかを少しまとめてみたいと思います。

1. 小さなサイトではjQueryがボトルネックになる

高機能なサイトでも十分ボトルネックになりますが、BootstrapだとjQueryとJavaScriptのロードに少し時間が掛かります。機能が少ない小さなサイトではあまり馬鹿にならない問題で、素のBootstrapはやや大き過ぎるのです。 CSSだけならUnCSSなどを使えばいくらでも切り詰められますが、JavaScriptはそう簡単には切り詰められません。

ただボトルネックになったとしてもjQueryの資産というのは非常に大きく、高機能なUIを実現しようとするとまだまだ必要な事が多いです。しかし将来どのようなライブラリが必要かを見切って、jQueryの出番がなさそうなら、Bulmaは十分に選択肢になり得ます。

2. BootstrapはJavaScriptなしではいくつか表示の問題がある

jQueryが遅いならJavaScriptをロードしなければ良いと思うかも知れません。この時に一番のネックになるのが、アニメーション。 CSSオンリーのBootstrapだとアニメーションが動かない事で、例えばドロップダウンができなくなる。

これによってアドホック実装が生まれてしまうのですが、実はこのコード、Bulmaで必要なJavaScriptコードとほぼ変わりません。よく勘違いされてますが、BulmaでもJavaScriptコードは必須です。だからよく言われる「BulmaはJavaScriptがないから軽量」というのはちょっと違うし、CSSのファイルサイズで言えばBootstrapのほうが小さいです。

ただ、だからと言ってこの部分を見てBootstrap推しという訳でもないです。一番気になってるのは、non-jQueryなBootstrap 5でアニメーションがどうなるかというところ。 Animate.cssみたいな路線になるか、Bulma路線か、それともアニメーションを独自実装するか。現状ではあまりよくわかっていない。色々な選択肢が考えられるけど実装スタイルは結構変わりそう。どうせ実装が変わるなら今はどのCSSフレームワークを使っても大差ないかなとも思ったりする。

3. 小さなサイトならBootstrapほどのイベントフックはなくても良い

少し難しい事をしようとすると、コンポーネントがいくつかの状態を持つようになってくるので、どんなCSSフレームワークでもイベントフックが必要になります。ただ小さなサイトなら複雑なイベントフックは起きません。せいぜい1-2の状態しか持たず、複雑な事をしないならBulmaで十分と、私は思います。

イメージを掴んでもらうためにモーダルのON/OFFに何らかの追加処理を加えてみる例を考えてみましょう。 CSSのみで構築するのはBulmaでも無理です。 BulmaにはON/OFFのCSSは備わっているけど、実際の切替処理はJavaScriptを書く必要があります。 is-activeクラスのtoggleをJavaScriptで実行する事で選択状態を切り替える実装をし、そのイベントの監視を追加実装する事になると思われます。タブの切り替えやパネルの切り替えでも同じような実装が必要になる。

Boostrapではshow.bs.modalなどのイベントが用意されているので、そこを監視して何らかの処理をすれば良い。何が違うかというと、is-activeなどが隠蔽されている事、実装が若干簡素化される事、イベントの上書きのしやすさなどが異なってきます。フックの数が増えれば増えるだけJavaScriptの実装は面倒になるので、リッチUIならBootstrapに軍配が上がるでしょう。ただそんなにリッチにならないならBulmaの実装で十分です。

このような違いをどう考えるかで、どちらを選ぶか決めれば良いと思います。今回は正直どっちでも良いかなという感じだったし、スマホの見た目を調整してさえくれれば十分だったので、Bulmaの感触を確かめてみようと思いました。

使ってみた印象としては、Bulmaはやや癖のあるフレームワークです。そういうものなのだと思えば特に問題はないんですが、以下は注意点だと思いました。

card-body のような閉じた命名規則ではないので、class 名が被りやすい (これが一番の注意点か)
ul, liなどのリストはcontentクラス内に収めないとデフォルトではinline表示
min-height, max-widthなどの指定がされているものが多くてPCサイトで凝った事をしようとすると割とプロパティの再指定が必要
要素の意味を持たせるためにはクラスを指定しないと良い感じに表示できない (ex: inputにはinputクラスといった要領)

もっともこれくらいしかないとも言え、実際、特に迷うところもなくサイトは完成しました。仕様に関しては慣れればどうという事はないので、小さなサイトで利用したくて、jQueryを使う予定がなくて、早く仕様に慣れられる人には軽量で良いかも知れません。

ただ私の好みはやっぱりBootstrapかなあ…。慣れの問題かどうかは何個かサイトを作ってみないとわからないけど、Bootstrapはサンプルベースでパパっと書いても、ほとんど変更の必要がないUIに仕上がってくれるんですよね。デフォルトの margin, padding, width, height がかなりしっくり来るのと、以前書いたようにドキュメントの強さを感じる。

2019年4月1日月曜日

DropCSSを利用して遅延ロードを最適化

DropCSSという未使用CSSを削除して最適化するツールがバズっていましたが、処理や実装的にもコンパクトで気になるツールでした。これまで類似ツールとしてUnCSSを使っていましたが、scriptタグの評価なしに最適化でき高速なのは良いですね。 UnCSSだと外部scriptのValidation Errorに気を使う必要があったので、そのへんは使いやすくなった。

ただ現状では既にインライン化されているCSSは最適化の処理判定外になるので、HTMLとCSSは分離した開発が必須になります。 DropCSSの採用が増えれば、開発フェーズはより厳密化されるでしょうね。それともインラインCSSのサポートのほうが早いかな。

処理速度や圧縮効率より私が良いなと思ったのは、コードが簡素で改良が簡単な事です。これを活かして、さっそく未使用CSSを削除するだけではなく、CSSの遅延ロード時に使えるCSSを生成できるようにしてみました。遅延ロードしたいCSSの例は、ファーストビューでは不要と判定されてもセカンドビューなどで本当は必要で、後から読み込むべきCSSの事です。詳しい説明はこちら。

実装すべき事は至極単純で、HTML上に対応するCSSがない場合に削除するのではなく残すようにすれば良いだけです。これは以下のコードを書き換えるだけです。

# before
if (domSel == '' || CSSselect.selectOne(domSel, htmlAst.childNodes, {adapter}) || shouldDrop(sel) !== true)
# after
if (domSel == '' || !CSSselect.selectOne(domSel, htmlAst.childNodes, {adapter}) || shouldDrop(sel) !== true)
  pre.push(sel);

次に上記のコードを利用して以下の3つのCSSを生成します。

ファーストビューのCSS
ファーストビュー＋セカンドビューのCSS (--ignoreオプションなどを利用)
セカンドビューのCSS＝2のCSSに上記コードを適用したCSS

これまで1,2のCSSを構築する事は簡単でしたが、2は無駄が多かった。しかし上記コードを用いれば効率の良い3を簡単に生成できるようになりました。これによって削減できるデータ量のイメージは以下。セカンドビューに含まれていた不要な10%のCSSが削減できる。

original: 100%
before: 25% = 10% + 15=(10+5)%
after:  15% = 10% +  5=(15-10)%

このような最適化をしやすいところが、DropCSSの一番の利点と言えるでしょう。

登録: 投稿 (Atom)