Dino Esposito: การพัฒนาเว็บแอปพลิเคชันสมัยใหม่ การวิเคราะห์สาขาวิชาและเทคโนโลยี อย่าทำลายประวัติศาสตร์ ปรับปรุงมัน การทดสอบและการทดลองใช้งาน

ล่าสุดเนื่องมาจาก UX และประสิทธิภาพการทำงานเป็นหลัก

ฉันต้องการนำเสนอหลักการที่สามารถนำไปปฏิบัติได้ 7 ข้อสำหรับเว็บไซต์ที่ต้องการใช้ JavaScript เพื่อควบคุม UI หลักการเหล่านี้เป็นผลมาจากการทำงานของฉันในฐานะนักออกแบบเว็บไซต์ แต่ยังเป็นผู้ใช้ WWW มาเป็นเวลานานด้วย

ไม่ต้องสงสัยเลยว่า JavaScript ได้กลายเป็นเครื่องมือที่ขาดไม่ได้สำหรับนักพัฒนาส่วนหน้า ขณะนี้ขอบเขตกำลังขยายไปยังพื้นที่อื่นๆ เช่น เซิร์ฟเวอร์และไมโครคอนโทรลเลอร์ ภาษาการเขียนโปรแกรมนี้ได้รับเลือกจากมหาวิทยาลัยที่มีชื่อเสียงเพื่อสอนนักศึกษาเกี่ยวกับพื้นฐานของวิทยาการคอมพิวเตอร์

ในขณะเดียวกันก็มีคำถามมากมายเกี่ยวกับบทบาทและ การใช้งานเฉพาะซึ่งหลายคนพบว่าตอบยาก รวมถึงผู้เขียนเฟรมเวิร์กและไลบรารีด้วย

ควรใช้ JavaScript แทนฟังก์ชั่นเบราว์เซอร์: ประวัติ, การนำทาง, การเรนเดอร์หรือไม่
แบ็คเอนด์กำลังจะตายเหรอ? จำเป็นต้องเรนเดอร์ HTML เลยหรือไม่?
จริงหรือไม่ที่ Single Page Applications (SPAs) คืออนาคต?
JS ควรสร้างเพจบนเว็บไซต์และเรนเดอร์เพจในเว็บแอปพลิเคชันหรือไม่
ฉันควรใช้เทคนิคเช่น PJAX หรือ TurboLinks หรือไม่
อะไรคือความแตกต่างที่แท้จริงระหว่างเว็บไซต์และเว็บแอปพลิเคชัน? ควรจะมีสิ่งหนึ่งเหลืออยู่หรือไม่?

1. การแสดงผลเพจบนเซิร์ฟเวอร์เป็นทางเลือก

tl; DR: การเรนเดอร์เซิร์ฟเวอร์ไม่ได้ทำเพื่อ SEO แต่เพื่อประสิทธิภาพ พิจารณาคำขอเพิ่มเติมสำหรับสคริปต์ สไตล์ และคำขอ API ที่ตามมา ในอนาคตคำนึงถึงการใช้งานด้วย วิธีการ HTTP 2.0 ดัน

ก่อนอื่น ฉันต้องชี้ให้เห็นข้อผิดพลาดทั่วไปของการแยก “แอปพลิเคชันที่แสดงผลบนเซิร์ฟเวอร์” ออกจาก “แอปพลิเคชันหน้าเดียว” หากเราต้องการบรรลุประสบการณ์ที่ดีที่สุดจากมุมมองของผู้ใช้ เราต้องไม่จำกัดตัวเองอยู่แค่ขีดจำกัดดังกล่าว และละทิ้งทางเลือกหนึ่งเพื่อประโยชน์ของอีกทางเลือกหนึ่ง

เหตุผลค่อนข้างชัดเจน หน้าต่างๆ ถูกส่งผ่านอินเทอร์เน็ต ซึ่งมีข้อจำกัดทางกายภาพ ดังที่ Stuart Cheshire แสดงให้เห็นอย่างน่าจดจำในบทความชื่อดังเรื่อง "It's Latency, Fool":

สามารถปรับปรุงผลลัพธ์ที่ระบุของ 85 ms ได้ (และดีขึ้นเล็กน้อยแล้ว) แต่สิ่งสำคัญคือต้องเข้าใจว่ามีขีดจำกัดทางกายภาพเกี่ยวกับความล่าช้าในการส่งข้อมูลผ่านอินเทอร์เน็ตไม่ว่าแบนด์วิดท์บนคอมพิวเตอร์ของผู้ใช้จะเพิ่มขึ้นเท่าใด .

นี่เป็นสิ่งสำคัญอย่างยิ่งกับความนิยมที่เพิ่มขึ้นของแอปพลิเคชัน JavaScript ซึ่งโดยทั่วไปจะมีเพียงมาร์กอัปและช่องว่างถัดจากนั้น แอปพลิเคชันหน้าเดียว (SPA) ที่เรียกว่า - เซิร์ฟเวอร์ส่งคืนหนึ่งหน้าและทุกอย่างถูกเรียกด้วยโค้ดในฝั่งไคลเอ็นต์

ลองนึกภาพสถานการณ์ที่ผู้ใช้เข้าถึง http://app.com/orders/ โดยตรง เมื่อใบสมัครของคุณได้รับและดำเนินการตามคำขอนี้ ก็ถือว่ามีความสำคัญอยู่แล้ว ข้อมูลเกี่ยวกับสิ่งที่ต้องแสดงบนหน้า ตัวอย่างเช่น สามารถโหลดคำสั่งซื้อจากฐานข้อมูลและเพิ่มลงในการตอบกลับได้ แต่สปาส่วนใหญ่ในสถานการณ์นี้ส่งคืนหน้าว่างและแท็ก จากนั้นคุณจะต้องแลกเปลี่ยนคำขออีกครั้งเพื่อรับเนื้อหาของสคริปต์ และอีกครั้งเพื่อรับเนื้อหา

แยกวิเคราะห์ HTML ที่ส่งโดยเซิร์ฟเวอร์สำหรับแต่ละหน้า SPA

นักพัฒนาหลายคนตั้งใจที่จะเสียสละเช่นนี้ พวกเขาพยายามให้แน่ใจว่าเครือข่ายเพิ่มเติมนั้น กระโดดจะเกิดขึ้นเพียงครั้งเดียวสำหรับผู้ใช้ โดยส่งส่วนหัวที่ถูกต้องเพื่อแคชในการตอบกลับด้วยสคริปต์และ CSS ภูมิปัญญาดั้งเดิมก็คือ นี่เป็นข้อเสนอที่ดี เพราะเมื่อดาวน์โหลดไฟล์ทั้งหมดลงคอมพิวเตอร์แล้ว การกระทำส่วนใหญ่ของผู้ใช้ (เช่น การนำทางไปยังส่วนอื่นๆ) จะเกิดขึ้นโดยไม่ต้องใช้หน้าหรือสคริปต์เพิ่มเติม

อย่างไรก็ตามแม้จะคำนึงถึงแคชแล้ว แต่ก็ยังมีการสูญเสียประสิทธิภาพอยู่บ้างหากเราคำนึงถึงเวลาในการแยกวิเคราะห์และการดำเนินการสคริปต์ ในบทความ “jQuery ใหญ่เกินไปสำหรับมือถือหรือเปล่า” มันบอกว่า jQuery เพียงอย่างเดียวสามารถทำให้ช้าลงได้อย่างไร เบราว์เซอร์มือถือเป็นเวลาหลายร้อยมิลลิวินาที

ที่แย่ไปกว่านั้นคือ ผู้ใช้มักจะไม่ได้รับข้อเสนอแนะใด ๆ ในขณะที่สคริปต์กำลังโหลด ผลลัพธ์คือหน้าว่างบนหน้าจอ ซึ่งจู่ๆ ก็กลายเป็นหน้าที่โหลดเต็ม

สิ่งสำคัญที่สุดคือ เรามักจะลืมไปว่าการขนส่งข้อมูลทางอินเทอร์เน็ต (TCP) ที่พบบ่อยที่สุดเริ่มต้นได้ช้า สิ่งนี้เกือบจะรับประกันได้ว่าชุดสคริปต์ส่วนใหญ่จะไม่ถูกถ่ายโอนในคราวเดียว ทำให้สถานการณ์ข้างต้นแย่ลงไปอีก

การเชื่อมต่อ TCP เริ่มต้นด้วยการแลกเปลี่ยนแพ็คเก็ตการจับมือกัน หากคุณใช้ SSL ซึ่งเป็นสิ่งสำคัญสำหรับการถ่ายโอนสคริปต์ที่ปลอดภัย จะมีการแลกเปลี่ยนแพ็กเก็ตเพิ่มเติมสองรายการ (หนึ่งรายการหากไคลเอ็นต์กู้คืนเซสชัน) หลังจากนี้เซิร์ฟเวอร์จะสามารถเริ่มส่งข้อมูลได้ แต่ในทางปฏิบัติแสดงให้เห็นว่าเซิร์ฟเวอร์ดำเนินการช้าและเป็นชุด

มีกลไกควบคุมความแออัดที่เรียกว่า Slow Start อยู่ภายใน โปรโตคอล TCPเพื่อส่งข้อมูลค่อย ๆ เพิ่มจำนวน เซ็กเมนต์- สิ่งนี้มีผลกระทบร้ายแรงสองประการสำหรับ SPA:

1. สคริปต์ขนาดใหญ่ใช้เวลาโหลดนานกว่าที่เห็นมาก ตามที่อธิบายไว้ในหนังสือ "High Performance Browser Networking" โดย Ilya Grigorik ต้องใช้ "การแลกเปลี่ยนแพ็กเก็ตสี่ครั้ง (...) และเวลาในการตอบสนองหลายร้อยมิลลิวินาทีเพื่อเข้าถึงการแลกเปลี่ยนข้อมูล 64 KB ระหว่างไคลเอนต์และเซิร์ฟเวอร์" ตัวอย่างเช่น ในกรณีของการเชื่อมต่ออินเทอร์เน็ตที่รวดเร็วระหว่างลอนดอนและนิวยอร์ก จะใช้เวลา 225 มิลลิวินาทีก่อนที่ TCP จะเข้าถึงได้ ขนาดสูงสุดบรรจุุภัณฑ์.

2. เนื่องจากกฎนี้ยังใช้กับการโหลดหน้าเริ่มต้นด้วย จึงเป็นสิ่งสำคัญมากว่าเนื้อหาใดจะถูกโหลดมาแสดงผลบนหน้าก่อน ตามที่ Paul Irish สรุปในการนำเสนอของเขาเรื่อง Delivering Goods 14 KB แรกถือเป็นเรื่องสำคัญ สิ่งนี้ชัดเจนหากคุณดูกราฟที่ระบุปริมาณการถ่ายโอนระหว่างไคลเอนต์และเซิร์ฟเวอร์ในระหว่างขั้นตอนแรกของการสร้างการเชื่อมต่อ

เซิร์ฟเวอร์สามารถส่งได้กี่ KB ในแต่ละขั้นตอนการเชื่อมต่อ ตามเซ็กเมนต์

เว็บไซต์ที่จัดการเพื่อส่งเนื้อหา (แม้แต่มาร์กอัปพื้นฐานที่ไม่มีข้อมูล) ในหน้าต่างนี้จะปรากฏตอบสนองเป็นพิเศษ อันที่จริงผู้เขียนเรื่องเร็วหลายคน แอปพลิเคชันเซิร์ฟเวอร์มองว่า JavaScript เป็นสิ่งที่ไม่จำเป็นหรือใช้ด้วยความระมัดระวังเป็นอย่างยิ่ง ทัศนคตินี้จะแข็งแกร่งยิ่งขึ้นหากแอปพลิเคชันมีแบ็กเอนด์และฐานข้อมูลที่รวดเร็ว และเซิร์ฟเวอร์ตั้งอยู่ใกล้กับผู้ใช้ (CDN)

บทบาทของเซิร์ฟเวอร์ในการเร่งการนำเสนอเนื้อหาขึ้นอยู่กับเว็บแอปพลิเคชันโดยตรง วิธีแก้ปัญหาไม่ได้จำกัดอยู่ที่ "แสดงผลทั้งหน้าบนเซิร์ฟเวอร์" เสมอไป

ในบางกรณี เป็นการดีกว่าที่จะแยกส่วนของเพจที่ไม่เกี่ยวข้องกับผู้ใช้ในปัจจุบันออกจากการตอบกลับครั้งแรกและทิ้งไว้ในภายหลัง ตัวอย่างเช่น แอปพลิเคชันบางตัวต้องการแสดงผลเฉพาะ "แกนกลาง" ของเพจเพื่อให้แน่ใจว่าจะตอบสนองได้ในทันที จากนั้นพวกเขาจะขอส่วนต่างๆ ของหน้าพร้อมกัน สิ่งนี้ให้การตอบสนองที่ดีกว่าแม้ในสถานการณ์ที่แบ็กเอนด์แบบเดิมช้า สำหรับบางเพจ การแสดงเฉพาะส่วนที่มองเห็นได้ของเพจอาจเป็นตัวเลือกที่ดี

สำคัญมาก ๆ การประเมินเชิงคุณภาพสคริปต์และสไตล์ โดยคำนึงถึงข้อมูลที่เซิร์ฟเวอร์มีเกี่ยวกับเซสชัน ไคลเอนต์ และ URL สคริปต์ที่เรียงลำดับจะมีความสำคัญต่อ /orders มากกว่าตรรกะของหน้าการตั้งค่าอย่างเห็นได้ชัด อาจจะไม่ชัดนักแต่ก็มีความแตกต่างในการโหลด” CSS โครงสร้าง" และ "CSS สำหรับจัดแต่งทรงผม" อันแรกอาจจำเป็นสำหรับโค้ด JavaScript ดังนั้นจึงจำเป็น การปิดกั้นและอันที่สองถูกโหลดแบบอะซิงโครนัส

