pple 致力于讓每件產(chǎn)品都賞心悅目,與其說官網(wǎng)是產(chǎn)品展示平臺,倒不如說它是蘋果產(chǎn)品分支的延續(xù)。從 Apple.com 找設計靈感是每一位設計師都做過的事,那它到底有何魅力?文章對Apple的網(wǎng)頁設計展開了梳理分析,與大家分享。
每當有新產(chǎn)品發(fā)布時,我們都會被它的 Landing page 所吸引。不管是 AirPods Pro 也好,和前段時間發(fā)布的 iPad Pro 也一樣。
這背后是 Apple 基于 webGL 技術,創(chuàng)造的一種沉浸與交互式產(chǎn)品體驗。
我們在產(chǎn)品介紹頁可以看到,蘋果使用了大量的滾動 scroll 來體現(xiàn)連續(xù)性。
一方面,滾動作為大多數(shù) Web 用戶最自然的操作,學習成本極低。
另一方面,在冗長的頁面下,滾動能讓產(chǎn)品特性保持更自然的轉場銜接。
iPad Pro 的連續(xù)性
另外,采用了大量的動畫式轉換(animated transition),即操作時展示的動態(tài)效果,以此來增加趣味性。
伴隨著豐富的、若隱顯現(xiàn)的章節(jié)文案,就像電影的旁白一樣,娓娓道來。
通過滾動的方式增加交互性,這是明智之舉。試想一下,如果只放置已渲染的演示視頻,那么用戶的操作會受到限制,只能在視頻中前進或后退,毫無樂趣可言。
AirPods的趣味性
說到言之有序,我們看 iPad 的頁面介紹。四款產(chǎn)品,分別是:iPad Pro、iPad Air、iPad、iPad mini。
拍攝角度的秩序感,可謂妙不可言。
iPad的秩序感
如此一來,即顯得有序,也不會導致視覺疲勞。
其次,官網(wǎng)與 iOS 保持協(xié)同的設計語言,給用戶呈現(xiàn)了一致的感官體驗。
從 iOS 11 開始,蘋果就采用了 Large Title 大標題的字體風格。字重也從 Regular + Light 的組合,轉向的 Medium + Bold ,以此增強信息傳播中的識別力。
HomePod
另外,高斯模糊的標題欄背景、產(chǎn)品的投影等設計語言也保持系統(tǒng)一貫的風格。我們可以很清晰的看到 Web 設計的同步轉變。
第三是視差帶來的層次感。
蘋果奉行包豪斯的無裝飾和極簡的理念。當然,它不是那種附庸的美觀及外表的光鮮,而是將復雜難懂的技術以簡潔的形式傳達給用戶。
Mac Pro 視差滾動
在信息層次方面,Apple 的編排設計由淺入深,猶如抽絲剝繭。很好的利用了視差滾動,傳達圖片與文字之間「層」的概念。這種深度感可以增加用戶的理解和樂趣。
不僅如此,樣式上富有視覺張力。或擴張、或收縮、或吸引、或排斥之感覺,呈現(xiàn)刺激與震撼。舉兩個例子:
A13芯片的擴張力
擴張力:整個畫面以 A13芯片 為視覺中心點,元素和布局圍繞這個視覺中心點向外擴張。采用發(fā)散式的視覺引導,視覺張力就出現(xiàn)了,讓人感覺巍峨壯觀。
Pro級攝像頭的排斥力
排斥力:通過元素的大小對比,可以形成一定強度的視覺排斥力。Pro級攝像頭 輔以大特寫,傳達空間意識。視覺上被其構圖、美感觸動。
再聊聊蘋果的高級感是怎么來的?
我們都知道,高飽和度的色彩,會影響人的情緒波動。相反,低飽和度的配色,對人眼的刺激較弱,會有一種冷靜且克制的高級感。
iMac Pro 高級感
回過頭來看蘋果官網(wǎng)的大部分頁面,除了產(chǎn)品界面色彩 和 按鈕藍 之外,其他的文字、背景、控件一律采用黑白灰色系,以此營造高級感。
甚至是 iPhone 11 Pro 新出的暗夜綠,也是高級灰中加了一點點綠而已。
換言之,減少使用顏色的數(shù)量,降低色彩的飽和度都能削減色彩對人的情緒,起到提升產(chǎn)品高級感的效果。
iPad 留白
除此之外,恰當?shù)牧舭卓梢愿油怀霎a(chǎn)品內(nèi)容,讓重要的信息更準確的傳達。并且能營造出廣闊的空間感,讓畫面得到延伸,呈現(xiàn)一種意境美。
所以我們做設計時應當多做減法,避免無意義的視覺元素堆砌,反而能讓你的設計更有高級的氣質(zhì)。
這又印證了現(xiàn)代主義建筑大師密斯·凡德羅的那句話:Less Is More。
當然,只有留白是不夠的。既然是做宣傳,那么一份高分辨率、精致的配圖就顯得尤為重要。
蘋果官網(wǎng)大部分的產(chǎn)品都是采用實拍+后期修圖,而非渲染圖。目的就是為了反映真實產(chǎn)品的質(zhì)感、以及材質(zhì)光影效果,這一點能看到蘋果對于品質(zhì)的極致追求。
Designed by Apple in California
不僅如此,蘋果產(chǎn)品圣經(jīng)《Designed by Apple in California》,以及壁紙同樣是由攝影師拍攝完成。有興趣的同學可以看下面這個幕后制作視頻,相當硬核。
做過英文 Web 的設計師都知道,英文往往比中文更好設計,相同的布局英文出來的效果也更好看。
這不是崇洋媚外,心理學有個詞叫做「母語羞澀」。簡單來說就是,中文對于我們來說,太常見了會讓人產(chǎn)生一種廉價感(實際上是羞澀感)的心理感受。
老外也一樣,你可以看到美國企業(yè):蘋果、麥當勞、星巴克都是使用圖形 Logo,而日本企業(yè)不用母語,而是用英文,比如 SONY、TOYOTA、Canon。
你的下一臺電腦,何必是電腦。
回到蘋果官網(wǎng),我們看到一部分文案是英文產(chǎn)品名稱,這個不會感覺羞澀。
那中文部分怎么辦呢?比較有意思的是,Apple 的本土化團隊用了完全不對仗但押韻、奇怪的排比、雙關、重復等修辭手法。雖然語感很差,但基本上能明白字面意思。
其實這樣做的目的就是為了創(chuàng)造一種陌生感、一種獨特的語言風格,來凸品牌氣質(zhì)。舉幾個例子:
最后一點。生活要有儀式感,蘋果官網(wǎng)也有儀式感。
國際婦女節(jié)專題
在一些特殊的日子里,例如三八節(jié)當天,友商選擇打廣告促銷。而蘋果推出了國際婦女節(jié)專題,致敬女性的偉大,這一做法頗具人文情懷。
不過話又說回來,感動歸感動,還是參與友商的打折活動香。
Apple 的設計哲學:交互篇
Apple 的設計哲學:UI 篇
Apple 的設計哲學:聲音篇
作者:阿洋;公眾號:洋爺(ID:yangye365)網(wǎng)易資深視覺設計師,每周分享關于交互、產(chǎn)品、視覺上的思考,歡迎關注交流。
本文由 @洋爺 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉載。
題圖來自Unsplash,基于CC0協(xié)議。
能夠?qū)懗龌镜捻撁妫ɡ锩姘瑘D片、各種標簽和鏈接)
我們主要用的開發(fā)工具有chrome、hbuilder、Photoshop
瀏覽器是網(wǎng)頁顯示、運行的平臺,常用的瀏覽器有IE、火狐(Firefox)、谷歌(Chrome)、Safari和Opera等。我們平時稱為五大瀏覽器。
瀏覽器內(nèi)核又可以分成兩部分:渲染引擎(layout engineer 或者 Rendering Engine)和 JS 引擎。
渲染引擎 :它負責取得網(wǎng)頁的內(nèi)容(HTML、XML、圖像等等)、整理訊息(例如加入 CSS 等),以及計算網(wǎng)頁的顯示方式,然后會輸出至顯示器或打印機。瀏覽器的內(nèi)核的不同對于網(wǎng)頁的語法解釋會有不同,所以渲染的效果也不相同。
JS 引擎 則是解析 Javascript 語言,執(zhí)行 javascript語言來實現(xiàn)網(wǎng)頁的動態(tài)效果。
最開始渲染引擎和 JS 引擎并沒有區(qū)分得很明確,后來 JS 引擎越來越獨立,內(nèi)核就傾向于只指渲染引擎。有一個網(wǎng)頁標準計劃小組制作了一個 ACID 來測試引擎的兼容性和性能。內(nèi)核的種類很多,如果加上沒什么人使用的非商業(yè)的免費內(nèi)核,可能會有10多種,但是常見的瀏覽器內(nèi)核可以分這四種:Trident、Gecko、Blink、Webkit。
了解一點:移動端的瀏覽器內(nèi)核主要說的是系統(tǒng)內(nèi)置瀏覽器的內(nèi)核。
Android手機而言,使用率最高的就是Webkit內(nèi)核,大部分國產(chǎn)瀏覽器宣稱的自己的內(nèi)核,基本上也是屬于webkit二次開發(fā)。
iOS以及WP7平臺上,由于系統(tǒng)原因,系統(tǒng)大部分自帶瀏覽器內(nèi)核,一般是Safari或者IE內(nèi)核Trident的
結構標準:結構用于對網(wǎng)頁元素進行整理和分類,咱們主要學的是HTML。 最重要
表現(xiàn)標準:表現(xiàn)用于設置網(wǎng)頁元素的版式、顏色、大小等外觀樣式,主要指的是CSS。
行為標準:行為是指網(wǎng)頁模型的定義及交互的編寫,咱們主要學的是 Javascript
HTML(英文Hyper Text Markup Language的縮寫)中文譯為“超文本標簽語言”。是用來描述網(wǎng)頁的一種語言。
所謂超文本,因為它可以加入圖片、聲音、動畫、多媒體等內(nèi)容,不僅如此,它還可以從一個文件跳轉到另一個文件,與世界各地主機的文件連接。
<h1> 我是一個大標題 </h1>
注意: 體會 文本 標簽 語言 幾個詞語
總結: HTML 作用就是用標記標簽來描述網(wǎng)頁,把網(wǎng)頁內(nèi)容在瀏覽器中展示出來。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</style>
</head>
<body>
<div class="box"></div>
</body>
</html>
1.HTML標簽:
作用所有HTML中標簽的一個根節(jié)點。 最大的標簽 根標簽
2 head標簽: 文檔的頭部
文檔的頭部描述了文檔的各種屬性和信息,包括文檔的標題、在 Web 中的位置以及和其他文檔的關系等。絕大多數(shù)文檔頭部包含的數(shù)據(jù)都不會真正作為內(nèi)容顯示給讀者。
注意在head標簽中我們必須要設置的標簽是title
3.title標簽: 文檔的標題
作用:讓頁面擁有一個屬于自己的標題。
4.body標簽:文檔的主體 以后我們的頁面內(nèi)容 基本都是放到body里面的
body 元素包含文檔的所有內(nèi)容(比如文本、超鏈接、圖像、表格和列表等等。)
在HTML頁面中,帶有“< >”符號的元素被稱為HTML標簽,如上面提到的 HTML、head、body都是HTML骨架結構標簽。所謂標簽就是放在“< >” 標簽符中表示某個功能的編碼命令,也稱為HTML標簽或 HTML元素
1.雙標簽
<標簽名> 內(nèi)容 </標簽名>
該語法中“<標簽名>”表示該標簽的作用開始,一般稱為“開始標簽(start tag)”,“</標簽名>” 表示該標簽的作用結束,一般稱為“結束標簽(end tag)”。和開始標簽相比,結束標簽只是在前面加了一個關閉符“/”。
比如 <body>我是文字 </body>
2.單標簽
<標簽名 />
單標簽也稱空標簽,是指用一個標簽符號即可完整地描述某個功能的標簽。
比如 <br />
標簽的相互關系就分為兩種:
1.嵌套關系
<head> <title> </title> </head>
2.并列關系
<head></head> <body></body>
首先 HTML和CSS是兩種完全不同的語言,我們學的是結構,就只寫HTML標簽,認識標簽就可以了。 不會再給結構標簽指定樣式了。
HTML標簽有很多,這里我們學習最為常用的,后面有些較少用的,我們可以查下手冊就可以了。
排版標簽
單詞縮寫: head 頭部. 標題 title 文檔標題
為了使網(wǎng)頁更具有語義化,我們經(jīng)常會在頁面中用到標題標簽,HTML提供了6個等級的標題,即
<h1>、<h2>、<h3>、<h4>、<h5>和<h6>
其基本語法格式如下:
<hn> 標題文本 </hn>
<p> 文本內(nèi)容 </p>
<hr />是單標簽
<br />
div span 是沒有語義的 是我們網(wǎng)頁布局主要的2個盒子 css+div
div 就是 division 的縮寫 分割, 分區(qū)的意思 其實有很多div 來組合網(wǎng)頁。
span, 跨度,跨距;范圍
語法格式:
<div> 這是頭部 </div> <span>今日價格</span>
在網(wǎng)頁中,有時需要為文字設置粗體、斜體或下劃線效果,這時就需要用到HTML中的文本格式化標簽,使文字以特殊的方式顯示。
b i s u 只有使用 沒有 強調(diào)的意思 strong em del ins 語義更強烈
使用HTML制作網(wǎng)頁時,如果想讓HTML標簽提供更多的信息,可以使用HTML標簽的屬性加以設置。其基本語法格式如下:
<標簽名 屬性1="屬性值1" 屬性2="屬性值2" …> 內(nèi)容 </標簽名>
在上面的語法中,
1.標簽可以擁有多個屬性,必須寫在開始標簽中,位于標簽名后面。
2.屬性之間不分先后順序,標簽名與屬性、屬性與屬性之間均以空格分開。
3.任何標簽的屬性都有默認值,省略該屬性則取默認值。
采取 鍵值對 的格式 key="value" 的格式
比如:
<hr width="400" />
屬性 是 寬度
值 是 400
單詞縮寫: image 圖像
HTML網(wǎng)頁中任何元素的實現(xiàn)都要依靠HTML標簽,要想在網(wǎng)頁中顯示圖像就需要使用圖像標簽,接下來將詳細介紹圖像標簽<img />以及和他相關的屬性。其基本語法格式如下:
該語法中src屬性用于指定圖像文件的路徑和文件名,他是img標簽的必需屬性。
<img src="圖像URL" />
單詞縮寫: anchor 的縮寫 [???k?(r)] 。基本解釋 錨, 鐵錨 的
在HTML中創(chuàng)建超鏈接非常簡單,只需用標簽環(huán)繞需要被鏈接的對象即可,其基本語法格式如下:
<a href="跳轉目標" target="目標窗口的彈出方式">文本或圖像</a>
href:用于指定鏈接目標的url地址,當為標簽應用href屬性時,它就具有了超鏈接的功能。 Hypertext Reference的縮寫。意思是超文本引用
target:用于指定鏈接頁面的打開方式,其取值有self和blank兩種,其中self為默認值,blank為在新窗口中打開方式。
注意:
1.外部鏈接 需要添加 http:// www.baidu.com
2.內(nèi)部鏈接 直接鏈接內(nèi)部頁面名稱即可 比如 < a href="index.html"> 首頁
3.如果當時沒有確定鏈接目標時,通常將鏈接標簽的href屬性值定義為“#”(即href="#"),表示該鏈接暫時為一個空鏈接。
4.不僅可以創(chuàng)建文本超鏈接,在網(wǎng)頁中各種網(wǎng)頁元素,如圖像、表格、音頻、視頻等都可以添加超鏈接。
通過創(chuàng)建錨點鏈接,用戶能夠快速定位到目標內(nèi)容。
創(chuàng)建錨點鏈接分為兩步:
1.使用“a href=”#id名>“鏈接文本"</a>創(chuàng)建鏈接文本(被點擊的) <a href="#two"> 2.使用相應的id名標注跳轉目標的位置。 <h3 id="two">第2集</h3>
base 可以設置整體鏈接的打開狀態(tài)
base 寫到 <head> </head> 之間
把所有的連接 都默認添加 target="_blank"
在HTML中還有一種特殊的標簽——注釋標簽。如果需要在HTML文檔中添加一些便于閱讀和理解但又不需要顯示在頁面中的注釋文字,就需要使用注釋標簽。其基本語法格式如下:
<!-- 注釋語句 --> ctrl + / 或者 ctrl +shift + /
注釋內(nèi)容不會顯示在瀏覽器窗口中,但是作為HTML文檔內(nèi)容的一部分,也會被下載到用戶的計算機上,查看源代碼時就可以看到。
實際工作中,通常新建一個文件夾專門用于存放圖像文件,這時再插入圖像,就需要采用“路徑”的方式來指定圖像文件的位置。
根目錄 當前目錄
路徑可以分為: 相對路徑和絕對路徑
以引用文件之網(wǎng)頁所在位置為參考基礎,而建立出的目錄路徑。因此,當保存于不同目錄的網(wǎng)頁引用同一個文件時,所使用的路徑將不相同,故稱之為相對路徑。
絕對路徑以Web站點根目錄為參考基礎的目錄路徑。之所以稱為絕對,意指當所有網(wǎng)頁引用同一個文件時,所使用的路徑都是一樣的
“D:webimglogo.gif”,或完整的網(wǎng)絡地址,例如“http://www.itcast.cn/images/l...”。
無序列表的各個列表項之間沒有順序級別之分,是并列的。其基本語法格式如下:
<ul> <li>列表項1</li> <li>列表項2</li> <li>列表項3</li> ...... </ul>
注意:
有序列表即為有排列順序的列表,其各個列表項按照一定的順序排列定義,有序列表的基本語法格式如下:
<ol> <li>列表項1</li> <li>列表項2</li> <li>列表項3</li> ...... </ol>
所有特性基本與ul 一致。
但是實際工作中, 較少用 ol img src="media/1.jpg" />
定義列表常用于對術語或名詞進行解釋和描述,定義列表的列表項前沒有任何項目符號。其基本語法如下:
<dl> <dt>名詞1</dt> <dd>名詞1解釋1</dd> <dd>名詞1解釋2</dd> ... <dt>名詞2</dt> <dd>名詞2解釋1</dd> <dd>名詞2解釋2</dd> ... </dl>
在HTML網(wǎng)頁中,要想創(chuàng)建表格,就需要使用表格相關的標簽。創(chuàng)建表格的基本語法格式如下:
<table> <tr> <td>單元格內(nèi)的文字</td> ... </tr> ... </table>
在上面的語法中包含三對HTML標簽,分別為 table</table、tr</tr、td</td,他們是創(chuàng)建表格的基本標簽,缺一不可,下面對他們進行具體的解釋
1.table用于定義一個表格。
2.tr 用于定義表格中的一行,必須嵌套在 table標簽中,在 table中包含幾對 tr,就有幾行表格。
3.td /td:用于定義表格中的單元格,必須嵌套在<tr></tr>標簽中,一對 <tr> </tr>中包含幾對<td></td>,就表示該行中有多少列(或多少個單元格)。
注意:
1. <tr></tr>中只能嵌套<td></td> 2. <td></td>標簽,他就像一個容器,可以容納所有的元素
表頭一般位于表格的第一行或第一列,其文本加粗居中,如下圖所示,即為設置了表頭的表格。設置表頭非常簡單,只需用表頭標簽th</th替代相應的單元格標簽td</td即可。
在使用表格進行布局時,可以將表格劃分為頭部、主體和頁腳(頁腳因為有兼容性問題,我們不在贅述),具體 如下所示:
<thead></thead>:用于定義表格的頭部。
必須位于<table></table> 標簽中,一般包含網(wǎng)頁的logo和導航等頭部信息。
<tbody></tbody>:用于定義表格的主體。
位于<table></table>標簽中,一般包含網(wǎng)頁中除頭部和底部之外的其他內(nèi)容。
表格的標題: caption
定義和用法
caption 元素定義表格標題。
<table> <caption>我是表格標題</caption> </table>
caption 標簽必須緊隨 table 標簽之后。您只能對每個表格定義一個標題。通常這個標題會被居中于表格之上。
跨行合并:rowspan 跨列合并:colspan
合并單元格的思想:
將多個內(nèi)容合并的時候,就會有多余的東西,把它刪除。 例如 把 3個 td 合并成一個, 那就多余了2個,需要刪除。 公式: 刪除的個數(shù) = 合并的個數(shù) - 1
合并的順序 先上 先左
表格的學習要求: 能手寫表格結構,并且能合并單元格。
表單控件:
包含了具體的表單功能項,如單行文本輸入框、密碼輸入框、復選框、提交按鈕、重置按鈕等。
提示信息:
一個表單中通常還需要包含一些說明性的文字,提示用戶進行填寫和操作。
表單域:
他相當于一個容器,用來容納所有的表單控件和提示信息,可以通過他定義處理表單數(shù)據(jù)所用程序的url地址,以及數(shù)據(jù)提交到服務器的方法。如果不定義表單域,表單中的數(shù)據(jù)就無法傳送到后臺服務器。
在上面的語法中,input /標簽為單標簽,type屬性為其最基本的屬性,其取值有多種,用于指定不同的控件類型。除了type屬性之外,input /標簽還可以定義很多其他的屬性,其常用屬性如下表所示。
label 標簽為 input 元素定義標注(標簽)。
作用: 用于綁定一個表單元素, 當點擊label標簽的時候, 被綁定的表單元素就會獲得輸入焦點
如何綁定元素呢?
for 屬性規(guī)定 label 與哪個表單元素綁定。
<label for="male">Male</label> <input type="radio" name="sex" id="male" value="male">
如果需要輸入大量的信息,就需要用到textarea/textarea標簽。通過textarea控件可以輕松地創(chuàng)建多行文本輸入框,其基本語法格式如下:
<textarea cols="每行中的字符數(shù)" rows="顯示的行數(shù)"> 文本內(nèi)容 </textarea>
使用select控件定義下拉菜單的基本語法格式如下
<select> <option>選項1</option> <option>選項2</option> <option>選項3</option> ... </select>
注意:
在HTML中,form標簽被用于定義表單域,即創(chuàng)建一個表單,以實現(xiàn)用戶信息的收集和傳遞,form中的所有內(nèi)容都會被提交給服務器。創(chuàng)建表單的基本語法格式如下:
<form action="url地址" method="提交方式" name="表單名稱"> 各種表單控件 </form>
常用屬性:
注意: 每個表單都應該有自己表單域。
如需轉載,請注明出處,否則將追究法律責任。
參考回答:
https 的 SSL 加密是在傳輸層實現(xiàn)的。
(1)http 和 https 的基本概念
http: 超文本傳輸協(xié)議, 是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議, 是一個客戶端和服 務器端請求和應答的標準 (TCP) , 用于從 WWW 服務器傳輸超文本到本地瀏覽器的傳 輸協(xié)議, 它可以使瀏覽器更加高效, 使網(wǎng)絡傳輸減少。
https: 是以安全為目標的 HTTP 通道, 簡單講是 HTTP 的安全版, 即 HTTP 下加入 SSL 層, HTTPS 的安全基礎是 SSL, 因此加密的詳細內(nèi)容就需要 SSL。
https 協(xié)議的主要作用是:建立一個信息安全通道,來確保數(shù)組的傳輸,確保網(wǎng)站的真實 性。
(2)http 和 https 的區(qū)別?
http 傳輸?shù)臄?shù)據(jù)都是未加密的,也就是明文的, 網(wǎng)景公司設置了 SSL 協(xié)議來對 http 協(xié)議 傳輸?shù)臄?shù)據(jù)進行加密處理,簡單來說 https 協(xié)議是由 http 和 ssl 協(xié)議構建的可進行加密傳 輸和身份認證的網(wǎng)絡協(xié)議, 比 http 協(xié)議的安全性更高。
主要的區(qū)別如下:
Https 協(xié)議需要 ca 證書, 費用較高。
http 是超文本傳輸協(xié)議, 信息是明文傳輸, https 則是具有安全性的 ssl 加密傳輸協(xié)議。 使用不同的鏈接方式, 端口也不同, 一般而言, http 協(xié)議的端口為 80, https 的端口為443。
http 的連接很簡單,是無狀態(tài)的;HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構建的可進行加密傳 輸 、身份認證的網(wǎng)絡協(xié)議, 比 http 協(xié)議安全。
(3)https 協(xié)議的工作原理
客戶端在使用 HTTPS 方式與 Web 服務器通信時有以下幾個步驟, 如圖所示。 客戶使用 https url 訪問服務器, 則要求web 服務器建立 ssl 鏈接。
web 服務器接收到客戶端的請求之后, 會將網(wǎng)站的證書 (證書中包含了公鑰) , 返回或 者說傳輸給客戶端。
客戶端和 web 服務器端開始協(xié)商 SSL 鏈接的安全等級, 也就是加密等級。
客戶端瀏覽器通過雙方協(xié)商一致的安全等級,建立會話密鑰,然后通過網(wǎng)站的公鑰來加 密會話密鑰, 并傳送給網(wǎng)站。
web 服務器通過自己的私鑰解密出會話密鑰。
web 服務器通過會話密鑰加密與客戶端之間的通信。
(4)https 協(xié)議的優(yōu)點
使用HTTPS 協(xié)議可認證用戶和服務器, 確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器;
HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構建的可進行加密傳輸 、身份認證的網(wǎng)絡協(xié)議, 要比 http 協(xié)議安全, 可防止數(shù)據(jù)在傳輸過程中不被竊取 、改變, 確保數(shù)據(jù)的完整性 。 HTTPS 是現(xiàn)行架構下最安全的解決方案,雖然不是絕對安全,但它大幅增加了中間人攻 擊的成本。
谷歌曾在 2014 年 8 月份調(diào)整搜索引擎算法, 并稱“比起同等 HTTP 網(wǎng)站, 采用 HTTPS 加密的網(wǎng)站在搜索結果中的排名將會更高”。
(5)https 協(xié)議的缺點
https 握手階段比較費時, 會使頁面加載時間延長 50%, 增加 10%~20%的耗電。
https 緩存不如 http 高效, 會增加數(shù)據(jù)開銷。
SSL 證書也需要錢, 功能越強大的證書費用越高。
SSL 證書需要綁定 IP, 不能再同一個 ip 上綁定多個域名, ipv4 資源支持不了這種消耗。
參考回答:
客戶端和服務端都需要直到各自可收發(fā), 因此需要三次握手。
簡化三次握手:
<img width="487" alt="2018-07-10 3 42 11" src="https://user-images.githubusercontent.com/ 17233651/42496289-1c6d668a-8458-11e8-98b3-65db50f64d48.png">
從圖片可以得到三次握手可以簡化為:C 發(fā)起請求連接 S 確認,也發(fā)起連接 C 確認我們 再看看每次握手的作用: 第一次握手: S 只可以確認 自己可以接受 C 發(fā)送的報文段第 二次握手: C 可以確認 S 收到了自己發(fā)送的報文段, 并且可以確認 自己可以接受 S 發(fā) 送的報文段第三次握手: S 可以確認 C 收到了自己發(fā)送的報文段。
參考回答:
( 1) TCP 是面向連接的, udp 是無連接的即發(fā)送數(shù)據(jù)前不需要先建立鏈接。
( 2) TCP 提供可靠的服務 。也就是說, 通過 TCP 連接傳送的數(shù)據(jù), 無差錯, 不丟失, 不重復, 且按序到達;UDP 盡最大努力交付, 即不保證可靠交付 。 并且因為 tcp 可靠, 面向連接, 不會丟失數(shù)據(jù)因此適合大數(shù)據(jù)量的交換。
( 3) TCP 是面向字節(jié)流,UDP 面向報文,并且網(wǎng)絡出現(xiàn)擁塞不會使得發(fā)送速率降低 (因 此會出現(xiàn)丟包, 對實時的應用比如 IP 電話和視頻會議等) 。
( 4) TCP 只能是 1 對 1 的, UDP 支持 1 對 1,1 對多。
( 5) TCP 的首部較大為 20 字節(jié), 而 UDP 只有 8 字節(jié)。
( 6) TCP 是面向連接的可靠性傳輸, 而 UDP 是不可靠的。
參考回答:
(1)什么是 WebSocket?
WebSocket 是 HTML5 中的協(xié)議, 支持持久連續(xù), http 協(xié)議不支持持久性連接 。Http1.0 和 HTTP1.1 都不支持持久性的鏈接, HTTP1.1 中的 keep-alive, 將多個 http 請求合并為 1 個
(2)WebSocket 是什么樣的協(xié)議, 具體有什么優(yōu)點?
HTTP 的生命周期通過 Request 來界定, 也就是 Request 一個 Response, 那么在 Http1.0 協(xié)議中, 這次 Http 請求就結束了 。在 Http1.1 中進行了改進, 是的有一個 connection: Keep-alive,也就是說,在一個 Http 連接中,可以發(fā)送多個 Request,接收多個 Response。 但是必須記住, 在 Http 中一個 Request 只能對應有一個 Response, 而且這個 Response 是被動的, 不能主動發(fā)起。
WebSocket 是基于 Http 協(xié)議的,或者說借用了 Http 協(xié)議來完成一部分握手,在握手階段 與 Http 是相同的。我們來看一個 websocket 握手協(xié)議的實現(xiàn),基本是 2 個屬性,upgrade, connection。
基本請求如下:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
多了下面 2 個屬性:
Upgrade:webSocket
Connection:Upgrade
告訴服務器發(fā)送的是websocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
參考回答:
head: 類似于 get 請求, 只不過返回的響應中沒有具體的內(nèi)容, 用戶獲取報頭 options: 允許客戶端查看服務器的性能, 比如說服務器支持的請求方式等等。
參考回答:
請求的返回頭里面, 用于瀏覽器解析的重要參數(shù)就是 OSS 的 API 文檔里面的返回http 頭, 決定用戶下載行為的參數(shù)。
下載的情況下:
x-oss-object-type: Normal
x-oss-request-id: 598D5ED34F29D01FE2925F41
x-oss-storage-class: Standard
參考回答:
能夠被殘障人士使用的網(wǎng)站才能稱得上一個易用的 (易訪問的) 網(wǎng)站。 殘障人士指的是那些帶有殘疾或者身體不健康的用戶。
使用 alt 屬性:
<img src="person.jpg" alt="this is a person"/>
有時候瀏覽器會無法顯示圖像 。具體的原因有:
用戶關閉了圖像顯示
瀏覽器是不支持圖形顯示的迷你瀏覽器
瀏覽器是語音瀏覽器 (供盲人和弱視人群使用)
如果您使用了alt 屬性, 那么瀏覽器至少可以顯示或讀出有關圖像的描述。
參考回答:
什么是 Bom? Bom 是瀏覽器對象 。有哪些常用的 Bom 屬性呢?
(1)location 對象
location.href-- 返回或設置當前文檔的 URL
location.search -- 返回 URL 中的查詢字符串部分 。 例
如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的內(nèi) 容?id=5&name=dreamdu
location.hash -- 返回 URL#后面的內(nèi)容, 如果沒有#, 返回空
location.host -- 返回 URL 中的域名部分, 例如 www.dreamdu.com
location.hostname -- 返回 URL 中的主域名部分, 例如 dreamdu.com
location.pathname -- 返回 URL 的域名后的部分 。例如 http://www.dreamdu.com/xhtml/ 返 回/xhtml/
location.port -- 返回 URL 中的端口部分 。 例如 http://www.dreamdu.com:8080/xhtml/ 返回8080
location.protocol -- 返回 URL 中的協(xié)議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返 回(//)前面的內(nèi)容 http:
location.assign -- 設置當前文檔的 URL
location.replace() -- 設置當前文檔的 URL, 并且在 history 對象的地址列表中移除這個 URL location.replace(url);
location.reload() -- 重載當前頁面
(2)history 對象
history.go() -- 前進或后退指定的頁面數(shù) history.go(num);
history.back() -- 后退一頁
history.forward() -- 前進一頁
(3)Navigator 對象
navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字 符串)。
navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie。
參考回答:
dragstart: 事件主體是被拖放元素, 在開始拖放被拖放元素時觸發(fā), 。
darg: 事件主體是被拖放元素, 在正在拖放被拖放元素時觸發(fā)。
dragenter: 事件主體是目標元素, 在被拖放元素進入某元素時觸發(fā)。
dragover: 事件主體是目標元素, 在被拖放在某元素內(nèi)移動時觸發(fā)。
dragleave: 事件主體是目標元素, 在被拖放元素移出目標元素是觸發(fā)。
drop: 事件主體是目標元素, 在目標元素完全接受被拖放元素時觸發(fā)。
dragend: 事件主體是被拖放元素, 在整個拖放操作結束時觸發(fā)。
參考回答:
首先補充一下, http 和 https 的區(qū)別, 相比于 http,https 是基于 ssl 加密的 http 協(xié)議
簡要概括: http2.0 是基于 1999 年發(fā)布的 http1.0 之后的首次更新。
提升訪問速度 (可以對于, 請求資源所需時間更少, 訪問速度更快, 相比 http1.0)
允許多路復用:多路復用允許同時通過單一的 HTTP/2 連接發(fā)送多重請求-響應信息。改 善了: 在 http1.1 中, 瀏覽器客戶端在同一時間, 針對同一域名下的請求有一定數(shù)量限 制 (連接數(shù)量) , 超過限制會被阻塞。
二進制分幀:HTTP2.0 會將所有的傳輸信息分割為更小的信息或者幀,并對他們進行二 進制編碼、首部壓縮、服務器端推送。
參考回答:
(1)400 狀態(tài)碼: 請求無效
產(chǎn)生原因:
前端提交數(shù)據(jù)的字段名稱和字段類型與后臺的實體沒有保持一致。
前端提交到后臺的數(shù)據(jù)應該是 json 字符串類型, 但是前端沒有將對象 JSON.stringify 轉化成字符串。
解決方法:
對照字段的名稱, 保持一致性,將 obj 對象通過 JSON.stringify 實現(xiàn)序列化。
(2)401 狀態(tài)碼: 當前請求需要用戶驗證
(3)403 狀態(tài)碼: 服務器已經(jīng)得到請求, 但是拒絕執(zhí)行
參考回答:
fetch 發(fā)送 post 請求的時候, 總是發(fā)送 2 次, 第一次狀態(tài)碼是 204, 第二次才成功?
原因很簡單, 因為你用 fetch 的 post 請求的時候, 導致 fetch 第一次發(fā)送了一個 Options 請求,詢問服務器是否支持修改的請求頭,如果服務器支持,則在第二次中發(fā)送真正的 請求。
參考回答:
在 HTML 頁面中,如果在執(zhí)行腳本時,頁面的狀態(tài)是不可相應的,直到腳本執(zhí)行完成后, 頁面才變成可相應 。web worker 是運行在后臺的 js, 獨立于其他腳本, 不會影響頁面你 的性能 。并且通過 postMessage 將結果回傳到主線程 。這樣在進行復雜操作的時候, 就 不會阻塞主線程了。
如何創(chuàng)建 web worker:
檢測瀏覽器對于 web worker 的支持性
創(chuàng)建 web worker 文件 (js, 回傳函數(shù)等)
創(chuàng)建 web worker 對象
參考回答:
HTML5 語義化標簽是指正確的標簽包含了正確的內(nèi)容,結構良好,便于閱讀, 比如nav 表示導航條, 類似的還有 article 、header 、footer 等等標簽。
參考回答:
定義: iframe 元素會創(chuàng)建包含另一個文檔的內(nèi)聯(lián)框架
提示: 可以將提示文字放在<iframe></iframe>之間, 來提示某些不支持 iframe 的瀏覽器 缺點: 會阻塞主頁面的 onload 事件 搜索引擎無法解讀這種頁面, 不利于 SEO iframe 和主頁面共享連接池, 而瀏覽器對相同區(qū)域有限制所以會影響性能。
參考回答:
Doctype 聲明于文檔最前面, 告訴瀏覽器以何種方式來渲染頁面, 這里有兩種模式, 嚴 格模式和混雜模式。
嚴格模式的排版和 JS 運作模式是 以該瀏覽器支持的最高標準運行。
混雜模式, 向后兼容, 模擬老式瀏覽器, 防止瀏覽器無法兼容頁面。
參考回答:
XSS (跨站腳本攻擊) 是指攻擊者在返回的 HTML 中嵌入 javascript 腳本,為了減輕這些 攻擊, 需要在 HTTP 頭部配上, set-cookie:
httponly-這個屬性可以防止 XSS,它會禁止 javascript 腳本來訪問 cookie。
secure - 這個屬性告訴瀏覽器僅在請求為 https 的時候發(fā)送 cookie。
結果應該是這樣的: Set-Cookie=<cookie-value>.....
參考回答:
就是用URL 定位資源, 用 HTTP 描述操作。
參考回答:
可以參考這篇文章:
響應式布局的常用解決方案對比(媒體查詢、百分比、rem 和 vw/vh)
參考回答:
(1)粗暴型, 禁用縮放
<meta name="viewport" content="width=device-width, user-scalable=no">
(2)利用 FastClick, 其原理是:
檢測到 touchend 事件后, 立刻出發(fā)模擬 click 事件, 并且把瀏覽器 300 毫秒之后真正出 發(fā)的事件給阻斷掉。
參考回答:
addEventListener(event, function, useCapture)
其中, event 指定事件名; function 指定要事件觸發(fā)時執(zhí)行的函數(shù); useCapture 指定事件 是否在捕獲或冒泡階段執(zhí)行。
參考回答:
100 Continue 繼續(xù) 。客戶端應繼續(xù)其請求。
101 Switching Protocols 切換協(xié)議。服務器根據(jù)客戶端的請求切換協(xié)議。只能切換到更 高級的協(xié)議, 例如, 切換到HTTP 的新版本協(xié)議。
200 OK 請求成功 。一般用于 GET 與 POST 請求。
201 Created 已創(chuàng)建 。成功請求并創(chuàng)建了新的資源。
202 Accepted 已接受 。 已經(jīng)接受請求, 但未處理完成。
203 Non-Authoritative Information 非授權信息。請求成功。但返回的 meta 信息不在原 始的服務器, 而是一個副本。
204 No Content 無內(nèi)容 。服務器成功處理, 但未返回內(nèi)容 。在未更新網(wǎng)頁的情況下, 可確保瀏覽器繼續(xù)顯示當前文檔。
205 Reset Content 重置內(nèi)容。服務器處理成功, 用戶終端 (例如: 瀏覽器) 應重置文 檔視圖 。可通過此返回碼清除瀏覽器的表單域。
206 Partial Content 部分內(nèi)容 。服務器成功處理了部分 GET 請求。
300 Multiple Choices 多種選擇。請求的資源可包括多個位置,相應可返回一個資源特 征與地址的列表用于用戶終端 (例如: 瀏覽器) 選擇。
301 Moved Permanently 永久移動。請求的資源已被永久的移動到新 URI,返回信息會 包括新的 URI,瀏覽器會自動定向到新 URI。今后任何新的請求都應使用新的 URI 代替。
302 Found 臨時移動。與 301 類似。但資源只是臨時被移動。客戶端應繼續(xù)使用原有 URI。
303 See Other 查看其它地址 。與 301 類似 。使用 GET 和 POST 請求查看。
304 Not Modified 未修改 。所請求的資源未修改, 服務器返回此狀態(tài)碼時, 不會返回 任何資源。客戶端通常會緩存訪問過的資源,通過提供一個頭信息指出客戶端希望只返 回在指定日期之后修改的資源。
305 Use Proxy 使用代理 。所請求的資源必須通過代理訪問。
306 Unused 已經(jīng)被廢棄的 HTTP 狀態(tài)碼。
307 Temporary Redirect 臨時重定向 。與 302 類似 。使用 GET 請求重定向。
400 Bad Request 客戶端請求的語法錯誤, 服務器無法理解。
401 Unauthorized 請求要求用戶的身份認證。
402 Payment Required 保留, 將來使用。
403 Forbidden 服務器理解請求客戶端的請求, 但是拒絕執(zhí)行此請求。
404 Not Found 服務器無法根據(jù)客戶端的請求找到資源 (網(wǎng)頁) 。通過此代碼, 網(wǎng)站 設計人員可設置"您所請求的資源無法找到"的個性頁面。
405 Method Not Allowed 客戶端請求中的方法被禁止。
406 Not Acceptable 服務器無法根據(jù)客戶端請求的內(nèi)容特性完成請求。
407 Proxy Authentication Required 請求要求代理的身份認證, 與 401 類似, 但請求者 應當使用代理進行授權。
408 Request Time-out 服務器等待客戶端發(fā)送的請求時間過長, 超時。
409 Conflict 服務器完成客戶端的 PUT 請求是可能返回此代碼,服務器處理請求時發(fā) 生了沖突。
410 Gone 客戶端請求的資源已經(jīng)不存在。410 不同于 404,如果資源以前有現(xiàn)在被永 久刪除了可使用410 代碼, 網(wǎng)站設計人員可通過 301 代碼指定資源的新位置。
411 Length Required 服務器無法處理客戶端發(fā)送的不帶 Content-Length 的請求信息。
412 Precondition Failed 客戶端請求信息的先決條件錯誤。
413 Request Entity Too Large 由于請求的實體過大,服務器無法處理, 因此拒絕請求。 為防止客戶端的連續(xù)請求,服務器可能會關閉連接。如果只是服務器暫時無法處理,則 會包含一個 Retry-After 的響應信息。
414 Request-URI Too Large 請求的 URI 過長 ( URI 通常為網(wǎng)址) , 服務器無法處理。
415 Unsupported Media Type 服務器無法處理請求附帶的媒體格式。
416 Requested range not satisfiable 客戶端請求的范圍無效。
417 Expectation Failed 服務器無法滿足 Expect 的請求頭信息。
500 Internal Server Error 服務器內(nèi)部錯誤, 無法完成請求。
501 Not Implemented 服務器不支持請求的功能, 無法完成請求。
502 Bad Gateway 作為網(wǎng)關或者代理工作的服務器嘗試執(zhí)行請求時, 從遠程服務器接 收到了一個無效的響應。
503 Service Unavailable 由于超載或系統(tǒng)維護,服務器暫時的無法處理客戶端的請求。 延時的長度可包含在服務器的 Retry-After 頭信息中。
504 Gateway Time-out 充當網(wǎng)關或代理的服務器, 未及時從遠端服務器獲取請求。
505 HTTP Version not supported 服務器不支持請求的 HTTP 協(xié)議的版本, 無法完成處 理。
參考回答:
協(xié)議頭 | 說明 |
Accept | 可接受的響應內(nèi)容類型 (Content-Types) 。 |
Accept-Charset | 可接受的字符集。 |
Accept-Encoding | 可接受的響應內(nèi)容的編碼方式。 |
Accept-Language | 可接受的響應內(nèi)容語言列表。 |
Accept-Datetime | 可接受的按照時間來表示的響應內(nèi)容版本。 |
Authorization | 用于表示 HTTP 協(xié)議中需要認證資源的認證信息。 |
Cache-Control | 用來指定當前的請求/回復中的, 是否使用緩存機制。 |
Connection | 客戶端 (瀏覽器) 想要優(yōu)先使用的連接類型。 |
Cookie | 由之前服務器通過 Set-Cookie(見下文)設置的一個 HTTP 協(xié)議 Cookie。 |
Content-Length | 以 8 進制表示的請求體的長度。 |
Content-MD5 | 請求體的內(nèi)容的二進制 MD5 散列值 (數(shù)字簽名) , 以 Base64 編碼的結果。 |
Content-Type | 請求體的 MIME 類型 (用于 POST 和 PUT 請求中)。 |
Date | 發(fā)送該消息的日期和時間 (以RFC 7231中定義的"HTTP 日期"格式 來發(fā)送)。 |
Expect | 表示客戶端要求服務器做出特定的行為。 |
From | 發(fā)起此請求的用戶的郵件地址。 |
Host | 表示服務器的域名以及服務器所監(jiān)聽的端口號 。如果所請求的端口 是對應的服務的標準端口 ( 80) , 則端口號可以省略。 |
If-Match | 僅當客戶端提供的實體與服務器上對應的實體相匹配時, 才進行對應的操作 。主要用于像 PUT 這樣的方法中, 僅當從用戶上次更新 某個資源后, 該資源未被修改的情況下, 才更新該資源。 |
If-Modified-Since | 允許在對應的資源未被修改的情況下返回304 未修改 |
If-None-Match | 允許在對應的內(nèi)容未被修改的情況下返回304 未修改 ( 304 Not Modified ) , 參考 超文本傳輸協(xié)議 的實體標記 |
If-Range | 如果該實體未被修改過, 則向返回所缺少的那一個或多個部分 。否 則, 返回整個新的實體。 |
If-Unmodified-Since | 僅當該實體自某個特定時間以來未被修改的情況下, 才發(fā)送回應。 |
Max-Forwards | 限制該消息可被代理及網(wǎng)關轉發(fā)的次數(shù)。 |
Origin | 發(fā)起一個針對跨域資源共享的請求 (該請求要求服務器在響應中加入一個 Access-Control-Allow-Origin 的消息頭,表示訪問控制所允許 的來源) 。 |
Pragma | 與具體的實現(xiàn)相關, 這些字段可能在請求/回應鏈中的任何時候產(chǎn) 生。 |
Proxy-Authorization | 用于向代理進行認證的認證信息。 |
Range | 表示請求某個實體的一部分, 字節(jié)偏移以 0 開始。 |
Referer | 表示瀏覽器所訪問的前一個頁面, 可以認為是之前訪問頁面的鏈接將瀏覽器帶到了當前頁面。Referer 其實是 Referrer 這個單詞,但 RFC 制作標準時給拼錯了, 后來也就將錯就錯使用 Referer 了。 |
TE | 瀏覽器預期接受的傳輸時的編碼方式: 可使用回應協(xié)議頭 Transfer-Encoding 中的值 (還可以使用"trailers"表示數(shù)據(jù)傳輸時的分 塊方式) 用來表示瀏覽器希望在最后一個大小為 0 的塊之后還接收到一些額外的字段。 |
User-Agent | 瀏覽器的身份標識字符串。 |
Upgrade | 要求服務器升級到一個高版本協(xié)議。 |
Via | 告訴服務器, 這個請求是由哪些代理發(fā)出的。 |
Warning | 一個一般性的警告, 表示在實體內(nèi)容體中可能存在錯誤。 |
參考回答:
緩存分為兩種: 強緩存和協(xié)商緩存, 根據(jù)響應的header 內(nèi)容來決定。
獲取資源形式 | 狀態(tài)碼 | 發(fā)送請求到服務器 | |
強緩存 | 從緩存取 | 200 (from cache) | 否, 直接從緩存取 |
協(xié)商緩存 | 從緩存取 | 304 (not modified) | 是,通過服務器來告知緩存是否可 用 |
強緩存相關字段有 expires, cache-control 。如果 cache-control 與 expires 同時存在的話, cache-control 的優(yōu)先級高于 expires。
協(xié)商緩存相關字段有 Last-Modified/If-Modified-Since, Etag/If-None-Match。
參考回答:
304:如果客戶端發(fā)送了一個帶條件的 GET 請求且該請求已被允許,而文檔的內(nèi)容 (自 上次訪問以來或者根據(jù)請求的條件) 并沒有改變, 則服務器應當返回這個 304 狀態(tài)碼。
參考回答:
因為服務器上的資源不是一直固定不變的,大多數(shù)情況下它會更新,這個時候如果我們 還訪問本地緩存,那么對用戶來說,那就相當于資源沒有更新,用戶看到的還是舊的資 源;所以我們希望服務器上的資源更新了瀏覽器就請求新的資源,沒有更新就使用本地 的緩存, 以最大程度的減少因網(wǎng)絡請求而產(chǎn)生的資源浪費。
參考 https://segmentfault.com/a/1190000008956069
參考回答:
降低請求量: 合并資源, 減少 HTTP 請求數(shù), minify / gzip 壓縮, webP, lazyLoad。
加快請求速度: 預解析 DNS, 減少域名數(shù), 并行加載, CDN 分發(fā)。
緩存: HTTP 協(xié)議緩存請求, 離線緩存 manifest, 離線數(shù)據(jù)緩存 localStorage。
渲染: JS/CSS 優(yōu)化, 加載順序, 服務端渲染, pipeline。
*請認真填寫需求信息,我們會在24小時內(nèi)與您取得聯(lián)系。