タグ: SharePoint

SharePoint に限らずページの表示速度が遅い事はユーザーの利活用促進を阻みます。オッサンになって更に記憶力が悪くなったので正確な情報ではありませんが、たしか通常のWebサイトではページの表示が2秒だか3秒以上かかると、ユーザーの離脱率がグンと上がるようです。なので、パフォーマンスについての対策は検討すべきかと思います。

パフォーマンスについては様々な原因があるのですが、ここではページを編集できる権限レベルでも調査できる、ページの表示速度が遅い原因を紹介します。

▼対象のページを表示します。（デモでは極端にWebパーツをゼロにしました）

▼編集モードにして、表示されているWebパーツの数を正確に数えます。（ゼロ個）

▼編集モードを終えて、URLの末尾に「?contents=1」を入力します。

▼このページが持っているWebパーツの一覧画面が表示されます。

ここで先ほど数えたWebパーツ数とここの一覧の数が一致しているかを確認してください。（表示上はゼロ個だったのに対し、こちらでは4個あります。）

以上です。

ここまでは過去に類似した記事を投稿済みです。

SharePoint ：ページにWebパーツを追加すると1つしか表示していないのにWebパーツのタイトルに[1]が表示される

ただ、この時では気がついていなかったのですが、この一覧で「ページで開く」が「はい」になっているWebパーツは、実は表示上は消えているけど裏で生きている透明人間のような存在で、なんとソース上ではレンダリングされているんです。
この透明人間Webパーツが、表示速度が遅い原因である場合があるんです。

例えば…

▼このような「lib001」というライブラリがあるとします。事前に「search_test01」がある事を確認してください。

▼先ほどの見た目はWebパーツが1つもないページ

▼ただしこのように透明人間Webパーツが多々あり、この中に「lib001」ライブラリも含まれています。

さて、この状態で該当ページのソースから「search_test01」を検索します。

▼このようにソース上ではレンダリングされているんです。

この透明人間Webパーツが単体動作する軽量なWebパーツなら良いですが、数千アイテムあるアプリをフィルターかけていない状態でアプリパーツとして配置している場合、しかもそれが数個あった場合は、パフォーマンスに影響はあると考えます。

なので、上述の調査で数が一致しなかった場合は、透明人間Webパーツを削除してみましょう。

実際に、表示速度が遅い悩みのあるページで、上述の方法で調査した結果、透明人間Webパーツが大量にあり、一覧ページから完全抹殺したところ、劇的に表示速度が速くなった例もあります。

もちろんこれは原因のほんの1つなのですが、調べ方は簡単なので調査する価値はあるのかなと思います。

リストやライブラリといったアプリは、新しい表示（モダンUI）とクラシック表示は切り替え可能です。（一部アプリは新しい表示には対応していませんが。）
しかし、ページに関しては作成後に切り替える事は不可能かと思います。

で、前回の記事の冒頭でも少し触れましたが、SharePoint Online でクラシック表示のサイトでも、歯車アイコンからページを追加した際に、いつからかモダンページで作成されるようになりました。

SharePoint ：「ページの追加」をした際のモダンページとクラシックページの挙動の違いと注意点

ではページは作成後にモダンとクラシックは切り替えられない認識なので、クラシックページはもう作成できなくなった？と思うとそうではありません。

では、ページの追加方法は複数ありますが、それぞれの挙動を探ってみます。

■歯車アイコンから

すでにわかってはいますが念のため。結果としてモダンUIでもクラシックUIでもどちらからでも、歯車アイコンからの挙動は同じなので、以下はクラシックUIからのスクショを。

▼サイト内のどのページからでも「歯車アイコン」→「ページの追加」

▼モダンページが作成されます。

■モダンUIの「サイトのページ」ライブラリから

▼「+新規」→「Wiki ページ」

▼クラシックページ用のページ名入力画面

▼編集モードのクラシックページ

▼「+新規」→「Web パーツ ページ」

▼クラシックページ（Web パーツ ページ）の作成前の設定画面

興味深いのがサイトのページライブラリから新規作成したのに、「保存場所」の初期値が「サイトのリソース ファイル」になっている事。つまり、作ろうとしたライブラリとは別のライブラリに作られてしまいます。また、逆に「サイトのリソース ファイル」ライブラリからはWeb パーツ ページ を作成するUIはないんですよねぇ。ユーザーの混乱の元ですね。

▼編集モードのクラシックページ（Web パーツ ページ）

▼「+新規」→「サイト ページ」

▼モダンページが作成されます。

■クラシックUIの「サイトのページ」ライブラリから

▼「+新規」

▼クラシックページ用のページ名入力画面

▼編集モードのクラシックページ

▼クラシックUIのリボンの「新しいドキュメント」

これらは全てモダンUIと同じ挙動でした。（のでスクショは割愛）

たしかページの追加方法はこのくらいだったと思います。
まとめると…