ตัวอย่างที่ดีของ SPA ที่ไม่ส่งผลให้เกิดการแลกเปลี่ยนแพ็กเก็ตที่ไม่จำเป็นคือโคลนแนวคิด StackOverflow ขนาด 4096 ไบต์ ซึ่งในทางทฤษฎีสามารถโหลดด้วยแพ็กเก็ตแรกหลังจากการจับมือกันในการเชื่อมต่อ TCP! ผู้เขียนจัดการเพื่อให้บรรลุเป้าหมายนี้โดยการปฏิเสธการแคช โดยใช้อินไลน์สำหรับทรัพยากรทั้งหมดในการตอบสนองจากเซิร์ฟเวอร์ โดยการใช้การพุชเซิร์ฟเวอร์ SPDY หรือ HTTP/2 เป็นไปได้ในทางทฤษฎีในการถ่ายโอนรหัสไคลเอ็นต์ที่แคชไว้ทั้งหมดในการกระโดดครั้งเดียว ในปัจจุบัน การเรนเดอร์บางส่วนหรือทั้งหน้าบนฝั่งเซิร์ฟเวอร์ยังคงเป็นวิธีที่ได้รับความนิยมมากที่สุดในการกำจัดการแลกเปลี่ยนแพ็กเก็ตที่ไม่จำเป็น

SPA แบบพิสูจน์แนวคิดโดยใช้อินไลน์สำหรับ CSS และ JS เพื่อกำจัดการไปกลับที่ไม่จำเป็น

ระบบที่ค่อนข้างยืดหยุ่นซึ่งแยกการเรนเดอร์ระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ และจัดเตรียมเครื่องมือสำหรับการโหลดสคริปต์และสไตล์แบบค่อยเป็นค่อยไปอาจทำให้เส้นแบ่งระหว่าง เว็บไซต์และ แอปพลิเคชันเว็บ- ทั้งใช้ URL การนำทาง และแสดงข้อมูลแก่ผู้ใช้ แม้กระทั่งแอพพลิเคชั่นด้วย สเปรดชีตซึ่งแต่เดิมต้องใช้ฟังก์ชันฝั่งไคลเอ็นต์ จะต้องแสดงข้อมูลที่จำเป็นต้องแก้ไขแก่ลูกค้าก่อน และการทำเช่นนี้ในจำนวนเที่ยวไปกลับน้อยที่สุดก็มีความสำคัญอย่างยิ่ง

จากมุมมองของฉัน ข้อบกพร่องด้านประสิทธิภาพที่ใหญ่ที่สุดในหลาย ๆ ด้าน ระบบยอดนิยมในยุคปัจจุบันอธิบายได้จากการสะสมความซับซ้อนในสแต็กที่ก้าวหน้า เมื่อเวลาผ่านไป เทคโนโลยีอย่าง JavaScript และ CSS ได้ถูกเพิ่มเข้ามา ความนิยมของพวกเขาก็ค่อยๆเพิ่มขึ้นเช่นกัน ตอนนี้เท่านั้นที่เราจะซาบซึ้งว่าสามารถใช้แตกต่างกันได้อย่างไร เรากำลังพูดถึงการปรับปรุงโปรโตคอลด้วย (ซึ่งแสดงโดยความคืบหน้าในปัจจุบันของ SPDY และ QUIC) แต่ประโยชน์สูงสุดมาจากการเพิ่มประสิทธิภาพแอปพลิเคชัน

อาจเป็นประโยชน์ในการระลึกถึงการอภิปรายทางประวัติศาสตร์บางส่วนเกี่ยวกับการออกแบบ รุ่นก่อนหน้า HTML และ WWW ตัวอย่างเช่น รายชื่ออีเมลนี้ตั้งแต่ปี 1997 แนะนำให้เพิ่มแท็ก ในรูปแบบ HTML Marc Andreessen ย้ำถึงความสำคัญของการส่งข้อมูลอย่างรวดเร็ว:

2. ตอบสนองต่อการกระทำของผู้ใช้ทันที

tl; DR: JavaScript ช่วยให้คุณสามารถซ่อนเวลาแฝงของเครือข่ายได้ทั้งหมด การใช้สิ่งนี้เป็นหลักการออกแบบ เราสามารถลบตัวบ่งชี้การโหลดและข้อความ "กำลังโหลด" เกือบทั้งหมดออกจากแอปพลิเคชันได้ PJAX หรือ TurboLinks ขาดโอกาสในการเพิ่มความเร็วอินเทอร์เฟซแบบอัตนัย

หน้าที่ของเราคือเพิ่มความเร็วในการตอบสนองต่อการกระทำของผู้ใช้ให้สูงสุด ไม่ว่าเราจะใช้ความพยายามมากเพียงใดในการลดจำนวนการกระโดดเมื่อทำงานกับเว็บแอปพลิเคชัน ยังมีสิ่งต่าง ๆ ที่อยู่นอกเหนือการควบคุมของเรา นี่คือขีดจำกัดทางทฤษฎีของความเร็วแสงและค่า ping ขั้นต่ำระหว่างไคลเอนต์และเซิร์ฟเวอร์

ปัจจัยสำคัญคือคุณภาพการสื่อสารที่ไม่สามารถคาดเดาได้ระหว่างไคลเอนต์และเซิร์ฟเวอร์ หากคุณภาพการเชื่อมต่อไม่ดีแสดงว่า การส่งสัญญาณซ้ำแพคเกจ ในกรณีที่ต้องโหลดเนื้อหาแบบไปกลับ 2-3 ครั้ง คุณอาจต้องการเนื้อหามากกว่านี้มาก

นี่คือประโยชน์หลักของ JavaScript สำหรับการปรับปรุง UX หากอินเทอร์เฟซถูกเขียนสคริปต์บนฝั่งไคลเอ็นต์ เราสามารถซ่อนเวลาแฝงของเครือข่ายได้ เราสามารถสร้างความประทับใจในความเร็วสูงได้ เราสามารถบรรลุเวลาแฝงเป็นศูนย์ได้โดยไม่ได้ตั้งใจ

สมมติว่าอยู่ตรงหน้าเราอีกครั้ง HTML ธรรมดา- เอกสารเชื่อมต่อกันด้วยไฮเปอร์ลิงก์หรือแท็ก - หากคุณคลิกที่รายการใดรายการหนึ่ง เบราว์เซอร์จะส่งคำขอเครือข่ายซึ่งใช้เวลานานอย่างไม่อาจคาดเดาได้ จากนั้นรับและประมวลผลข้อมูลที่ได้รับและเข้าสู่สถานะใหม่ในที่สุด

JavaScript ช่วยให้คุณตอบสนองต่อการกระทำของผู้ใช้ได้ทันทีและในแง่ดี การคลิกลิงก์หรือปุ่มจะทำให้ได้รับการตอบสนองทันทีโดยไม่ต้องต่ออินเทอร์เน็ต ตัวอย่างที่รู้จักกันดีคืออินเทอร์เฟซ Gmail (หรือ Google Inbox) ซึ่งการเก็บถาวรข้อความอีเมลจะเกิดขึ้นทันที ในขณะที่คำขอที่เกี่ยวข้องไปยังเซิร์ฟเวอร์จะถูกส่งและประมวลผลแบบอะซิงโครนัส

ในกรณีของแบบฟอร์ม แทนที่จะรอโค้ด HTML เพื่อตอบกลับการกรอก เราสามารถตอบกลับได้ทันทีที่ผู้ใช้กด “Enter” หรือดียิ่งขึ้น เช่นเดียวกับการค้นหาของ Google เราสามารถตอบสนองได้เร็วยิ่งขึ้นด้วยการเตรียมมาร์กอัปสำหรับหน้าใหม่ล่วงหน้า

พฤติกรรมนี้เป็นตัวอย่างของสิ่งที่ฉันเรียกว่า การปรับมาร์กอัป- แนวคิดพื้นฐานคือหน้าเว็บ "รู้" มาร์กอัปในอนาคต ดังนั้นจึงสามารถเปลี่ยนไปใช้หน้าดังกล่าวได้เมื่อยังไม่มีข้อมูลที่จะระบุ นี่เป็นพฤติกรรม "ในแง่ดี" เนื่องจากยังคงมีความเสี่ยงที่ข้อมูลจะไม่มาถึงและจะต้องรายงานข้อความแสดงข้อผิดพลาด แต่สิ่งนี้เกิดขึ้นได้ยากอย่างเห็นได้ชัด

หน้าแรกของ Google เป็นตัวอย่างที่ดีเพราะแสดงให้เห็นหลักการสองข้อแรกจากบทความของเราอย่างชัดเจน

ปลายปี พ.ศ. 2547 Google กลายเป็นผู้บุกเบิกด้าน โดยใช้จาวาสคริปต์เพื่อให้คำแนะนำแบบเรียลไทม์ขณะพิมพ์ การค้นหา(ที่น่าสนใจคือพนักงานพัฒนาฟังก์ชันนี้โดยใช้เวลา 20% เป็นอิสระจากงานหลัก เช่นเดียวกับ Gmail) สิ่งนี้กลายเป็นพื้นฐานสำหรับการเกิดขึ้นของ Ajax:

การดำเนินการอีกประเภทหนึ่งนอกเหนือจากการคลิกและการส่งแบบฟอร์มที่ได้รับการปรับปรุงอย่างมากด้วย JavaScript คือการแสดงการอัปโหลดไฟล์

เราสามารถบันทึกความพยายามของผู้ใช้ในการดาวน์โหลดไฟล์ได้ วิธีทางที่แตกต่าง: ลากและวาง วางจากคลิปบอร์ด เลือกไฟล์ จากนั้น ต้องขอบคุณ HTML5 API ใหม่ที่ทำให้เราสามารถแสดงเนื้อหาราวกับว่ามันถูกดาวน์โหลดไปแล้ว ตัวอย่างของอินเทอร์เฟซประเภทนี้คืองานของเรากับการดาวน์โหลดใน Cloudup สังเกตว่าภาพขนาดย่อของรูปภาพถูกสร้างขึ้นและแสดงผลอย่างไรในทันที:

รูปภาพจะถูกเรนเดอร์และแสดงจนกว่าการโหลดจะเสร็จสิ้น

ในทุกกรณีเหล่านี้เราปรับปรุง การรับรู้ความเร็ว- โชคดีที่มีหลักฐานมากมายที่แสดงถึงประโยชน์ของแนวทางนี้ อย่างน้อยก็ยกตัวอย่างวิธีการ เพิ่มขึ้นระยะทางถึงสายพานลำเลียงสัมภาระที่สนามบินฮูสตัน ลดลงจำนวนข้อร้องเรียนเกี่ยวกับกระเป๋าเดินทางสูญหายโดยไม่จำเป็นต้องเร่งดำเนินการเกี่ยวกับสัมภาระ

แนวคิดนี้ควรส่งผลกระทบอย่างจริงจังต่อ UI ของแอปพลิเคชันของเรา ฉันเชื่อว่าตัวบ่งชี้การโหลดควรกลายเป็นสิ่งหายาก โดยเฉพาะอย่างยิ่งเมื่อเราเปลี่ยนไปใช้แอปพลิเคชันข้อมูลแบบเรียลไทม์ ซึ่งจะอธิบายไว้ในส่วนถัดไป

มีบางสถานการณ์ที่ภาพลวงตาของการกระทำในทันทีส่งผลเสียต่อ UX นี่อาจเป็นรูปแบบการชำระเงินหรือสิ้นสุดเซสชันบนเว็บไซต์ ด้วยการใช้แนวทางในแง่ดีที่นี่ ซึ่งหลอกลวงผู้ใช้โดยพฤตินัย เราอาจเสี่ยงต่อการทำให้เขาหงุดหงิด

แต่ถึงแม้ในกรณีเหล่านี้ การแสดงสปินเนอร์หรือตัวแสดงการโหลดบนหน้าจอก็ควรหยุดลง ควรแสดงเฉพาะหลังจากที่ผู้ใช้พิจารณาว่าการตอบกลับไม่ได้เกิดขึ้นทันที จากการศึกษาของ Nielsen ที่อ้างถึงบ่อยครั้ง:

คำแนะนำเวลาตอบสนองขั้นพื้นฐานยังคงเหมือนเดิมเป็นเวลาสามสิบปี Miller 1968; การ์ดและคณะ 1991:
*0.1 วินาทีคือขีดจำกัดสำหรับผู้ใช้ในการรับรู้การตอบสนองทันที โดยไม่จำเป็นต้องแสดงผลที่นี่ ข้อมูลเพิ่มเติมเว้นแต่ผลการดำเนินการ
* 1.0 วินาทีคือขีดจำกัดความต่อเนื่องของความคิดของผู้ใช้ แม้ว่าเขาจะสังเกตเห็นความล่าช้าก็ตาม โดยทั่วไปแล้ว ไม่จำเป็นต้องมีตัวบ่งชี้เพิ่มเติมสำหรับความล่าช้าที่มากกว่า 0.1 วินาที แต่น้อยกว่า 1.0 วินาที แต่ผู้ใช้จะสูญเสียความรู้สึกในการทำงานกับข้อมูลโดยตรง
* 10 วินาทีคือขีดจำกัดในการรักษาความสนใจของผู้ใช้ต่อบทสนทนา ด้วยเวลาแฝงที่สูงขึ้น ผู้ใช้จะต้องการทำงานอื่นในขณะที่รอการตอบกลับจากคอมพิวเตอร์

น่าเสียดายที่เทคนิคอย่าง PJAX หรือ TurboLinks พลาดคุณสมบัติส่วนใหญ่ที่อธิบายไว้ในนั้น ส่วนนี้- รหัสฝั่งไคลเอ็นต์ไม่ "รู้" เกี่ยวกับสถานะในอนาคตของเพจจนกว่าจะมีการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์

3. การตอบสนองต่อการเปลี่ยนแปลงข้อมูล

tl; DR: เมื่อมีการอัพเดตข้อมูลบนเซิร์ฟเวอร์ ลูกค้าควรได้รับการแจ้งเตือนโดยไม่ชักช้า นี่เป็นรูปแบบหนึ่งของการปรับปรุงประสิทธิภาพการทำงานเมื่อผู้ใช้ไม่ต้องดำเนินการเพิ่มเติม (กด F5 รีเฟรชหน้า) ปัญหาใหม่: การจัดการการเชื่อมต่อ (อีกครั้ง) การกู้คืนสถานะ

