การออกแบบที่ตอบสนองไม่เพียงพอ เราต้องการประสิทธิภาพที่ตอบสนอง

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

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

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

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

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

กระบวนทัศน์การออกแบบครั้งแรกของอิฐ

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

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

ยากแค่ไหนสำหรับเราที่จะใช้เลย์เอาต์ sub-mobile-first ที่จะให้ข้อมูลนั้นแก่อุปกรณ์ที่ต่ำกว่าเกณฑ์ความสามารถและประสิทธิภาพที่แน่นอนเท่านั้น?

การปรับปรุงอย่างสง่างาม

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

เนื่องจากฟังก์ชันนี้มีให้ใช้งานมากขึ้นเรื่อยๆ ความจำเป็นในการคิดเกี่ยวกับเรื่องนี้ (ไม่ต้องพูดถึง) ก็ยิ่งห่างไกลมากขึ้นเรื่อยๆ

จากจุดยืนของบทความนี้สามารถแบ่งออกได้ดังนี้:

ความเสื่อมโทรมที่ไม่สง่างาม: หากไม่มีฟีเจอร์ใดพร้อมใช้งาน การนำไปใช้งานจะล้มเหลวในลักษณะที่ทำให้ใช้งานไม่ได้หรือใช้งานไม่ได้ในลักษณะที่ห้ามปราม

การลดระดับลงอย่างสง่างาม: หากฟีเจอร์ไม่พร้อมใช้งาน จะล้มเหลวในลักษณะที่ยังคงใช้งานได้ที่ยอมรับได้

การปรับปรุงที่ไม่สง่างาม: หากคุณลักษณะนี้ไม่พร้อมใช้งาน คุณลักษณะนี้จะถูกจำลองโดยโพลีฟิลหรือชิม

ที่นั่นแก้ปัญหาได้

เว้นแต่คุณจะพิจารณาประสิทธิภาพของอุปกรณ์ระดับล่างที่เหมือนกันเหล่านั้น

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

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

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

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

ทำได้ แต่จำเป็นต้องทำไหม

แนวทางปฏิบัติที่ดีที่สุดอีกประการหนึ่งสำหรับการพัฒนาเว็บคือการตรวจสอบว่ามีฟีเจอร์บนอุปกรณ์หรือไม่ก่อนเปิดใช้งาน

อย่างไรก็ตาม ให้คำนึงว่าคุณสามารถติดตั้ง Google Chrome เวอร์ชันล่าสุดบนโทรศัพท์ Android รุ่นเก่าของคุณได้ และจะอ้างว่าสามารถเรียกใช้ภาพเคลื่อนไหว CSS, WebGL, เอฟเฟกต์พารัลแลกซ์พื้นหลัง และฟังก์ชันอื่นๆ ได้อีกมากมาย แต่มันทำไม่ได้ จริงๆ มากเสียจนเบราว์เซอร์ขัดข้องและอุปกรณ์ทั้งหมดจะไม่ตอบสนองจนถึงจุดที่จะต้องรีบูตเพื่อควบคุมอีกครั้ง

ปัญหานี้เพิ่งเริ่มส่งผลกระทบต่อแอปพลิเคชัน Android ครั้งใหญ่ (จากมุมมองของผู้ใช้) การลดลงที่เห็นได้ชัดเจนที่สุดประการหนึ่งในแง่นี้ส่งผลต่อการอัปเกรดแอป Google Talk/แฮงเอาท์ ที่เปลี่ยนบริการจากแอปพลิเคชันแชทที่มีขนาดเล็กที่สุดที่มีให้ใช้งานในแอปพลิเคชันที่แทบจะใช้งานไม่ได้เนื่องจากปัญหาด้านประสิทธิภาพในอุปกรณ์รุ่นเก่า (เพื่อเน้นย้ำประเด็นนี้อีกครั้ง: "เก่ากว่า" ในที่นี้หมายความว่าคุณยังสามารถซื้อจากชั้นวางซึ่งเป็นสินค้าใหม่เอี่ยมได้ในเกือบทุกร้าน) ปัญหาเดียวกันนี้ส่งผลต่อแอป YouTube และแอป Twitter (จากประสบการณ์ของผม) และอีกหลายปัญหาอย่างเห็นได้ชัด

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

ให้ผู้ใช้เลือกไม่รับ Bleeding Edge

คุณเคยพบว่าตัวเองพยายามใช้ Gmail จากอุปกรณ์เครื่องเก่าหรือผ่านการเชื่อมต่อที่ไม่ดีหรือไม่? ลิงก์ "โหลด HTML พื้นฐาน" นั้นมีประโยชน์แน่นอน

เหตุใดหน้าร้านออนไลน์ที่เน้นการสัมผัสที่ล้ำสมัย ตอบสนอง เคลื่อนไหว และเน้นการสัมผัสจึงไม่มีฟังก์ชันดังกล่าว

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

คุณต้องการห้องสมุดทั้งหมดหรือไม่?

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

เมื่อเร็ว ๆ นี้ ฉันได้ติดตามจำนวนฟังก์ชันที่ฉันใช้จริงเมื่อรวมไลบรารี่ และเครื่องมือที่ฉันใช้บ่อยที่สุดคือ jQuery บ่อยครั้งที่ฉันพบว่าฉันใช้ฟังก์ชันเพียงหนึ่งหรือสองฟังก์ชัน (เช่น $.extend หรือ $.ready) หรือที่แย่กว่านั้นคือ ฉันใช้มันเพื่อรับองค์ประกอบตามคลาสหรือ ID บางครั้งฉันปล่อยไว้อย่างนั้น บางครั้งฉันย้อนกลับไปดูโค้ดเพื่อลบหรือแยกการพึ่งพา

คงจะดีไม่น้อยถ้าคุณสามารถวิเคราะห์ได้โดยอัตโนมัติว่าห้องสมุดมีการใช้งานและลดน้ำหนักมากน้อยเพียงใดตามผลลัพธ์ที่ได้?

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

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

สิ่งที่จำเป็นต้องมีคือไลบรารีเวอร์ชันสำหรับการพัฒนาเท่านั้น ซึ่งผ่านการทดสอบหน่วยของฟังก์ชันการทำงานที่ขึ้นต่อกัน เปิดใช้งานการติดตามคุณลักษณะที่ใช้และแสดงผลการพึ่งพาขั้นต่ำหรืออย่างน้อยในระดับการใช้งาน (เช่น ขอให้ฉันรวม jQuery ไว้เป็น 8% ของฟังก์ชันการทำงานหรือ 80%) เอาต์พุตการพึ่งพาสามารถใช้เพื่อเลือกเชอร์รี่ รวม และลดเอาต์พุตสำหรับการผลิต

แต่ฉันจะทำอะไรกับมันได้บ้าง?

ก่อนอื่น ให้ เข้าประเด็น คิดเกี่ยวกับเรื่องนี้ พูดคุยกับเพื่อนๆ ของคุณ และพยายามระบุปัญหาในสถานการณ์จริง

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

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

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

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

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

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