こんな感じですかね。
モダンページとクラシックページを使い分けたい、歯車アイコンからのページの追加はモダンページだけどクラシックページを作成するにはどうしたらいい？などお困りの際にはご参考に。ただし、いつ動作が変わるか分からないのが SharePoint Online なので、明日には変わっているかもしれません。できるだけ最新の状況を追いますけどね。

SharePoint Online では、いつからかわかりませんが、「歯車アイコン」→「ページの追加」からページを作成すると、モダンページで作成されるようになりましたね。

ところで、クラシックページを作成する手順は以下の通りでした。

▼ページを追加するとページ名を入力する画面表示され、入力後に「作成」ボタンを

▼するとページが編集モードで開くので編集開始します。

しかし、モダンページでは挙動がちょっと違います。

▼ページを追加すると即編集モードでページが開きます。

クラシックページでは、ページ名を入力する画面でキャンセルができましたが、モダンページでは、即編集モードが開くので、実は裏側ではこの時点ですでにページは作成されています。

▼サイトのページライブラリを見ると、このようにランダム文字列のページ名で作成されています。

発行前なので閲覧ユーザーには表示されませんが、ページの追加をした後に「やっぱや～めた」的にタブを閉じるなどをした場合は、この挙動に気がつかずにキャンセルしたと思っていたページが未発行状態のままで作成されていますので、サイトのページライブラリを確認し、作成されてしまったページを削除しましょう。

特にページ作成者が多いサイトの場合は、モダンページになると、このようなゴミページがたくさんあるかもしれないですね。今までの経験上、リストとライブラリをメインで利用してページはホームページ以外は利用しない場合が多かったですが、ここ最近の動向などを見ると、今後はページは利用されてくるかもしれません。

開発・カスタマイズに利用する画像・CSS・JSファイルなどの格納先を「サイトのリソース ファイル」ライブラリに指定される事がよくあります。このライブラリはサイトを作成すると自動で作成されているのですが、「リソース」とは日本語で「資源・資産」なんて訳せると思うので、サイトのカスタマイズに利用する資源の格納先に選んでしまいがちでしょうか。

しかし、過去にも少し取り上げましたが、「サイトのリソース ファイル」ライブラリのそもそもの利用方法があり、それを考えるとカスタマイズファイルの格納先には向いていないのでは？と思います。

SharePoint 複数行テキスト列で画像・ビデオ・ファイルを挿入する際の「宛先ライブラリ」の初期値変更

「サイトのリソース ファイル」ライブラリとは、概ねページやアイテムに画像などを表示させる際のアップロード先と思って頂いて良いと思います。

SharePoint 2007 の頃はアイテムの複数行テキスト列に画像を表示したい場合は、先にどこかのライブラリに画像をアップロードし、URLを控えて、それを複数行テキスト列に指定して表示させていました。SharePoint 2010 からこの手間が楽になり、複数行テキスト列のリッチテキストエディタ内で、画像をアップロードしつつ表示させる事ができるようになりました。このアップロード先はサイト内のライブラリを指定できるのですが、その初期値で指定されているライブラリが「サイトのリソース ファイル」です。同じくビデオを表示させる際のアップロード先もそうです。

▼複数行テキスト列でコンピューターから画像を挿入すると

▼宛先ライブラリの初期値が「サイトのリソース ファイル」になっています。

▼新しい表示（モダンUI）のニュースページのヘッダー画像の追加も

▼アップロードする先は「サイトのリソース ファイル」になっています。

※しかも、新しい表示（モダンUI）のニュースページでは、宛先ライブラリの指定はできず「サイトのリソース ファイル」で固定のようです。

つまり、ここに開発・カスタマイズファイルを格納してしまうと、サイト運営開始してから上述のような方法で利用される画像・ビデオファイルと混在してしまいます。

「別に混在してもいいよ」って場合も、更に注意点としてアクセス権限があります。「サイトのリソース ファイル」ライブラリはデフォルトでは親となるサイトの権限を継承しています。つまりサイトに投稿権限以上あれば、ライブラリ内のフォルダーやファイルは編集・削除も可能です。それがなぜ注意点かというと…サイトの開発・カスタマイズに利用しているファイルを、特定多数の人達が編集・削除できてしまうという事です。

もちろんアクセス権限はフォルダー単位でも独立させて設定できますが、そこまでしてもサイトの開発・カスタマイズに利用しているファイルを「サイトのリソース ファイル」ライブラリに格納しなければいけない理由って逆にないと思います。

だとしたら、ゴチャゴチャしていなく権限も安全なライブラリに格納した方が良いのかなと思います。

• 専用のライブラリを作成する
• マスターページギャラリーやスタイルライブラリに格納する
• 専用のサイト（コレクション）を作成する
• 別のサーバーに格納する

などなど。それぞれの環境に合わせたやり方は色々ありますね。

もちろん、その上で「サイトのリソース ファイル」ライブラリを利用したい場合は、それもまた不正解ではなく正解なんだと思います。