หลักการที่สามเกี่ยวข้องกับการตอบสนองของ UI ต่อการเปลี่ยนแปลงข้อมูลที่ต้นทาง ซึ่งโดยทั่วไปคือเซิร์ฟเวอร์ฐานข้อมูลตั้งแต่หนึ่งเครื่องขึ้นไป

ไปแล้วคือรูปแบบการส่งข้อมูล HTML ที่คงที่จนกว่าผู้ใช้จะรีเฟรชหน้า (เว็บไซต์แบบเดิม) หรือโต้ตอบกับมัน (Ajax)

UI ของคุณควรอัปเดตโดยอัตโนมัติ

นี่เป็นสิ่งสำคัญในโลกที่ข้อมูลไหลเพิ่มมากขึ้นจากแหล่งต่างๆ รวมถึงนาฬิกา โทรศัพท์ แท็บเล็ต และอุปกรณ์สวมใส่ที่จะปรากฏในอนาคต

นำเสนอข่าว ฟีด Facebookทันทีที่ปรากฏเมื่อมีการเผยแพร่ข้อมูลเป็นหลักด้วย คอมพิวเตอร์ส่วนบุคคลผู้ใช้ การเรนเดอร์แบบคงที่นั้นไม่เหมาะสมที่สุด แต่ก็เหมาะสมสำหรับผู้ที่รีเฟรชฟีดของตน เช่น วันละครั้ง

ตอนนี้เราอยู่ในโลกที่คุณอัปโหลดรูปภาพและได้รับไลค์และความคิดเห็นจากเพื่อนและคนรู้จักเกือบจะในทันที ความจำเป็นในการตอบสนองทันทีกลายเป็นสิ่งจำเป็นตามธรรมชาติในสภาพแวดล้อมการแข่งขันของแอปพลิเคชันอื่นๆ

อย่างไรก็ตาม การสันนิษฐานว่าประโยชน์ของการอัปเดต UI แบบทันทีนั้นจำกัดอยู่เพียงแอปพลิเคชันที่มีผู้ใช้หลายรายอาจถือเป็นเรื่องผิด นั่นเป็นเหตุผลที่ฉันชอบพูดถึง จุดข้อมูลที่ตกลงกัน, แทน ผู้ใช้- ลองใช้สถานการณ์ทั่วไปในการซิงโครไนซ์รูปภาพระหว่างโทรศัพท์กับแล็ปท็อปของคุณเอง:

แอปพลิเคชันแบบผู้ใช้คนเดียวยังสามารถได้รับประโยชน์จากปฏิกิริยาอีกด้วย

มีประโยชน์ในการจินตนาการ ทั้งหมดข้อมูลที่ส่งถึงผู้ใช้ในรูปแบบ "โต้ตอบ" การซิงโครไนซ์เซสชันและสถานะการอนุญาตเป็นตัวอย่างหนึ่งของแนวทางสากล หากผู้ใช้แอปพลิเคชันของคุณเปิดหลายแท็บพร้อมกัน การสิ้นสุดเซสชันการทำงานในแท็บใดแท็บหนึ่งควรปิดใช้งานการให้สิทธิ์ในแท็บอื่นๆ ทั้งหมดทันที สิ่งนี้นำไปสู่การปรับปรุงความปลอดภัยและการป้องกันที่ดีขึ้นอย่างหลีกเลี่ยงไม่ได้ ข้อมูลที่เป็นความลับโดยเฉพาะในสถานการณ์ที่มีผู้ใช้หลายคนเข้าถึงอุปกรณ์เครื่องเดียวกันได้

แต่ละหน้าตอบสนองต่อสถานะเซสชันและสถานะการอนุญาต

เมื่อคุณกำหนดกฎว่าข้อมูลบนหน้าจอจะได้รับการอัปเดตโดยอัตโนมัติ สิ่งสำคัญคือต้องทำงานใหม่: การกู้คืนสถานะ

เมื่อส่งคำขอและรับการอัปเดตปรมาณู เป็นเรื่องง่ายที่จะลืมว่าแอปพลิเคชันของคุณควรอัปเดตตามปกติแม้ว่าจะไม่มีการใช้งานเป็นเวลานานก็ตาม ลองนึกภาพการปิดฝาแล็ปท็อปของคุณแล้วเปิดขึ้นในอีกไม่กี่วันต่อมา แอปพลิเคชันจะทำงานอย่างไร

ตัวอย่างสิ่งที่เกิดขึ้นหากการเชื่อมต่อไม่ได้รับการอัพเดตอย่างถูกต้อง

ความสามารถของแอปพลิเคชันในการเชื่อมต่อใหม่ตามปกติจะโต้ตอบกับหลักการ #1 หากคุณเลือกที่จะส่งข้อมูลในการโหลดหน้าแรก คุณต้องคำนึงถึงเวลาที่ผ่านไปก่อนที่จะโหลดสคริปต์ด้วย เวลานี้เทียบเท่ากับเวลาตัดการเชื่อมต่อ ดังนั้นการเชื่อมต่อเริ่มต้นของสคริปต์ของคุณจึงเป็นการเริ่มต้นเซสชันใหม่

4. การควบคุมการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์

tl; DR: ตอนนี้เราสามารถปรับแต่งการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์ได้ ตรวจสอบให้แน่ใจว่าได้จัดการกับข้อผิดพลาด ร้องขอความช่วยเหลือจากไคลเอ็นต์อีกครั้ง ซิงค์ข้อมูลในเบื้องหลัง และบันทึกแคชออฟไลน์

เมื่อเว็บเกิดขึ้น การสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ถูกจำกัดด้วยหลายวิธี:

การคลิกลิงค์จะเป็นการส่ง GET เพื่อรับ หน้าใหม่และการเรนเดอร์ของมัน

การส่งแบบฟอร์มจะส่ง POST หรือ GET ตามด้วยการแสดงหน้าใหม่

การแทรกรูปภาพหรือวัตถุจะส่ง GET แบบอะซิงโครนัสตามด้วยการแสดงผล

ความเรียบง่ายของรุ่นนี้น่าดึงดูดมาก และตอนนี้สิ่งต่าง ๆ มีความซับซ้อนมากขึ้นอย่างแน่นอนเมื่อต้องทำความเข้าใจวิธีรับและส่งข้อมูล

ข้อจำกัดหลักเกี่ยวข้องกับประเด็นที่สอง การไม่สามารถส่งข้อมูลโดยไม่จำเป็นต้องโหลดหน้าใหม่ถือเป็นข้อเสียจากมุมมองของประสิทธิภาพ แต่สิ่งที่สำคัญที่สุดคือทำให้ปุ่ม "ย้อนกลับ" พังโดยสิ้นเชิง:

อาจเป็นสิ่งประดิษฐ์ที่น่ารำคาญที่สุดของเว็บเก่า

นี่คือสาเหตุที่เว็บในฐานะแพลตฟอร์มแอปพลิเคชันยังคงไม่สมบูรณ์หากไม่มี JavaScript Ajax เป็นการก้าวกระโดดครั้งใหญ่ในแง่ของความง่ายในการเผยแพร่โดยผู้ใช้

ขณะนี้เรามี API จำนวนมาก (XMLHttpRequest, WebSocket, EventSource และอื่นๆ อีกมากมาย) ที่ให้การควบคุมการไหลของข้อมูลอย่างสมบูรณ์และแม่นยำ นอกจากความสามารถในการเผยแพร่ข้อมูลผู้ใช้ผ่านแบบฟอร์มแล้ว เรายังมีโอกาสใหม่ในการปรับปรุง UX

จอแสดงผลเกี่ยวข้องโดยตรงกับหลักการก่อนหน้า สถานะการเชื่อมต่อ- หากเราคาดหวังว่าข้อมูลจะได้รับการอัปเดตโดยอัตโนมัติ เราต้องแจ้งให้ผู้ใช้ทราบข้อเท็จจริง สูญเสียการเชื่อมต่อและ พยายามที่จะคืนค่ามัน.

เมื่อตรวจพบการตัดการเชื่อมต่อ จะมีประโยชน์ในการจัดเก็บข้อมูลในหน่วยความจำ (หรือดีกว่านั้นใน localStorage) เพื่อให้สามารถส่งได้ในภายหลัง นี่เป็นสิ่งสำคัญอย่างยิ่งในแง่ของการใช้งาน ServiceWorker ในอนาคต ซึ่งช่วยให้แอปพลิเคชัน JavaScript ทำงานได้ ในพื้นหลัง- หากแอปพลิเคชันของคุณไม่เปิด คุณยังคงสามารถลองซิงค์ข้อมูลกับเซิร์ฟเวอร์ในเบื้องหลังต่อไปได้

พิจารณาความเป็นไปได้ของการหมดเวลาและข้อผิดพลาดเมื่อส่งข้อมูล สถานการณ์ดังกล่าวควรได้รับการแก้ไขเพื่อประโยชน์ของลูกค้า หากการเชื่อมต่อกลับคืนมา ให้ลองส่งข้อมูลอีกครั้ง ในกรณีที่มีข้อผิดพลาดถาวร โปรดแจ้งให้ผู้ใช้ทราบ

ข้อผิดพลาดบางอย่างจำเป็นต้องได้รับการจัดการอย่างระมัดระวังเป็นพิเศษ ตัวอย่างเช่น 403 ที่ไม่คาดคิดอาจหมายความว่าเซสชันของผู้ใช้ไม่ถูกต้อง ในกรณีเช่นนี้ คุณสามารถกู้คืนเซสชันได้โดยแสดงหน้าต่างให้ผู้ใช้เข้าสู่ระบบและรหัสผ่าน

สิ่งสำคัญคือต้องแน่ใจว่าผู้ใช้จะไม่ขัดจังหวะการไหลของข้อมูลโดยไม่ได้ตั้งใจ สิ่งนี้สามารถเกิดขึ้นได้ในสองสถานการณ์ กรณีแรกและชัดเจนที่สุดคือการปิดเบราว์เซอร์หรือแท็บ ซึ่งเป็นสิ่งที่เราพยายามป้องกันด้วยตัวจัดการก่อนยกเลิกการโหลด

คำเตือนก่อนยกเลิกการโหลด

อีกกรณีหนึ่ง (และชัดเจนน้อยกว่า) คือเมื่อคุณพยายามนำทางไปยังหน้าอื่น เช่น โดยการคลิกที่ลิงก์ ในกรณีนี้ แอปพลิเคชันสามารถหยุดผู้ใช้โดยใช้วิธีอื่นได้ ขึ้นอยู่กับดุลยพินิจของผู้พัฒนา

5. อย่าทำลายเรื่องราว ปรับปรุงมัน

tl;DR: หากเบราว์เซอร์ไม่จัดการ URL และประวัติ เราจะพบปัญหาใหม่ ตรวจสอบให้แน่ใจว่าคุณมีคุณสมบัติตรงตามลักษณะการเลื่อนที่คาดไว้ บันทึกแคชของคุณเองเพื่อรับข้อเสนอแนะอย่างรวดเร็ว

ตัวอย่างเช่น เพจ "ไม่มีที่สิ้นสุด" ทั่วไปมักจะสร้างด้วยปุ่ม JavaScript ที่ขอข้อมูลเพิ่มเติม/HTML แล้วแทรกเข้าไป น่าเสียดายที่มีเพียงไม่กี่คนที่จำได้ว่าต้องโทรไปที่ history.pushState หรือ replacementState เป็นขั้นตอนที่จำเป็น

เพราะเหตุนี้ผมจึงใช้คำว่า "แตก" ด้วยรูปแบบที่เรียบง่ายของเว็บดั้งเดิม สถานการณ์นี้จึงเป็นไปไม่ได้ การเปลี่ยนแปลงแต่ละสถานะขึ้นอยู่กับการเปลี่ยนแปลง URL

แต่ก็มีเช่นกัน ด้านหลังเหรียญ - โอกาส ทำให้ดีขึ้นประวัติการท่องเว็บ ซึ่งตอนนี้เราควบคุมโดยใช้ JavaScript

ความเป็นไปได้อย่างหนึ่งที่เรียกว่า Fast Back โดย Daniel Pipius:

ปุ่มย้อนกลับควรทำงานได้อย่างรวดเร็ว ผู้ใช้ไม่คาดหวังการเปลี่ยนแปลงข้อมูลมากเกินไป

มันเหมือนกับการใช้ปุ่มย้อนกลับเหมือนปุ่มจากเว็บแอปพลิเคชันและใช้หลักการ #2 กับมัน: ตอบสนองต่อการกระทำของผู้ใช้ทันที- สิ่งสำคัญคือคุณมีโอกาสที่จะตัดสินใจว่าจะแคชหน้าก่อนหน้าอย่างไรและแสดงบนหน้าจอทันที จากนั้นคุณสามารถใช้หลักการ #3 แล้วแจ้งให้ผู้ใช้ทราบเมื่อมีข้อมูลใหม่มาถึงหน้านั้น

ยังคงมีบางสถานการณ์ที่คุณไม่สามารถควบคุมการทำงานของแคชได้ ตัวอย่างเช่น หากคุณแสดงผลเพจ จากนั้นไปที่ไซต์บุคคลที่สาม จากนั้นผู้ใช้คลิก "ย้อนกลับ" แอปพลิเคชันที่แสดง HTML บนฝั่งเซิร์ฟเวอร์แล้วแก้ไขบนฝั่งไคลเอ็นต์จะไวต่อจุดบกพร่องเล็กๆ น้อยๆ นี้เป็นพิเศษ:

ทำงานไม่ถูกต้องปุ่มย้อนกลับ

อีกวิธีหนึ่งในการทำลายการนำทางคือการละเว้นหน่วยความจำสถานะการเลื่อน อีกครั้งหนึ่งเพจที่ไม่ใช้ JS และ ควบคุมด้วยมือประวัติศาสตร์น่าจะไม่มีปัญหาที่นี่ แต่ หน้าไดนามิกจะมี ฉันทดสอบฟีดข่าวที่ใช้ JavaScript ที่ได้รับความนิยมมากที่สุดสองรายการบนอินเทอร์เน็ต: Twitter และ Facebook ทั้งสองมีความจำเสื่อมแบบเลื่อน

