在圖像密集型網頁上的加載速度

Question

我目前在一個投資組合網站上工作，在那里我必須在同一頁面上加載大量照片。

這些圖像是通過PHP動態加載的，目前，我選擇了預先保存這些圖像的縮略圖版本並進行加載。

但是，我擔心的是，如果該站點有大量用戶，這可能不是最佳解決方案：我基本上會將每個圖像的重復數乘以用戶上傳的圖像數。

我的問題是，對於這個問題是否有更好的解決方案？ 一種在不損害太多空間的情況下盡快加載頁面的方法？

萬分感謝。

Answer 1

加載包含大量圖像的網頁會很慢。 其原因是由於傳輸這些圖像所需的帶寬。

您有幾種選擇

1. 以平鋪模式加載完整圖像。 這些圖像將是完整圖像，只是調整大小以適合“縮略圖”視圖。 這樣做的好處是您只保存1張圖像，但是該圖像是全尺寸的，因此加載時間很長。

2. 按照您說的那樣加載縮略圖。 這樣做的好處是性能，但是您需要為每個圖像存儲兩個副本。 另外，根據您處理縮略圖創建的方式，您可能會要求用戶上傳圖像的兩個副本以提供自己的縮略圖...這可能會發臭。

3. 加載縮略圖，但在上傳時動態生成縮略圖。 您實際上是在磁盤上保留映像的兩個副本，但是您是通過一些php映像修改API動態創建的。 這樣可以更快地加載，但是仍然會占用磁盤空間。 它還最小化了提供縮略圖的用戶/管理要求。

4. 根據要求，按需加載縮略圖。 這種方法需要進行一些測試，因為我從未嘗試過。 基本上，您將調用php圖像修改API（或將其更好地外包給本機解決方案！）來創建要使用的一次性（或緩存的）縮略圖。 您可能會說“ OMG，這將花費很長時間！”。 我認為，如果您應用適當的緩存機制，那么這種方法實際上可能會有用，這樣您就不會不斷地重新創建相同的縮略圖。 它將限制帶寬，並且由於這里的限制因素是網絡連接，因此它可能比僅發送完整圖像更快（因為創建縮略圖的限制因素現在是CPU /內存/硬盤）。

我認為＃4是一個有趣的概念，可能值得探討。

Answer 2

1. 動態生成大圖像的縮略圖。 （ 一些提示 ）
2. 異步加載圖像（嘗試JAIL ）
3. 分頁
4. 緩存也是一種選擇，但是從第二次加載站點開始就可以使用。

Answer 3

我認為是：

A.利用高速緩存（系統高速緩存，標頭中的高速緩存，HTTP高速緩存..所有高速緩存）

B.不要一直產生Thumb

C.使用諸如Gearman或beanstalkd的Job Queing系統生成拇指，這樣您就不必立即做

D.使用Imagick更有效

E.分頁

F.僅在修改原始文件后，示例才會生成Thumb

$file = "a.jpg" ;
$thumbFile = "a.thumb.jpg" ;
$createThumb = true;
if(is_file($thumbFile))
{
    if((filemtime($file) - 10) < filemtime($thumbFile));
    {
        $createThumb = false;
    }
}


if($createThumb === true)
{
    $thumb = new Imagick();
    $thumb->readImage($file);
    $thumb->thumbnailImage(50, null);
    $thumb->writeImage($thumbFile);
    $thumb->destroy();
}

Answer 4

考慮對所有圖像使用精靈或拼貼，以便僅加載一個較大的圖像，從而節省帶寬並減少頁面加載時間。

同樣，正如已經建議的，分頁和異步加載可以改善它。

參考文獻：

• http://css-tricks.com/css-sprites/
• http://en.wikipedia.org/wiki/Sprite_(computer_graphics)#Sprites_by_CSS

Answer 5

是的 ，緩存縮略圖是個好主意，如果操作正確，效果會很好。 這種東西是水平縮放的好地方。

1. 您應該考慮使用CDN 。 （或者可能實現類似的東西。）緩存系統將生成通常要求的大小的圖像，並在以后不經常請求時將其整理掉。
2. 您還可以水平擴展並將該服務移植到網絡或雲中的另一台服務器或虛擬服務器上。

它是磁盤密集型和帶寬密集型的事物，即圖像傳遞。 不如視頻差！