การเปลี่ยนหน้าอย่างไม่มีที่สิ้นสุดมักเป็นสัญญาณของความจำเสื่อมในการเลื่อน

ท้ายที่สุด ควรระวังการเปลี่ยนแปลงสถานะที่เกี่ยวข้องเมื่อดูประวัติเท่านั้น ตัวอย่างเช่น กรณีนี้ด้วยการเปลี่ยนสถานะของแผนผังย่อยพร้อมความคิดเห็น

การเปลี่ยนประเภทความคิดเห็นจะต้องบันทึกไว้ในประวัติ

หากเพจถูกแสดงผลอีกครั้งหลังจากคลิกลิงก์ภายในแอปพลิเคชัน ผู้ใช้อาจคาดหวังให้ขยายความคิดเห็นทั้งหมด เมื่อสถานะเปลี่ยนแปลงก็ต้องบันทึกไว้ในประวัติ

6. อัปเดตรหัสผ่านข้อความพุช

tl; DR: การส่งข้อมูลผ่านข้อความพุชเพียงอย่างเดียวนั้นไม่เพียงพอ คุณต้องใช้รหัสด้วย หลีกเลี่ยงข้อผิดพลาด API และปรับปรุงประสิทธิภาพ ใช้ DOM ไร้สถานะเพื่อออกแบบแอปพลิเคชันของคุณใหม่โดยไม่ยุ่งยาก

เป็นสิ่งสำคัญอย่างยิ่งที่แอปพลิเคชันของคุณตอบสนองต่อการเปลี่ยนแปลงในโค้ด

ประการแรกจะลดจำนวนลง ข้อผิดพลาดที่เป็นไปได้และเพิ่มความน่าเชื่อถือ หากคุณได้ทำการเปลี่ยนแปลงที่สำคัญกับ API แบ็กเอนด์ ต้องอัพเดตโค้ดของโปรแกรมไคลเอนต์ มิฉะนั้นลูกค้าอาจไม่ยอมรับข้อมูลใหม่หรืออาจส่งข้อมูลในรูปแบบที่เข้ากันไม่ได้

ไม่น้อย เหตุผลสำคัญคือการปฏิบัติตามหลักการ #3 หากอินเทอร์เฟซของคุณอัปเดตตัวเอง ก็ไม่มีเหตุผลเพียงเล็กน้อยที่ผู้ใช้จะต้องโหลดหน้าเว็บซ้ำด้วยตนเอง

โปรดทราบว่าสำหรับไซต์ทั่วไป การรีเฟรชหน้าเว็บจะทริกเกอร์สองสิ่ง: การโหลดข้อมูลซ้ำและการโหลดโค้ดอีกครั้ง การจัดการระบบด้วยการอัปเดตข้อมูลแบบพุชโดยไม่ต้องอัปเดตรหัสแบบพุชนั้นไม่สมบูรณ์ โดยเฉพาะอย่างยิ่งในโลกที่แท็บเดียว (เซสชัน) สามารถเปิดอยู่ได้เป็นเวลานานมาก

หากช่องทางการพุชของเซิร์ฟเวอร์ใช้งานได้ ผู้ใช้จะได้รับแจ้งเกี่ยวกับความพร้อมใช้งานของรหัสใหม่ ถ้าไม่เช่นนั้น คุณสามารถเพิ่มหมายเลขเวอร์ชันลงในส่วนหัวของคำขอ HTTP ขาออกได้ เซิร์ฟเวอร์สามารถเปรียบเทียบกับเวอร์ชันล่าสุดที่รู้จัก ตกลงที่จะประมวลผลคำขอหรือไม่ และออกงานให้กับลูกค้า

หลังจากนี้ เว็บแอปพลิเคชันบางตัวจะบังคับให้โหลดเพจซ้ำในนามของผู้ใช้ เช่น หากหน้านั้นไม่อยู่ในบริเวณที่มองเห็นได้ของหน้าจอและไม่มีแบบฟอร์มให้กรอกข้อมูลครบถ้วน

แนวทางที่ดียิ่งขึ้นคือการสลับโค้ดแบบ "ร้อน" ซึ่งหมายความว่าคุณไม่จำเป็นต้องโหลดหน้าใหม่ทั้งหมด แทนแน่นอน โมดูลจะถูกแทนที่ทันที และส่งรหัสอีกครั้งเพื่อดำเนินการ

ในแอปพลิเคชันที่มีอยู่จำนวนมาก โค้ดแบบ Hot-swap ค่อนข้างยาก เมื่อต้องการทำเช่นนี้ คุณต้องยึดตามสถาปัตยกรรมที่แยกออกจากกันตั้งแต่แรก พฤติกรรม(รหัส) จาก ข้อมูล(สถานะ). แผนกนี้จะทำให้เราสามารถเผยแพร่แพตช์ต่างๆ มากมายได้อย่างรวดเร็ว

ตัวอย่างเช่น ในเว็บแอปพลิเคชันของเรา มีโมดูลที่ตั้งค่าบัสสำหรับส่งเหตุการณ์ (เช่น socket.io) เมื่อมีเหตุการณ์เกิดขึ้น สถานะขององค์ประกอบเฉพาะจะเปลี่ยนไป และสิ่งนี้จะสะท้อนให้เห็นใน DOM จากนั้นคุณเปลี่ยนลักษณะการทำงานของส่วนประกอบนั้น ตัวอย่างเช่น เพื่อให้สร้างมาร์กอัป DOM ที่แตกต่างกันสำหรับสถานะที่มีอยู่และสถานะใหม่

ตามหลักการแล้ว เราควรจะสามารถเปลี่ยนแปลงโค้ดแบบโมดูลาร์ได้ ไม่จำเป็นต้องสร้างการเชื่อมต่อกับซ็อกเก็ตอีกครั้ง ตัวอย่างเช่น หากเป็นไปได้ที่จะอัปเดตโค้ด ส่วนประกอบที่จำเป็น- สถาปัตยกรรมในอุดมคติสำหรับการอัพเดตพุชโค้ดจึงเป็นแบบโมดูลาร์

แต่ปัญหาเกิดขึ้นทันทีว่าจะประเมินโมดูลโดยที่ไม่ต้องการได้อย่างไร ผลข้างเคียง- สถาปัตยกรรมแบบที่ React นำเสนอเหมาะที่สุดที่นี่ หากมีการอัปเดตโค้ดของส่วนประกอบ ตรรกะของส่วนประกอบนั้นสามารถดำเนินการอีกครั้งและ DOM จะได้รับการอัปเดต อ่านคำอธิบายของ Dan Abramov เกี่ยวกับแนวคิดนี้

โดยพื้นฐานแล้ว แนวคิดก็คือให้คุณอัปเดต DOM (หรือเปลี่ยนสี) ซึ่งช่วยได้อย่างมากในการแทนที่โค้ด หากสถานะถูกเก็บไว้ใน DOM หรือแอปพลิเคชันติดตั้งตัวจัดการเหตุการณ์ การอัปเดตโค้ดอาจกลายเป็นงานที่ยากขึ้นมาก

7. การทำนายพฤติกรรม

tl; DR : ความล่าช้าเชิงลบ

แอปพลิเคชัน JavaScript สมัยใหม่อาจมีกลไกในการทำนายการกระทำของผู้ใช้

การใช้งานแนวคิดนี้ที่ชัดเจนที่สุดคือการดาวน์โหลดข้อมูลจากเซิร์ฟเวอร์ล่วงหน้าก่อนที่ผู้ใช้จะร้องขอ การโหลดหน้าเว็บโดยวางเคอร์เซอร์ของเมาส์ไว้เหนือหน้าเว็บเพื่อให้การคลิกลิงก์ปรากฏขึ้นทันทีเป็นตัวอย่างง่ายๆ

วิธีการตรวจสอบการติดตามเมาส์ขั้นสูงกว่าเล็กน้อยจะวิเคราะห์วิถีการเคลื่อนที่ของเมาส์สำหรับ "การชน" ในอนาคตด้วยองค์ประกอบแบบโต้ตอบเช่นปุ่ม -

ปลั๊กอิน jQuery ทำนายเส้นทางของเมาส์

บทสรุป

อินเทอร์เน็ตยังคงเป็นสื่อที่หลากหลายที่สุดในการส่งข้อมูล เรายังคงเพิ่มไดนามิกให้กับเพจของเรา และก่อนที่จะนำไปใช้ เราต้องแน่ใจว่าเรารักษาหลักการสำคัญของเว็บที่เราได้รับมา

เพจที่มีไฮเปอร์ลิงก์เป็นองค์ประกอบที่ดีสำหรับแอปพลิเคชันใดๆ การโหลดโค้ด สไตล์ และมาร์กอัปอย่างต่อเนื่องในขณะที่ผู้ใช้โต้ตอบ ช่วยให้มั่นใจถึงประสิทธิภาพที่ยอดเยี่ยมโดยไม่ต้องเสียสละการโต้ตอบ

JavaScript มีคุณสมบัติพิเศษใหม่ให้ หากเทคโนโลยีเหล่านี้มีการใช้กันอย่างแพร่หลายก็จะจัดให้มี ประสบการณ์ที่ดีที่สุดทำงานให้กับผู้ใช้แพลตฟอร์มที่อิสระที่สุดที่มีอยู่ - WWW

เครื่องมือที่ทันสมัยสำหรับการพัฒนาเว็บไซต์อินเทอร์เน็ตและแอปพลิเคชันเว็บ

ครูปินา ทัตยานา อเล็กซานดรอฟนา 1, ชเชอร์บาโควา สเวตลานา มิคาอิลอฟนา 1
1 Moscow Pedagogical State University นักศึกษาปริญญาโท

คำอธิบายประกอบ
บทความนี้เน้นไปที่ภาพรวมของเครื่องมือสมัยใหม่สำหรับการพัฒนาเว็บไซต์อินเทอร์เน็ตและเว็บแอปพลิเคชัน ปัญหาในการสอนนักเรียนและเด็กนักเรียนยังมีการกล่าวถึงเทคโนโลยีเหล่านี้ด้วย

เครื่องมือพัฒนาที่ทันสมัย เว็บไซต์ออนไลน์และแอปพลิเคชันบนเว็บ

ครูปิน่า ตาเตียนา อเล็กซานดรอฟน่า 1 , ชเชอร์บาโควา สเวตลานา มิคายลอฟน่า 1
1 Moscow State Pedagogical University สำเร็จการศึกษาจากภาควิชาคณิตศาสตร์ประยุกต์และไอที

เชิงนามธรรม
บทความนี้ให้ภาพรวมของการพัฒนาเว็บไซต์สมัยใหม่และแอปพลิเคชันบนเว็บ นอกจากนี้ยังกล่าวถึงปัญหาในการฝึกอบรมนักเรียนและนักเรียนเกี่ยวกับเทคโนโลยีเหล่านี้

สารสนเทศของสังคมยุคใหม่เกี่ยวข้องกับการแนะนำวิธีการและวิธีการของข้อมูลและ เทคโนโลยีการสื่อสาร(ICT) ในด้านต่างๆ ของกิจกรรมของมนุษย์ บทบาทพิเศษในกระบวนการนี้ไม่ต้องสงสัยเลยว่าเป็นของการพัฒนาเทคโนโลยีเครือข่ายและการสื่อสาร ซึ่งเหนือสิ่งอื่นใดแสดงให้เห็นในการสร้างระบบข้อมูลอัตโนมัติขององค์กรและโครงการเครือข่ายอีคอมเมิร์ซ แท้จริงแล้วกิจกรรมใดๆ องค์กรที่ทันสมัยไม่ทางใดก็ทางหนึ่ง เกี่ยวข้องกับการสร้างและบำรุงรักษาเว็บไซต์ของบริษัท

มาตรฐานการศึกษาของรัฐบาลกลางสมัยใหม่ (FSES) ในหลายสาขาไม่เพียงแต่ด้านวิศวกรรมเท่านั้น แต่ยังรวมถึงด้านมนุษยธรรมด้วย กำหนดให้ผู้สำเร็จการศึกษาต้องมีทักษะในการพัฒนาและจัดการไซต์อินเทอร์เน็ต

วิธีการและเครื่องมือสำหรับการพัฒนาไซต์อินเทอร์เน็ตและเว็บแอปพลิเคชันกำลังพัฒนาแบบไดนามิก ตั้งแต่ความสามารถในการสร้างไซต์นามบัตรแบบธรรมดาไปจนถึงการพัฒนาแอปพลิเคชันเซิร์ฟเวอร์ที่ประมวลผลและจัดเก็บข้อมูลจำนวนมาก

หากต้องการพัฒนาเว็บไซต์แบบเรียบง่าย รวมถึงเว็บไซต์นามบัตรพร้อมคำอธิบายและข้อมูลติดต่อ คุณสามารถใช้วิธีการต่างๆ ได้:

การสร้างเอกสาร HTML เช่น ใช้โปรแกรมแก้ไข Notepad พิมพ์รหัสใน HTML ด้วยตนเองและนำไปใช้โดยใช้เบราว์เซอร์บนเวิร์กสเตชันไคลเอนต์ จากนั้นเผยแพร่กับผู้ให้บริการโดยใช้บริการโฮสติ้ง
การสร้างเอกสาร HTML เดียวกันโดยใช้โปรแกรมแก้ไข อะโดบี ดรีมวีเวอร์, ใช้ประโยชน์จากฟังก์ชั่นและสิ่งอำนวยความสะดวกที่หลากหลาย;
ใช้ไซต์เชลล์สำเร็จรูปเพื่อพัฒนาเว็บไซต์ในพื้นที่และการออกแบบต่างๆ และเผยแพร่ไซต์บนอินเทอร์เน็ตโดยใช้บริการโฮสติ้งฟรีหรือมีค่าใช้จ่าย

ต่างจากการพัฒนาไซต์ที่เรียบง่ายและไม่มีการโต้ตอบ สำหรับการพัฒนาแอปพลิเคชันเว็บที่รันและประมวลผลข้อมูลบนเซิร์ฟเวอร์ วิธีการและเครื่องมือเป็นสิ่งจำเป็นที่เสริมวิธีการและเครื่องมือที่ระบุไว้ในย่อหน้าก่อนหน้า นอกเหนือจากการสร้างโค้ด HTML การพัฒนาแอปพลิเคชันบนเว็บยังเกี่ยวข้องกับการเขียนโปรแกรมในภาษาพิเศษอีกด้วย ในการพัฒนาเว็บแอปพลิเคชันนั้น มีการใช้ภาษาการเขียนโปรแกรม PHP และไม่มีใครสามารถทำได้หากไม่มีเซิร์ฟเวอร์ Apache ในเครื่องและฐานข้อมูล MySQL

ลองดูเครื่องมือการเขียนโปรแกรมแอปพลิเคชันเว็บเพิ่มเติม:

ภาษาการเขียนโปรแกรม JavaScript ใช้เพื่อสร้างเอกสาร HTML แบบโต้ตอบ
VBScript ใช้สำหรับการเขียนสคริปต์ไคลเอนต์เช่นเดียวกับการเขียนสคริปต์เซิร์ฟเวอร์
Perl ใช้เพื่อพัฒนาเครื่องมือการดูแลระบบ เช่นเดียวกับในการพัฒนาสคริปต์ CGI ระบบประมวลผลอีเมลอัตโนมัติ และการสนับสนุนเว็บไซต์

หากต้องการพัฒนาเว็บแอปพลิเคชันอย่างอิสระ คุณสามารถใช้ทรัพยากร Denwer ที่แจกจ่ายอย่างอิสระได้

Denwer (จากตัวย่อ DNVR - ชุดนักพัฒนาเว็บของสุภาพบุรุษ) คือชุดของการแจกจ่ายและเชลล์ซอฟต์แวร์ที่ออกแบบมาสำหรับการสร้างและแก้ไขข้อบกพร่องของแอปพลิเคชันเว็บและเนื้อหาไดนามิกอื่น ๆ ของเว็บเพจบนพีซีที่ใช้ระบบปฏิบัติการ

ชุด Denwer ประกอบด้วย:

ท้องถิ่น เซิร์ฟเวอร์อาปาเช่เพื่อเปิดแอพพลิเคชั่นบนคอมพิวเตอร์ของผู้ใช้จำลองการทำงานของเซิร์ฟเวอร์โดยที่ผู้ให้บริการจะติดตั้งแอพพลิเคชั่นที่พัฒนาขึ้นในภายหลัง อาปาเช่คือ ซอฟต์แวร์– ข้ามแพลตฟอร์ม เผยแพร่อย่างอิสระและสนับสนุนโดยระบบปฏิบัติการต่างๆ
ระบบการเขียนโปรแกรม PHP เป็นภาษา C-like สำหรับการพัฒนาโค้ดโปรแกรมที่ฝังอยู่ในโค้ด HTML ของไซต์และดำเนินการบนเซิร์ฟเวอร์เพื่อวัตถุประสงค์ในการประมวลผลข้อมูลที่ได้รับจากผู้ใช้ของไซต์ใดไซต์หนึ่ง PHP (Hypertext Preprocessor - "Hypertext Preprocessor" เดิมทีเครื่องมือโฮมเพจส่วนบุคคล - "เครื่องมือสำหรับการสร้าง หน้าเว็บส่วนตัว") – ภาษาสคริปต์ จุดประสงค์ทั่วไปใช้สำหรับการพัฒนาเว็บแอปพลิเคชันถูกสร้างขึ้นโดย Rasmus Lerdorf ในปี 1994;
MySQL เป็นซอฟต์แวร์ที่ใช้งานได้ฟรีสำหรับการประมวลผลฐานข้อมูล รวมถึงเมื่อทำงานกับข้อมูลที่ได้รับจากเบราว์เซอร์ไคลเอนต์ MySQL (ภาษาแบบสอบถามที่มีโครงสร้าง - " ภาษาที่มีโครงสร้างแบบสอบถาม") สร้างขึ้นโดย Michael Widenius จากบริษัท TcX ของสวีเดนในปี 1995

ชุด โปรแกรมเดนเวอร์หรือส่วนประกอบต่างๆ ถูกใช้กันอย่างแพร่หลายโดยทั้งมือสมัครเล่นและมืออาชีพเพื่อสร้างและแก้ไขข้อบกพร่องของแอปพลิเคชันเว็บและไซต์ ชุดนี้ยังใช้กันอย่างแพร่หลายเพื่อการศึกษาเพื่อสอนการเขียนโปรแกรมเว็บให้กับเด็กนักเรียนและนักเรียน

อับดุลกาลิมอฟ จี.แอล., คูเกล แอล.เอ. การฝึกอบรมการออกแบบระบบสารสนเทศและการวิเคราะห์ข้อมูล การศึกษาวิชาชีพ เมืองหลวง. 2556. ฉบับที่ 4. หน้า 31-33.

อับดุลกาลิมอฟ จี.แอล. ระบบการฝึกอบรมครูสาขาวิชาไอที การศึกษาระดับอุดมศึกษาในรัสเซีย 2553 ฉบับที่ 3 หน้า 156-158.

ลุค เวลลิง, ลอรา ทอมสัน. การพัฒนาเว็บแอพพลิเคชั่นด้วย PHP และ MySQL สำนักพิมพ์“วิลเลียมส์” 2010. -837. ไอ: 978-5-8459-1574-0.

จำนวนการดูสิ่งพิมพ์: กรุณารอสักครู่ คำถามคือ จะต้องรู้อะไรอีกบ้าง?
ไม่ว่าในกรณีใด คุณต้องมีแบ็กเอนด์ ถ้าฉันเข้าใจถูกต้อง Angular, Vue และเฟรมเวิร์กอื่นๆ ก็เป็นเพียงส่วนหน้าเท่านั้น
ใช่แล้ว ทุกที่ที่คุณหันไป การพัฒนาเว็บถูกพูดถึงทุกที่ว่าเป็นการพัฒนาส่วนหน้า และแน่นอนว่ามันเชื่อมโยงกับ Node.js (เพื่อที่จะเขียนอะไรบางอย่างใน Angular คุณไม่สามารถทำได้หากไม่มีมัน) ฉันไม่เข้าใจว่าส่วนหน้าเชื่อมต่อกับ Node.js อย่างไร เพราะ... Node.js เป็นวิธีเรียกใช้ JS ภายนอกเบราว์เซอร์เป็นหลัก
เป็นไปได้มากว่าคุณกำลังอ่านบทความเกี่ยวกับส่วนหน้า เนื่องจากไม่มีอะไรเกี่ยวกับส่วนหลังในบทความเหล่านั้น ดังที่คุณทราบ ส่วนหน้าเขียนด้วย JS และหลาย ๆ คนประทับใจกับความจริงที่ว่าคุณสามารถติดตั้ง NodeJS บนแบ็กเอนด์และสร้างเว็บไซต์โดยใช้ภาษาเดียวได้ หากฉันต้องการเรียกใช้แอปพลิเคชันในเบราว์เซอร์ แล้วทำไมฉันจึงต้องมีโหนด ? ทั้งหมดนี้ทำให้ฉันสับสน ฉันเห็นแต่ความขัดแย้ง
อย่าสับสน. มีเทคโนโลยีที่ใช้ในระหว่างกระบวนการสมัครและมีเทคโนโลยีที่ใช้ระหว่างกระบวนการพัฒนาแอปพลิเคชัน Gulp, Grunt, Babel, Webpack และอื่นๆ ทั้งหมดนี้เป็นเครื่องมือในการพัฒนา พวกเขาเร่งความเร็ว ลดความซับซ้อน และปรับปรุงคุณภาพของงาน ในเวลานั้น jQuery, Angular, React คือไลบรารีและเฟรมเวิร์กที่แอปพลิเคชันจะทำงาน

หากก่อนหน้านี้เว็บไซต์ถูกสร้างขึ้นโดยใช้เทคโนโลยีสองสามอย่าง แอพพลิเคชั่นที่ทันสมัยสามารถใช้หลายสิบหรือหลายร้อยอันหลังได้ สิ่งนี้เกี่ยวอะไรกับมัน? ภาษาที่แตกต่างกันการเขียนโปรแกรม ไลบรารี เฟรมเวิร์ก การบริการ ฯลฯ ทั้งหมดนี้มักเรียกว่า "สวนสัตว์" แห่งเทคโนโลยี

ที่นี่ฉันสามารถสรุปได้ว่าเซิร์ฟเวอร์ควรแลกเปลี่ยนข้อมูลกับแอปพลิเคชันผ่าน json หรืออย่างอื่นแทน html
ใช่ JSON เป็นไฟล์ที่พบบ่อยที่สุด คุณต้องมีเฟรมเวิร์กแบ็กเอนด์ที่คุณสามารถปรับใช้ REST API ได้ เท่าที่ฉันรู้ กรอบงานสมัยใหม่ส่วนใหญ่ของภาษาโปรแกรมสมัยใหม่ที่ใช้สำหรับการพัฒนาเว็บสามารถทำได้ ฉันไม่สามารถพูดได้อย่างแน่นอนว่าฉันทำงานด้วยภาษาเดียวกัน แต่เซิร์ฟเวอร์ก็เป็นพื้นฐานของสิ่งใด ๆ แอปพลิเคชันเครือข่ายและก่อนอื่นคุณต้องพัฒนาส่วนของเซิร์ฟเวอร์ก่อน
อย่างแน่นอน. แอปพลิเคชันหน้าเดียวสมัยใหม่ (SPA) ประกอบด้วยสองส่วนแยกกัน - ส่วนหน้าและส่วนหลัง สามารถสร้างแยกกันโดยสิ้นเชิง โดยนักพัฒนาที่แตกต่างกันสิ่งสำคัญคือการเห็นด้วยกับรูปแบบการถ่ายโอนข้อมูลและความแตกต่างทั้งหมด

ความงามของสปาอยู่ที่การแยกส่วนเหล่านี้ สิ่งใดสิ่งหนึ่งสามารถถูกแทนที่ด้วยสิ่งอื่นโดยไม่มีผลกระทบพิเศษใด ๆ แบ็กเอนด์หนึ่งสามารถให้บริการเว็บไซต์ แอปพลิเคชันบนมือถือ ให้การเข้าถึงข้อมูลสำหรับบุคคลที่สาม แอปพลิเคชันพันธมิตรและทั้งหมดผ่าน API เดียว

ต้องศึกษาอะไรอีกบ้าง? หรือมีความรู้เพียงพอ?
ฉันไม่คิดว่าจะเพียงพอ คุณจะกำหนดงานที่โครงการของคุณต้องแก้ไขและเลือกเทคโนโลยีสำหรับงานเหล่านั้นได้อย่างแม่นยำ คุณต้องมุ่งเน้นไปที่สิ่งหนึ่งคุณจะไม่สามารถศึกษาทุกสิ่งที่ทันสมัยได้จะไม่มีเวลาเพียงพอ เป็นไปได้หรือไม่ที่จะไม่ใช้ Node.js และด้วยเหตุนี้ npm หากจำเป็นต้องใช้ JS (TS) เท่านั้น เบราว์เซอร์เหรอ? ในขณะเดียวกันก็จำเป็นต้องมีการทดสอบด้วย
ใช่ มันค่อนข้างมาก บนฝั่งไคลเอ็นต์ เช่น JS+Angular และที่ฝั่งแบ็กเอนด์ เช่น PHP+Laravel ขณะนี้มีภาษามากมายและมีกรอบงานมากขึ้นสำหรับพวกเขา เลือกสิ่งที่ง่ายกว่าสำหรับคุณ

ล่าสุดเนื่องมาจาก UX และประสิทธิภาพการทำงานเป็นหลัก

ในขณะเดียวกัน มีคำถามมากมายเกี่ยวกับบทบาทและการใช้งานเฉพาะ ซึ่งหลายคนพบว่าเป็นการยากที่จะตอบ รวมถึงผู้เขียนเฟรมเวิร์กและไลบรารีด้วย

ควรใช้ JavaScript แทนฟังก์ชั่นเบราว์เซอร์: ประวัติ, การนำทาง, การเรนเดอร์หรือไม่
แบ็คเอนด์กำลังจะตายเหรอ? จำเป็นต้องเรนเดอร์ HTML เลยหรือไม่?
จริงหรือไม่ที่ Single Page Applications (SPAs) คืออนาคต?
JS ควรสร้างเพจบนเว็บไซต์และเรนเดอร์เพจในเว็บแอปพลิเคชันหรือไม่
ฉันควรใช้เทคนิคเช่น PJAX หรือ TurboLinks หรือไม่
อะไรคือความแตกต่างที่แท้จริงระหว่างเว็บไซต์และเว็บแอปพลิเคชัน? ควรจะมีสิ่งหนึ่งเหลืออยู่หรือไม่?

สิ่งต่อไปนี้คือความพยายามของฉันที่จะตอบคำถามเหล่านี้ ฉันพยายามค้นคว้าวิธีใช้ JavaScript จากมุมมองของประสบการณ์ผู้ใช้ (UX) โดยเฉพาะอย่างยิ่งฉันให้ความสนใจเป็นพิเศษกับแนวคิดในการลดเวลาที่ผู้ใช้ใช้ในการรับข้อมูลที่เขาสนใจ เริ่มต้นจากพื้นฐานของเทคโนโลยีเครือข่ายและจบลงด้วยการทำนายพฤติกรรมผู้ใช้ในอนาคต1. การเรนเดอร์เพจบน servertl; DR: การเรนเดอร์บนเซิร์ฟเวอร์ไม่ได้ทำเพื่อ SEO แต่เพื่อประสิทธิภาพ พิจารณาคำขอเพิ่มเติมสำหรับสคริปต์ สไตล์ และคำขอ API ที่ตามมา ในอนาคต ให้พิจารณาใช้วิธี HTTP 2.0 Push
ก่อนอื่น ฉันต้องชี้ให้เห็นข้อผิดพลาดทั่วไปของการแยก “แอปพลิเคชันที่แสดงผลบนเซิร์ฟเวอร์” ออกจาก “แอปพลิเคชันหน้าเดียว” หากเราต้องการบรรลุประสบการณ์ที่ดีที่สุดจากมุมมองของผู้ใช้ เราต้องไม่จำกัดตัวเองอยู่แค่ขีดจำกัดดังกล่าว และละทิ้งทางเลือกหนึ่งเพื่อประโยชน์ของอีกทางเลือกหนึ่ง

ระยะทางระหว่าง สแตนฟอร์ด และ บอสตัน คือ 4320 กม.
ความเร็วแสงในสุญญากาศคือ 300 x 10^6 m/s
ความเร็วแสงในใยแก้วนำแสงอยู่ที่ประมาณ 66% ของความเร็วแสงในสุญญากาศ
ความเร็วแสงในใยแก้วนำแสงคือ 300 x 10^6 เมตร/วินาที * 0.66 = 200 x 10^6 เมตร/วินาที
ความล่าช้าทางเดียวเมื่อส่งสัญญาณไปยังบอสตัน 4320 กม. / 200 x 10^6 เมตร/วินาที = 21.6 มิลลิวินาที
เวลาแฝงไปกลับ 43.2 ms
Ping จาก Stanford ถึง Boston บนอินเทอร์เน็ตสมัยใหม่ใช้เวลาประมาณ 85 ms (...)
ดังนั้นอุปกรณ์อินเทอร์เน็ตสมัยใหม่จึงส่งสัญญาณด้วยความเร็ว 0.5 เท่าของความเร็วแสง
สามารถปรับปรุงผลลัพธ์ที่ระบุของ 85 ms ได้ (และดีขึ้นเล็กน้อยแล้ว) แต่สิ่งสำคัญคือต้องเข้าใจว่ามีขีดจำกัดทางกายภาพเกี่ยวกับความล่าช้าในการส่งข้อมูลผ่านอินเทอร์เน็ตไม่ว่าแบนด์วิดท์บนคอมพิวเตอร์ของผู้ใช้จะเพิ่มขึ้นเท่าใด .

ลองนึกภาพสถานการณ์ที่ผู้ใช้เข้าถึง app.com/orders โดยตรง เมื่อใบสมัครของคุณได้รับและดำเนินการตามคำขอนี้ ก็ถือว่ามีความสำคัญอยู่แล้ว ข้อมูลเกี่ยวกับสิ่งที่ต้องแสดงบนหน้า ตัวอย่างเช่น สามารถโหลดคำสั่งซื้อจากฐานข้อมูลและเพิ่มลงในการตอบกลับได้ แต่สปาส่วนใหญ่ในสถานการณ์นี้ส่งคืนหน้าว่างและแท็ก จากนั้นคุณจะต้องแลกเปลี่ยนคำขออีกครั้งเพื่อรับเนื้อหาของสคริปต์ และอีกครั้งเพื่อรับเนื้อหา

แยกวิเคราะห์ HTML ที่ส่งโดยเซิร์ฟเวอร์สำหรับแต่ละหน้า SPA

อย่างไรก็ตามแม้จะคำนึงถึงแคชแล้ว แต่ก็ยังมีการสูญเสียประสิทธิภาพอยู่บ้างหากเราคำนึงถึงเวลาในการแยกวิเคราะห์และการดำเนินการสคริปต์ ในบทความ “jQuery ใหญ่เกินไปสำหรับมือถือหรือเปล่า” ระบุว่า jQuery เพียงอย่างเดียวสามารถทำให้เบราว์เซอร์มือถือบางตัวช้าลงหลายร้อยมิลลิวินาทีได้อย่างไร

กลไกการควบคุมความแออัดที่เรียกว่า Slow Start ถูกสร้างขึ้นในโปรโตคอล TCP เพื่อส่งข้อมูลเพิ่มขึ้น เซ็กเมนต์- สิ่งนี้มีผลกระทบร้ายแรงสองประการสำหรับ SPA:

1. สคริปต์ขนาดใหญ่ใช้เวลาโหลดนานกว่าที่เห็นมาก ตามที่อธิบายไว้ในหนังสือ "High Performance Browser Networking" โดย Ilya Grigorik ต้องใช้ "การแลกเปลี่ยนแพ็กเก็ตสี่ครั้ง (...) และเวลาในการตอบสนองหลายร้อยมิลลิวินาทีเพื่อเข้าถึงการแลกเปลี่ยนข้อมูล 64 KB ระหว่างไคลเอนต์และเซิร์ฟเวอร์" ตัวอย่างเช่น ในกรณีของการเชื่อมต่ออินเทอร์เน็ตที่รวดเร็วระหว่างลอนดอนและนิวยอร์ก จะใช้เวลา 225 มิลลิวินาที ก่อนที่ TCP จะเข้าถึงขนาดแพ็กเก็ตสูงสุดได้

เซิร์ฟเวอร์สามารถส่งได้กี่ KB ในแต่ละขั้นตอนการเชื่อมต่อ ตามเซ็กเมนต์

เว็บไซต์ที่จัดการเพื่อส่งเนื้อหา (แม้แต่มาร์กอัปพื้นฐานที่ไม่มีข้อมูล) ในหน้าต่างนี้จะปรากฏตอบสนองเป็นพิเศษ ในความเป็นจริง ผู้เขียนแอปพลิเคชันฝั่งเซิร์ฟเวอร์ที่รวดเร็วหลายคนมองว่า JavaScript เป็นสิ่งที่ไม่จำเป็นหรือเป็นสิ่งที่ควรใช้ด้วยความระมัดระวังอย่างยิ่ง ทัศนคตินี้จะแข็งแกร่งยิ่งขึ้นหากแอปพลิเคชันมีแบ็กเอนด์และฐานข้อมูลที่รวดเร็ว และเซิร์ฟเวอร์ตั้งอยู่ใกล้กับผู้ใช้ (CDN)

สำคัญมาก ๆ การประเมินเชิงคุณภาพสคริปต์และสไตล์ โดยคำนึงถึงข้อมูลที่เซิร์ฟเวอร์มีเกี่ยวกับเซสชัน ไคลเอนต์ และ URL สคริปต์ที่เรียงลำดับจะมีความสำคัญต่อ /orders มากกว่าตรรกะของหน้าการตั้งค่าอย่างเห็นได้ชัด อาจไม่ชัดเจนนัก แต่มีความแตกต่างในการโหลด “โครงสร้าง CSS” และ “สไตล์ CSS” อันแรกอาจจำเป็นสำหรับโค้ด JavaScript ดังนั้นจึงจำเป็น การปิดกั้นและอันที่สองถูกโหลดแบบอะซิงโครนัส

ระบบที่ค่อนข้างยืดหยุ่นซึ่งแยกการเรนเดอร์ระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ และจัดเตรียมเครื่องมือสำหรับการโหลดสคริปต์และสไตล์แบบค่อยเป็นค่อยไปอาจทำให้เส้นแบ่งระหว่าง เว็บไซต์และ แอปพลิเคชันเว็บ- ทั้งใช้ URL การนำทาง และแสดงข้อมูลแก่ผู้ใช้ แม้แต่แอปพลิเคชันสเปรดชีตที่แต่เดิมต้องใช้ฟังก์ชันฝั่งไคลเอ็นต์ก็ต้องแสดงข้อมูลที่จำเป็นต้องแก้ไขแก่ลูกค้าก่อน และการทำเช่นนี้ในจำนวนเที่ยวไปกลับน้อยที่สุดก็มีความสำคัญอย่างยิ่ง

ในความคิดของฉัน ข้อเสียด้านประสิทธิภาพที่ใหญ่ที่สุดในระบบยอดนิยมหลายๆ ระบบในปัจจุบันมาจากการสะสมความซับซ้อนในสแต็กที่ก้าวหน้า เมื่อเวลาผ่านไป เทคโนโลยีอย่าง JavaScript และ CSS ได้ถูกเพิ่มเข้ามา ความนิยมของพวกเขาก็ค่อยๆเพิ่มขึ้นเช่นกัน ตอนนี้เท่านั้นที่เราจะซาบซึ้งว่าสามารถใช้แตกต่างกันได้อย่างไร เรากำลังพูดถึงการปรับปรุงโปรโตคอลด้วย (ซึ่งแสดงโดยความคืบหน้าในปัจจุบันของ SPDY และ QUIC) แต่ประโยชน์สูงสุดมาจากการเพิ่มประสิทธิภาพแอปพลิเคชัน

อาจเป็นประโยชน์ในการระลึกถึงการอภิปรายทางประวัติศาสตร์บางส่วนเกี่ยวกับการออกแบบ HTML ยุคแรกและ WWW ตัวอย่างเช่น รายชื่ออีเมลนี้ตั้งแต่ปี 1997 แนะนำให้เพิ่มแท็ก ในรูปแบบ HTML Marc Andreessen ย้ำถึงความสำคัญของการส่งข้อมูลอย่างรวดเร็ว:

“หากจำเป็นต้องรวบรวมเอกสารอย่างรวดเร็ว เอกสารก็อาจซับซ้อนได้เท่าที่เราต้องการ และแม้ว่าความซับซ้อนจะถูกจำกัด เราก็ยังคงประสบปัญหาด้านประสิทธิภาพที่สำคัญจากการจัดโครงสร้างเอกสารในลักษณะนี้ ก่อนอื่น นี่เป็นการฝ่าฝืนหลักการ one-hop ของ WWW ทันที (เช่น IMG ก็ทำลายมันเช่นกัน แต่ด้วยเหตุผลที่เฉพาะเจาะจงมากและในแง่ที่จำกัดมาก) - เราแน่ใจหรือไม่ว่าเราต้องการสิ่งนี้ 2. ตอบสนองทันทีต่อการกระทำของผู้ใช้ DR: JavaScript ช่วยให้คุณสามารถซ่อนเวลาแฝงของเครือข่ายได้อย่างสมบูรณ์ การใช้สิ่งนี้เป็นหลักการออกแบบ เราสามารถลบตัวบ่งชี้การโหลดและข้อความ "กำลังโหลด" เกือบทั้งหมดออกจากแอปพลิเคชันได้ PJAX หรือ TurboLinks ขาดโอกาสในการเพิ่มความเร็วอินเทอร์เฟซแบบอัตนัย
หน้าที่ของเราคือเพิ่มความเร็วในการตอบสนองต่อการกระทำของผู้ใช้ให้สูงสุด ไม่ว่าเราจะใช้ความพยายามมากเพียงใดในการลดจำนวนการกระโดดเมื่อทำงานกับเว็บแอปพลิเคชัน ยังมีสิ่งต่าง ๆ ที่อยู่นอกเหนือการควบคุมของเรา นี่คือขีดจำกัดทางทฤษฎีของความเร็วแสงและค่า ping ขั้นต่ำระหว่างไคลเอนต์และเซิร์ฟเวอร์

ปัจจัยสำคัญคือคุณภาพการสื่อสารที่ไม่สามารถคาดเดาได้ระหว่างไคลเอนต์และเซิร์ฟเวอร์ หากคุณภาพการเชื่อมต่อไม่ดี แพ็กเก็ตจะถูกส่งอีกครั้ง ในกรณีที่ต้องโหลดเนื้อหาแบบไปกลับ 2-3 ครั้ง คุณอาจต้องการเนื้อหามากกว่านี้มาก

สมมติว่านี่เป็น HTML ธรรมดา เอกสารเชื่อมต่อกันด้วยไฮเปอร์ลิงก์หรือแท็ก - หากคุณคลิกที่รายการใดรายการหนึ่ง เบราว์เซอร์จะส่งคำขอเครือข่ายซึ่งใช้เวลานานอย่างไม่อาจคาดเดาได้ จากนั้นรับและประมวลผลข้อมูลที่ได้รับและเข้าสู่สถานะใหม่ในที่สุด

ในช่วงปลายปี พ.ศ. 2547 Google เป็นผู้บุกเบิกการใช้ JavaScript เพื่อให้คำแนะนำแบบเรียลไทม์ขณะพิมพ์คำค้นหา (ที่น่าสนใจคือ คุณลักษณะนี้ได้รับการพัฒนาโดยพนักงานในเวลาว่าง 20% เช่นเดียวกับ Gmail) สิ่งนี้กลายเป็นพื้นฐานสำหรับการเกิดขึ้นของ Ajax:

ดูที่ Google แนะนำ ดูข้อความค้นหาอัปเดตขณะที่คุณพิมพ์เกือบจะในทันที... โดยไม่ทำให้การโหลดหน้าซ้ำล่าช้า Google Suggest และ Google Maps เป็นสองตัวอย่างของแนวทางใหม่ในการสร้างเว็บแอปพลิเคชันที่เรา Adaptive Path เรียกว่า "Ajax"
และในปี 2010 พวกเขาได้เปิดตัวการค้นหาทันใจ ซึ่ง JS มีบทบาทสำคัญ โดยยกเลิกการรีเฟรชหน้าด้วยตนเองโดยสิ้นเชิง และสลับไปใช้มาร์กอัป "ผลการค้นหา" ในการกดแป้นพิมพ์ครั้งแรก ดังที่เห็นในภาพประกอบด้านบน

อีกตัวอย่างที่โดดเด่นของการปรับมาร์กอัปอาจอยู่ในกระเป๋าของคุณ ตั้งแต่แรกสุด วันไอโฟน OS กำหนดให้ผู้เขียนแอปพลิเคชันต้องจัดเตรียมรูปภาพ ค่าเริ่มต้น.pngซึ่งสามารถแสดงบนหน้าจอได้ทันทีขณะที่แอปพลิเคชันกำลังโหลดอยู่

iPhone OS บังคับให้โหลด default.png ก่อนเปิดแอป

เราสามารถบันทึกความพยายามของผู้ใช้ในการดาวน์โหลดไฟล์ได้หลายวิธี: ลากและวาง วางจากบัฟเฟอร์ การเลือกไฟล์ จากนั้น ต้องขอบคุณ HTML5 API ใหม่ที่ทำให้เราสามารถแสดงเนื้อหาราวกับว่ามันถูกดาวน์โหลดไปแล้ว ตัวอย่างของอินเทอร์เฟซประเภทนี้คืองานของเรากับการดาวน์โหลดใน Cloudup สังเกตว่าภาพขนาดย่อของรูปภาพถูกสร้างขึ้นและแสดงผลอย่างไรในทันที:

รูปภาพจะถูกเรนเดอร์และแสดงจนกว่าการโหลดจะเสร็จสิ้น

คำแนะนำเวลาตอบสนองขั้นพื้นฐานยังคงเหมือนเดิมเป็นเวลาสามสิบปี Miller 1968; การ์ดและคณะ 1991:
*0.1 วินาทีคือขีดจำกัดสำหรับผู้ใช้ในการรับรู้การตอบสนองทันที ไม่จำเป็นต้องแสดงข้อมูลเพิ่มเติมใดๆ นอกเหนือจากผลลัพธ์ของการดำเนินการ
* 1.0 วินาทีคือขีดจำกัดความต่อเนื่องของความคิดของผู้ใช้ แม้ว่าเขาจะสังเกตเห็นความล่าช้าก็ตาม โดยทั่วไปแล้ว ไม่จำเป็นต้องมีตัวบ่งชี้เพิ่มเติมสำหรับความล่าช้าที่มากกว่า 0.1 วินาที แต่น้อยกว่า 1.0 วินาที แต่ผู้ใช้จะสูญเสียความรู้สึกในการทำงานกับข้อมูลโดยตรง
* 10 วินาทีคือขีดจำกัดในการรักษาความสนใจของผู้ใช้ต่อบทสนทนา ด้วยเวลาแฝงที่สูงขึ้น ผู้ใช้จะต้องการทำงานอื่นในขณะที่รอการตอบกลับจากคอมพิวเตอร์
น่าเสียดายที่เทคนิคเช่น PJAX หรือ TurboLinks พลาดคุณสมบัติส่วนใหญ่ที่อธิบายไว้ในส่วนนี้ รหัสฝั่งไคลเอ็นต์ไม่ "รู้" เกี่ยวกับสถานะในอนาคตของเพจจนกว่าการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์จะเกิดขึ้น3. การตอบสนองต่อการเปลี่ยนแปลงข้อมูล DR: เมื่อมีการอัพเดตข้อมูลบนเซิร์ฟเวอร์ ลูกค้าควรได้รับแจ้งโดยไม่ชักช้า นี่เป็นรูปแบบหนึ่งของการปรับปรุงประสิทธิภาพการทำงานเมื่อผู้ใช้ไม่ต้องดำเนินการเพิ่มเติม (กด F5 รีเฟรชหน้า) ปัญหาใหม่: การจัดการการเชื่อมต่อ (อีกครั้ง) การกู้คืนสถานะ
หลักการที่สามเกี่ยวข้องกับการตอบสนองของ UI ต่อการเปลี่ยนแปลงข้อมูลที่ต้นทาง ซึ่งโดยทั่วไปคือเซิร์ฟเวอร์ฐานข้อมูลตั้งแต่หนึ่งเครื่องขึ้นไป

UI ของคุณควรอัปเดตโดยอัตโนมัติ

ลองนึกภาพฟีดข่าวของ Facebook ทันทีหลังจากเปิดตัว ซึ่งข้อมูลส่วนใหญ่เผยแพร่จากคอมพิวเตอร์ส่วนบุคคลของผู้ใช้ การเรนเดอร์แบบคงที่นั้นไม่เหมาะสมที่สุด แต่ก็เหมาะสมสำหรับผู้ที่รีเฟรชฟีดของตน เช่น วันละครั้ง

มีประโยชน์ในการจินตนาการ ทั้งหมดข้อมูลที่ส่งถึงผู้ใช้ในรูปแบบ "โต้ตอบ" การซิงโครไนซ์เซสชันและสถานะการอนุญาตเป็นตัวอย่างหนึ่งของแนวทางสากล หากผู้ใช้แอปพลิเคชันของคุณเปิดหลายแท็บพร้อมกัน การสิ้นสุดเซสชันการทำงานในแท็บใดแท็บหนึ่งควรปิดใช้งานการให้สิทธิ์ในแท็บอื่นๆ ทั้งหมดทันที สิ่งนี้นำไปสู่การรักษาความปลอดภัยที่ดีขึ้นและการปกป้องข้อมูลที่เป็นความลับที่ดีขึ้นอย่างหลีกเลี่ยงไม่ได้ โดยเฉพาะอย่างยิ่งในสถานการณ์ที่มีคนหลายคนสามารถเข้าถึงอุปกรณ์เดียวกัน

แต่ละหน้าตอบสนองต่อสถานะเซสชันและสถานะการอนุญาต

4. การควบคุมการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์ tl;DR: ตอนนี้เราสามารถปรับแต่งการแลกเปลี่ยนข้อมูลกับเซิร์ฟเวอร์ได้แล้ว ตรวจสอบให้แน่ใจว่าได้จัดการกับข้อผิดพลาด ลองส่งคำขอไปยังไคลเอ็นต์อีกครั้ง ซิงค์ข้อมูลในเบื้องหลัง และเก็บแคชไว้แบบออฟไลน์
เมื่อเว็บเกิดขึ้น การสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ถูกจำกัดด้วยหลายวิธี:

การคลิกลิงก์จะเป็นการส่ง GET เพื่อดึงหน้าใหม่และแสดงผล

การส่งแบบฟอร์มจะส่ง POST หรือ GET ตามด้วยการแสดงหน้าใหม่

การแทรกรูปภาพหรือวัตถุจะส่ง GET แบบอะซิงโครนัสตามด้วยการแสดงผล

อาจเป็นสิ่งประดิษฐ์ที่น่ารำคาญที่สุดของเว็บเก่า

คำเตือนก่อนยกเลิกการโหลด

5. อย่าทำลายประวัติศาสตร์ ปรับปรุงมัน tl; DR: หากเบราว์เซอร์ไม่จัดการ URL และประวัติ เราจะประสบปัญหาใหม่ ตรวจสอบให้แน่ใจว่าคุณมีคุณสมบัติตรงตามลักษณะการเลื่อนที่คาดไว้ บันทึกแคชของคุณเองเพื่อรับข้อเสนอแนะอย่างรวดเร็ว
นอกจากการส่งแบบฟอร์มแล้ว เมื่อใช้เฉพาะไฮเปอร์ลิงก์ในเว็บแอปพลิเคชัน เราก็จะได้อย่างสมบูรณ์ การนำทางที่ใช้งานได้"ไปข้างหน้า/ย้อนกลับ" ในเบราว์เซอร์

แต่ยังมีอีกด้านหนึ่งของเหรียญ นั่นก็คือโอกาส ทำให้ดีขึ้นประวัติการท่องเว็บ ซึ่งตอนนี้เราควบคุมโดยใช้ JavaScript

ความเป็นไปได้อย่างหนึ่งที่เรียกว่า Fast Back โดย Daniel Pipius:

ปุ่มย้อนกลับควรทำงานได้อย่างรวดเร็ว ผู้ใช้ไม่คาดหวังการเปลี่ยนแปลงข้อมูลมากเกินไป
มันเหมือนกับการใช้ปุ่มย้อนกลับเหมือนปุ่มจากเว็บแอปพลิเคชันและใช้หลักการ #2 กับมัน: ตอบสนองต่อการกระทำของผู้ใช้ทันที- สิ่งสำคัญคือคุณมีโอกาสที่จะตัดสินใจว่าจะแคชหน้าก่อนหน้าอย่างไรและแสดงบนหน้าจอทันที จากนั้นคุณสามารถใช้หลักการ #3 แล้วแจ้งให้ผู้ใช้ทราบเมื่อมีข้อมูลใหม่มาถึงหน้านั้น

การทำงานของปุ่ม "ย้อนกลับ" ไม่ถูกต้อง

อีกวิธีหนึ่งในการทำลายการนำทางคือการละเว้นหน่วยความจำสถานะการเลื่อน เป็นอีกครั้งที่เพจที่ไม่ใช้ JS และการจัดการประวัติด้วยตนเองน่าจะไม่มีปัญหาที่นี่ แต่จะมีเพจแบบไดนามิก ฉันทดสอบฟีดข่าวที่ใช้ JavaScript ที่ได้รับความนิยมมากที่สุดสองรายการบนอินเทอร์เน็ต: Twitter และ Facebook ทั้งสองมีความจำเสื่อมแบบเลื่อน

การเปลี่ยนประเภทความคิดเห็นจะต้องบันทึกไว้ในประวัติ

6. การอัปเดตโค้ดผ่านข้อความพุช DR: การส่งข้อมูลผ่านข้อความพุชเพียงอย่างเดียวนั้นไม่เพียงพอ คุณต้องใช้รหัสด้วย หลีกเลี่ยงข้อผิดพลาด API และปรับปรุงประสิทธิภาพ ใช้ DOM ไร้สถานะเพื่อออกแบบแอปพลิเคชันของคุณใหม่โดยไม่ยุ่งยาก
เป็นสิ่งสำคัญอย่างยิ่งที่แอปพลิเคชันของคุณตอบสนองต่อการเปลี่ยนแปลงในโค้ด

ประการแรก จะช่วยลดจำนวนข้อผิดพลาดที่อาจเกิดขึ้นและเพิ่มความน่าเชื่อถือ หากคุณได้ทำการเปลี่ยนแปลงที่สำคัญกับ API แบ็กเอนด์ ต้องอัพเดตโค้ดของโปรแกรมไคลเอนต์ มิฉะนั้นลูกค้าอาจไม่ยอมรับข้อมูลใหม่หรืออาจส่งข้อมูลในรูปแบบที่เข้ากันไม่ได้

เหตุผลที่สำคัญไม่แพ้กันคือการปฏิบัติตามหลักการข้อที่ 3 หากอินเทอร์เฟซของคุณอัปเดตตัวเอง ก็มีเหตุผลเพียงเล็กน้อยที่ผู้ใช้จะต้องโหลดหน้าเว็บซ้ำด้วยตนเอง

ตามหลักการแล้ว เราควรจะสามารถเปลี่ยนแปลงโค้ดแบบโมดูลาร์ได้ ไม่จำเป็นต้องสร้างการเชื่อมต่อกับซ็อกเก็ตอีกครั้ง ตัวอย่างเช่น หากเป็นไปได้ที่จะอัปเดตโค้ดของส่วนประกอบที่จำเป็น สถาปัตยกรรมในอุดมคติสำหรับการอัพเดตพุชโค้ดจึงเป็นแบบโมดูลาร์

แต่ปัญหาเกิดขึ้นทันทีในการประเมินโมดูลโดยไม่มีผลข้างเคียงที่ไม่พึงประสงค์ สถาปัตยกรรมแบบที่ React นำเสนอเหมาะที่สุดที่นี่ หากมีการอัปเดตโค้ดของส่วนประกอบ ตรรกะของส่วนประกอบนั้นสามารถดำเนินการอีกครั้งและ DOM จะได้รับการอัปเดต อ่านคำอธิบายของ Dan Abramov เกี่ยวกับแนวคิดนี้

7. การทำนายพฤติกรรม tl; DR: ความล่าช้าเชิงลบ
แอปพลิเคชัน JavaScript สมัยใหม่อาจมีกลไกในการทำนายการกระทำของผู้ใช้

ปลั๊กอิน jQuery ทำนายเส้นทางของเมาส์

เว็บยังคงเป็นสื่อกลางในการส่งข้อมูลที่หลากหลายที่สุด เรายังคงเพิ่มไดนามิกให้กับเพจของเรา และก่อนที่จะนำไปใช้ เราต้องแน่ใจว่าเรารักษาหลักการสำคัญของเว็บที่เราได้รับมา

JavaScript มีคุณสมบัติพิเศษใหม่ให้ หากเทคโนโลยีเหล่านี้มีการใช้กันอย่างแพร่หลาย พวกเขาจะมอบประสบการณ์ที่ดีที่สุดให้กับผู้ใช้แพลตฟอร์มที่เสรีที่สุดเท่าที่มีอยู่ - WWW

แท็ก:

เวลาแฝง
ผลงาน
พีแจ็กซ์
เทอร์โบลิงค์

เพิ่มแท็กในบทความนี้

เผยเเพร่โดย

แผนกนักพัฒนา Microsoft, ทีมพัฒนา .NET และ วิชวลสตูดิโอทีมผลิตภัณฑ์ Microsoft Developer Division, .NET และ Visual Studio

แผนกหนึ่งของ Microsoft Corporation

วิธีหนึ่งของ Microsoft วิธีหนึ่งของ Microsoft

เรดมันด์ วอชิงตัน 98052-6399

ห้ามทำซ้ำหรือส่งต่อหนังสือเล่มนี้ทั้งหมดหรือบางส่วน ในรูปแบบใดๆ หรือโดยวิธีการใดๆ โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรจากผู้จัดพิมพ์ ห้ามทำซ้ำหรือส่งต่อเนื้อหาส่วนใดส่วนหนึ่งของหนังสือเล่มนี้ในรูปแบบใด ๆ หรือโดยวิธีการใด ๆ โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษรจากผู้จัดพิมพ์

ตัวอย่างบางส่วนที่ให้ไว้ในหนังสือเล่มนี้มีวัตถุประสงค์เพื่อการอธิบายเท่านั้นและเป็นเพียงเรื่องสมมติ ตัวอย่างบางส่วนที่ปรากฎในที่นี้จัดทำขึ้นเพื่อประกอบการอธิบายเท่านั้นและเป็นเพียงเรื่องสมมติ ความคล้ายคลึงกับชื่อจริง ผู้คน และวัตถุอื่นๆ ทั้งหมดนั้นเกิดขึ้นโดยไม่ได้ตั้งใจและเกิดขึ้นโดยบังเอิญ ไม่มีการเชื่อมโยงหรือความเชื่อมโยงที่แท้จริงที่มีจุดมุ่งหมายหรือไม่ควรอนุมาน

Microsoft และเครื่องหมายการค้าที่แสดงอยู่ในหน้าเครื่องหมายการค้าที่ https://www.microsoft.com เป็นเครื่องหมายการค้าของกลุ่มบริษัท Microsoft Microsoft และเครื่องหมายการค้าที่แสดงอยู่ที่ https://www.microsoft.com บนเว็บเพจ “เครื่องหมายการค้า” เป็นเครื่องหมายการค้าของกลุ่มบริษัท Microsoft

Mac และ macOS เป็นเครื่องหมายการค้าของ Apple Inc. Mac และ macOS เป็นเครื่องหมายการค้าของ Apple Inc.

จดทะเบียนโลโก้วาฬนักเทียบท่าแล้ว เครื่องหมายการค้านักเทียบท่าอิงค์ ใช้โดยได้รับอนุญาต โลโก้วาฬ Docker เป็นเครื่องหมายการค้าจดทะเบียนของ Docker, Inc. ใช้โดยได้รับอนุญาต

ชื่อและโลโก้อื่นๆ ทั้งหมดเป็นทรัพย์สินของเจ้าของที่เกี่ยวข้อง เครื่องหมายและโลโก้อื่นๆ ทั้งหมดเป็นทรัพย์สินของเจ้าของที่เกี่ยวข้อง

Steve Smith - สถาปนิกและผู้ฝึกสอนซอฟต์แวร์ - Ardalis.com Steve "ardalis" Smith - สถาปนิกและผู้ฝึกสอนซอฟต์แวร์ - Ardalis.com

บรรณาธิการ: บรรณาธิการ:

ไมร่า เวนเซล ไมร่า เวนเซล

การแนะนำ

NET Core และ ASP.NET Core มีข้อดีหลายประการเหนือการพัฒนา .NET แบบดั้งเดิม .NET Core และ ASP.NET Core มีข้อดีหลายประการเหนือการพัฒนา .NET แบบดั้งเดิม คุณควรใช้ .NET Core สำหรับแอปพลิเคชันเซิร์ฟเวอร์ของคุณ หากบางส่วนหรือทั้งหมดต่อไปนี้มีความสำคัญต่อความสำเร็จของแอปพลิเคชันของคุณ:

รองรับแพลตฟอร์มต่างๆ การสนับสนุนข้ามแพลตฟอร์ม

การใช้ไมโครเซอร์วิส การใช้ไมโครเซอร์วิส

การใช้คอนเทนเนอร์นักเทียบท่า การใช้คอนเทนเนอร์นักเทียบท่า

ข้อกำหนดสำหรับประสิทธิภาพและความสามารถในการปรับขนาดที่สูง ข้อกำหนดด้านประสิทธิภาพและความสามารถในการปรับขนาดสูง

การกำหนดเวอร์ชันขนานของแอปพลิเคชัน .NET บนเซิร์ฟเวอร์เดียว การกำหนดเวอร์ชันแบบเคียงข้างกันของเวอร์ชัน .NET ตามแอปพลิเคชันบนเซิร์ฟเวอร์เดียวกัน

ข้อกำหนดเหล่านี้ได้รับการสนับสนุนโดยแอปพลิเคชัน .NET มาตรฐานจำนวนมาก แต่แพลตฟอร์ม ASP.NET Core และ .NET Core ที่ได้รับการปรับให้เหมาะสมจะให้การสนับสนุนขั้นสูงสำหรับสถานการณ์ข้างต้น แอปพลิเคชัน .NET แบบดั้งเดิมสามารถรองรับข้อกำหนดเหล่านี้ได้หลายอย่าง แต่ ASP.NET Core และ .NET Core ได้รับการปรับให้เหมาะสมเพื่อให้การสนับสนุนที่ได้รับการปรับปรุงสำหรับสถานการณ์ข้างต้น

องค์กรจำนวนมากขึ้นเรื่อยๆ เลือกที่จะโฮสต์เว็บแอปพลิเคชันของตนในระบบคลาวด์โดยใช้บริการต่างๆ เช่น Microsoft Azure องค์กรจำนวนมากขึ้นเรื่อยๆ เลือกที่จะโฮสต์เว็บแอปพลิเคชันของตนในระบบคลาวด์โดยใช้บริการต่างๆ เช่น Microsoft Azure คุณควรพิจารณาโฮสต์แอปพลิเคชันของคุณในระบบคลาวด์หากสิ่งต่อไปนี้มีความสำคัญต่อแอปพลิเคชันหรือองค์กรของคุณ:

ลดการลงทุนในศูนย์ข้อมูล (ฮาร์ดแวร์ ซอฟต์แวร์ สถานที่ สาธารณูปโภค, การจัดการเซิร์ฟเวอร์ ฯลฯ) การลงทุนที่ลดลงในต้นทุนศูนย์ข้อมูล (ฮาร์ดแวร์ ซอฟต์แวร์ พื้นที่ ยูทิลิตี้ การจัดการเซิร์ฟเวอร์ ฯลฯ)

ราคาที่ยืดหยุ่น (การชำระเงินสำหรับทรัพยากรที่ใช้จริง ไม่ใช่ทรัพยากรที่ไม่ได้ใช้งาน) ราคาที่ยืดหยุ่น (จ่ายตามการใช้งาน ไม่ใช่ความจุที่ไม่ได้ใช้งาน)

ความน่าเชื่อถือที่ยอดเยี่ยม ความน่าเชื่อถือสูงสุด

ปรับปรุงความคล่องตัวของแอปพลิเคชัน เปลี่ยนสถานที่และวิธีปรับใช้ได้อย่างง่ายดาย ปรับปรุงความคล่องตัวของแอป เปลี่ยนสถานที่และวิธีปรับใช้แอปของคุณได้อย่างง่ายดาย

ความจุที่ยืดหยุ่น ปรับขนาดได้ตามความต้องการที่แท้จริง ความจุที่ยืดหยุ่น ขยายหรือลดขนาดตามความต้องการที่แท้จริง

การสร้างแอปพลิเคชันเว็บด้วย ASP.NET Core ที่โฮสต์บน Azure มีข้อได้เปรียบทางการแข่งขันมากกว่าทางเลือกแบบเดิมๆ มากมาย การสร้างแอปพลิเคชันเว็บด้วย ASP.NET Core ซึ่งโฮสต์ใน Azure มอบข้อได้เปรียบทางการแข่งขันมากมายเหนือทางเลือกแบบเดิม ASP.NET Core ได้รับการปรับให้เหมาะสมสำหรับแนวทางปฏิบัติในการพัฒนาเว็บไซต์สมัยใหม่และสถานการณ์การโฮสต์บนคลาวด์ ASP.NET Core ได้รับการปรับให้เหมาะสมสำหรับแนวทางปฏิบัติในการพัฒนาเว็บแอปพลิเคชันสมัยใหม่และสถานการณ์การโฮสต์บนคลาวด์ ในบทช่วยสอนนี้ คุณจะได้เรียนรู้วิธีการออกแบบแอปพลิเคชัน ASP.NET Core เพื่อใช้ประโยชน์จากความสามารถเหล่านี้อย่างเต็มที่ ในคู่มือนี้ คุณจะได้เรียนรู้วิธีการออกแบบแอปพลิเคชัน ASP.NET Core ของคุณเพื่อใช้ประโยชน์จากความสามารถเหล่านี้ให้เกิดประโยชน์สูงสุด

วัตถุประสงค์

เอกสารนี้คือ คู่มือฉบับสมบูรณ์เกี่ยวกับการสร้างสรรค์ เสาหินเว็บแอปพลิเคชันที่ใช้ ASP.NET Core และ Azure คู่มือนี้ให้คำแนะนำตั้งแต่ต้นจนจบเกี่ยวกับการสร้าง เสาหินเว็บแอปพลิเคชันที่ใช้ ASP.NET Core และ Azure ในบริบทนี้ เสาหินหมายความว่าแอปพลิเคชันเหล่านี้ถูกปรับใช้เป็นหน่วยเดียว แทนที่จะเป็นชุดของบริการและแอปพลิเคชันเชิงโต้ตอบ ในบริบทนี้ "เสาหิน" หมายถึงข้อเท็จจริงที่ว่าแอปพลิเคชันเหล่านี้ใช้งานเป็นหน่วยเดียว ไม่ใช่ชุดของบริการและแอปพลิเคชันที่มีการโต้ตอบ

คู่มือนี้เป็นส่วนเสริมของไมโครเซอร์วิส" .สุทธิ. สถาปัตยกรรมสำหรับแอปพลิเคชัน .NET ที่มีคอนเทนเนอร์"โดยมุ่งเน้นไปที่ Docker, ไมโครเซอร์วิส และการปรับใช้คอนเทนเนอร์สำหรับการโฮสต์แอปพลิเคชันระดับองค์กร คู่มือนี้เป็นส่วนเสริมของ " .NET ไมโครเซอร์วิส สถาปัตยกรรมสำหรับแอปพลิเคชัน Containerized .NET" ซึ่งมุ่งเน้นไปที่ Docker, Microservices และการปรับใช้คอนเทนเนอร์เพื่อโฮสต์แอปพลิเคชันระดับองค์กรมากขึ้น

.NET ไมโครเซอร์วิส .NET ไมโครเซอร์วิส สถาปัตยกรรม .NET สำหรับคอนเทนเนอร์ แอพพลิเคชั่น NET

e-book
https://aka.ms/MicroservicesEbook
แอปพลิเคชันตัวอย่าง
https://aka.ms/microservicesarchitecture

ใครควรใช้คู่มือนี้

คู่มือนี้มีไว้สำหรับนักพัฒนา ผู้จัดการฝ่ายพัฒนา และสถาปนิกที่สนใจสร้างแอปพลิเคชันเว็บสมัยใหม่โดยใช้เทคโนโลยีและบริการของ Microsoft ในระบบคลาวด์เป็นหลัก ผู้ชมสำหรับคู่มือนี้ส่วนใหญ่เป็นนักพัฒนา หัวหน้าฝ่ายพัฒนา และสถาปนิกที่สนใจสร้างแอปพลิเคชันเว็บสมัยใหม่โดยใช้เทคโนโลยีและบริการของ Microsoft ในระบบคลาวด์

ผู้ชมรองคือผู้ที่รับผิดชอบในการนำไปใช้ โซลูชั่นทางเทคนิคผู้ที่คุ้นเคยกับ ASP.NET หรือ Azure อยู่แล้ว และต้องการข้อมูลเกี่ยวกับการอัพเกรดเป็น ASP.NET Core เพื่อพัฒนาโครงการใหม่และสนับสนุนโครงการที่มีอยู่ ผู้ชมรองคือผู้มีอำนาจตัดสินใจทางเทคนิคที่คุ้นเคยกับ ASP.NET หรือ Azure อยู่แล้ว และกำลังมองหาข้อมูลว่าควรอัปเกรดเป็น ASP.NET Core สำหรับโปรเจ็กต์ใหม่หรือโปรเจ็กต์ที่มีอยู่หรือไม่

คุณสามารถใช้คู่มือนี้ได้อย่างไร

คู่มือนี้ได้รับการย่อเป็นเอกสารขนาดสั้นซึ่งเน้นไปที่การสร้างแอปพลิเคชันเว็บโดยใช้เทคโนโลยี .NET และ Windows Azure ที่ทันสมัย คู่มือนี้ย่อเป็นเอกสารขนาดค่อนข้างเล็กซึ่งมุ่งเน้นที่การสร้างแอปพลิเคชันเว็บด้วยเทคโนโลยี .NET ที่ทันสมัย และ Windows Azure ดังนั้น เพื่อให้เข้าใจพื้นฐานเกี่ยวกับการใช้งานเหล่านี้และเข้าใจคำแนะนำทางเทคนิคที่เกี่ยวข้อง โปรดอ่านเอกสารทั้งหมด ด้วยเหตุนี้จึงสามารถอ่านได้ทั้งหมดเพื่อเป็นรากฐานในการทำความเข้าใจการใช้งานดังกล่าวและข้อควรพิจารณาทางเทคนิค คู่มือนี้พร้อมกับตัวอย่างการใช้งาน อาจเป็นจุดเริ่มต้นที่ดีหรือเป็นเอกสารอ้างอิงที่เป็นประโยชน์ คู่มือนี้พร้อมทั้งการใช้งานตัวอย่างสามารถใช้เป็นจุดเริ่มต้นหรือข้อมูลอ้างอิงได้ ใช้แอปพลิเคชันตัวอย่างที่ให้มาเป็นเทมเพลตสำหรับแอปพลิเคชันของคุณเอง หรือเพื่อดูว่าคุณสามารถจัดระเบียบส่วนประกอบของแอปพลิเคชันได้อย่างไร ใช้แอปพลิเคชันตัวอย่างที่เกี่ยวข้องเป็นเทมเพลตสำหรับแอปพลิเคชันของคุณเอง หรือเพื่อดูว่าคุณจะจัดระเบียบส่วนประกอบของแอปพลิเคชันของคุณอย่างไร เมื่อตัดสินใจว่าจะใช้ตัวเลือกเหล่านี้กับแอปพลิเคชันของคุณหรือไม่ คุณสามารถดูหลักการและทิศทางทางสถาปัตยกรรมที่อธิบายไว้ในคู่มือได้ตลอดเวลา และความสามารถทางเทคโนโลยี โปรดดูหลักการและความครอบคลุมของตัวเลือกสถาปัตยกรรมและเทคโนโลยี และข้อควรพิจารณาในการตัดสินใจเมื่อคุณชั่งน้ำหนักตัวเลือกเหล่านี้สำหรับการใช้งานของคุณเอง

หากจำเป็น คุณสามารถแนะนำคู่มือนี้ให้กับสมาชิกในทีมของคุณ เพื่อให้พวกเขาตระหนักถึงประเด็นสำคัญทั้งหมดเช่นกัน โปรดส่งต่อคู่มือนี้ให้กับทีมของคุณเพื่อช่วยให้แน่ใจว่ามีความเข้าใจร่วมกันเกี่ยวกับข้อควรพิจารณาและโอกาสเหล่านี้ ฉันตก ผู้สนใจจะใช้ชุดคำศัพท์ทั่วไปและยึดตามหลักการพื้นฐาน รูปแบบสถาปัตยกรรมและแนวปฏิบัติจะถูกนำไปใช้อย่างสม่ำเสมอมากขึ้น การให้ทุกคนทำงานจากชุดคำศัพท์และหลักการพื้นฐานที่เหมือนกันช่วยให้มั่นใจได้ถึงการประยุกต์ใช้รูปแบบและแนวปฏิบัติทางสถาปัตยกรรมที่สอดคล้องกัน

อ้างอิง