เมื่อเร็ว ๆ นี้ฉันเจอปัญหามากมาย เว็บไซต์ที่ตอบสนอง ด้วย มาก ปัญหาด้านประสิทธิภาพ สำหรับปัญหาส่วนใหญ่เห็นได้ชัดว่าปัญหาเหล่านี้แทบไม่มีประโยชน์อะไรเลยนอกจากสมาร์ทโฟนรุ่นล่าสุด พิจารณาจากข้อเท็จจริงที่ว่า การตอบสนอง เป็นแนวคิดที่มีจุดมุ่งหมายเพื่อเข้าถึงไฟล์ กว้างขึ้น ผู้ชมดูเหมือนจะต่อต้าน
ผู้มีส่วนร่วมมากที่สุดในปัญหานี้คือกระบวนทัศน์การออกแบบเดสก์ท็อปแรกที่ยังคงแพร่หลายอยู่ การคิดจากมุมมองของอุปกรณ์เคลื่อนที่เป็นอันดับแรกดูเหมือนจะช่วยแก้ปัญหาได้ แต่เพียงอย่างเดียวไม่ได้รับประกันประสิทธิภาพที่น่าพอใจ ดูเหมือนเราทุกคนจะพึ่งพาความเสื่อมโทรมที่สง่างามมากเกินไปหรือน้อยเกินไป เราพึ่งพา shims และ polyfills เพื่อเปิดใช้งานฟังก์ชันที่ขาดหายไป เราพึ่งพาไลบรารีเพื่อให้สามารถพัฒนาได้อย่างรวดเร็วและพร้อมสนับสนุนเมื่อความเข้ากันได้ของเบราว์เซอร์เป็นปัญหา
นักฆ่าโทรศัพท์บนเว็บไซต์ที่ไม่ตอบสนองและปลอมตัว ทวีต
'กังวลทำไม?' คุณอาจถาม “ ผู้เยี่ยมชมส่วนใหญ่ของเรามีสมาร์ทโฟนประสิทธิภาพสูงที่ใช้ระบบปฏิบัติการเวอร์ชันล่าสุด พวกเขาสามารถจัดการไซต์ของเราได้ การวิเคราะห์บอกเราเช่นนั้น”
ฉันขอโทษเกี่ยวกับการโต้แย้งของชายฟาง แต่ฉันคิดว่ามันสมควรที่จะพูดออกไปดัง ๆ ว่าคนที่ สามารถ ใช้ไซต์ของคุณจะเป็นผู้ใช้ส่วนใหญ่ของคุณ หากคุณไม่เห็น Android 2.3 ในการวิเคราะห์นั่นหมายความว่าไม่มีผู้ใช้อุปกรณ์เหล่านั้นใช่หรือไม่ หรือหมายความว่าไซต์ของคุณไม่มีอะไรให้ผู้ใช้เหล่านั้น? พิจารณาว่าอุปกรณ์จำนวนมากในยุคนั้นยังคงอยู่บนชั้นวางซึ่งถูกซื้อใหม่แม้กระทั่งในปัจจุบัน คุณไม่ควรมองข้ามสิ่งนี้ไปโดยสิ้นเชิงว่าเป็นเทคโนโลยีแบบเมื่อก่อน
ดังนั้นฉันจึงอยากพูดถึงกรณีที่เหมาะและเป้าหมายที่แท้จริงของการพัฒนาเว็บ และเกี่ยวกับแนวปฏิบัติและกระบวนทัศน์ที่ทำให้เราเข้าใกล้เป้าหมายเหล่านั้นมากขึ้น
Brick-First Design Paradigm
ส่วนสำคัญของยอดขายโทรศัพท์ประจำปียังคงถูกนำมาใช้โดยฟีเจอร์โฟน ประชากรส่วนใหญ่ไม่ได้ซื้อโทรศัพท์ทุกปี แต่ก็ยังมีอุปกรณ์ที่สามารถใช้งานเว็บได้อยู่ในครอบครอง เพิ่มตัวเลขเหล่านี้ในสมาร์ทโฟนรุ่นล่าสุดที่ยังคงใช้งานอยู่เพิ่มจุดไฟและอุปกรณ์กึ่งรองรับเว็บอื่น ๆ (อุปกรณ์ WAP ทีวีเครื่องปิ้งขนมปังเสื้อยืดและอิฐ) เพิ่มทั้งหมดและคุณอาจได้รับผลรวมที่น่าทึ่ง
คุณจะไม่เห็นสิ่งเหล่านี้ในการวิเคราะห์ของคุณเว้นแต่จะใช้งานได้ที่นั่น ทวีต
พิจารณากรณีการใช้งานสำหรับผู้ชมกลุ่มนี้ พวกเขาจะไม่อ่านบทความยาว ๆ เรียกดูและค้นคว้าเกี่ยวกับอุปกรณ์ของตน แต่พวกเขาอาจต้องเผชิญกับความน่ากลัวของการพยายามพิมพ์ URL บนแป้นพิมพ์ตัวเลขและนำทางไปยังหน้าเว็บโดยใช้ปุ่มทิศทางเพื่อไปยังหมายเลขโทรศัพท์หรือตรวจสอบที่อยู่อีกครั้งได้ทันที
แล้วมันยากแค่ไหนที่เราจะใช้เลย์เอาต์ย่อยสำหรับอุปกรณ์เคลื่อนที่ก่อนที่จะให้ข้อมูลนั้นเฉพาะกับอุปกรณ์ที่มีความสามารถและประสิทธิภาพต่ำกว่าเกณฑ์ที่กำหนด
ใช้เวลาเรียนนานแค่ไหนเพื่อรับรอง aws
การปรับปรุงที่สง่างาม
ด้วยการลดทอนอย่างสง่างามเป็นแนวทางปฏิบัติที่ดีที่สุดขั้นต่ำเราได้สร้างหลักการที่จับได้ทั้งหมดซึ่ง (ในบางส่วน) ขัดขวางการคิดนอกเหนือจากนั้น เมื่อความเสื่อมโทรมอย่างสง่างามเกิดขึ้นแล้วเราสามารถพูดได้อย่างแน่นอนว่างานของเราเสร็จสิ้นและทำได้ดี บ่อยครั้งมากขึ้นที่เราไม่ต้องนึกถึงมันเนื่องจากกรอบและไลบรารีต่างๆที่ใช้งานอยู่ครอบคลุมอยู่แล้ว และในที่สุด polyfills และ shims ก็ขจัดความจำเป็นในการลดทอนฟังก์ชันการทำงานในบางกรณี
เนื่องจากฟังก์ชันนี้พร้อมใช้งานมากขึ้นเรื่อย ๆ ความจำเป็นในการคิดเกี่ยวกับมัน (นับประสาอะไรกับมัน) ก็ยิ่งห่างไกลมากขึ้นเรื่อย ๆ
จากมุมมองของบทความนี้อาจแบ่งออกได้ดังนี้:
การย่อยสลายที่ไม่เป็นสาระ: หากคุณลักษณะไม่พร้อมใช้งานการติดตั้งจะล้มเหลวในลักษณะที่ไม่สามารถใช้งานได้หรือใช้งานไม่ได้ในลักษณะที่ไม่สามารถใช้งานได้จริง
การย่อยสลายที่สง่างาม: หากคุณลักษณะไม่พร้อมใช้งานคุณลักษณะนี้จะล้มเหลวในลักษณะที่ยังคงสามารถใช้งานได้
การปรับปรุงที่ไม่ดี: หากคุณสมบัติไม่พร้อมใช้งานคุณลักษณะนี้จะถูกจำลองโดย polyfill หรือ shim
มีการแก้ไขปัญหา
เว้นแต่คุณจะพิจารณาประสิทธิภาพของอุปกรณ์ระดับล่างเดียวกันเหล่านั้น
ขาดพลังในการประมวลผลและความสามารถด้านข้อมูลของน้องพวกเขาจึงถูกขอให้รับภาระมากขึ้น การใช้ polyfills เป็นโซลูชันสร้างภาพลวงตาว่าขณะนี้ฟังก์ชันที่ทันสมัยทั้งหมดมีอยู่ในทุกอุปกรณ์และสามารถใช้งานได้โดยไม่ต้องกังวล
ดังนั้นคุณจึงนำไปใช้ ทันสมัย และ polyfill ทุกอย่างในกรณี อุปกรณ์ที่มีความสามารถน้อยที่สุดจะโหลดข้อมูลได้มากที่สุดและประมวลผลได้มากที่สุด ดังนั้นจึงมั่นใจได้ถึงประสบการณ์ของผู้ใช้ปลายทางที่ 'ดีที่สุด'
เหตุใดฉันจึงควรใช้ node.jsชีฟชิมและโพลีฟิลล์? ขอบคุณสมาร์ทโฟนส่วนใหญ่ไม่รองรับ Flash! ทวีต
แนวคิดในการปรับปรุงอย่างสง่างามจะย้อนแนวคิดโดยเริ่มจากข้อกำหนดคุณสมบัติขั้นต่ำและการอัปเกรดการโหลดจนกว่าความสมดุลของประสิทธิภาพการใช้งานจะเหมาะสมที่สุดตามความสามารถของอุปกรณ์ ดังนั้นข้อกำหนดการรับส่งข้อมูลและการประมวลผลจะถูกย้ายไปยังอุปกรณ์ที่เหมาะสมที่สุดในการจัดการ
แน่นอนว่าในขณะนี้แนวคิดมีความซับซ้อนอย่างห้ามไม่ได้: มันไม่ได้รับการสนับสนุนโดยเฟรมเวิร์กและไลบรารีส่วนใหญ่โดยส่วนใหญ่ไม่ได้รับการอภิปรายและการอ้างอิงถึงแนวทางปฏิบัติดังกล่าวมีน้อยห่างไกลกันและมีการแปลเป็นไมโครฟังก์ชัน แต่เมื่อถึงจุดหนึ่งมันก็เป็นเช่นนั้นกับแนวคิดและฟังก์ชันการทำงานทั้งหมด
ทำได้ แต่ต้องทำอย่างไร?
แนวทางปฏิบัติที่ดีที่สุดอีกประการหนึ่งในการพัฒนาเว็บคือการตรวจสอบว่ามีคุณลักษณะอยู่ในอุปกรณ์หรือไม่ก่อนเปิดใช้งาน
อย่างไรก็ตามโปรดพิจารณาว่าคุณสามารถติดตั้ง Google Chrome เวอร์ชันล่าสุดบนโทรศัพท์ Android ที่มีอายุหลายปีได้และจะอ้างว่าสามารถทำงานได้ ภาพเคลื่อนไหว CSS , WebGL เอฟเฟกต์พารัลแลกซ์พื้นหลังและฟังก์ชันอื่น ๆ อีกมากมาย แต่จริงๆแล้ว จริงๆ ไม่สามารถ มากจนเบราว์เซอร์จะพังและอุปกรณ์ทั้งหมดจะไม่ตอบสนองจนถึงจุดที่จะต้องรีบูตเพื่อให้สามารถควบคุมได้อีกครั้ง
ปัญหานี้เริ่มส่งผลกระทบเมื่อไม่นานมานี้ แอปพลิเคชัน Android ในทางที่ดี (จากมุมมองของผู้ใช้) หนึ่งในการลดระดับที่เห็นได้ชัดเจนที่สุดในแง่นี้ส่งผลต่อการอัปเกรดแอป Google Talk / แฮงเอาท์ที่ทำให้บริการของพวกเขาเปลี่ยนจากแอปพลิเคชันแชทที่มีน้ำหนักเบาที่สุดไปจนถึงแอปพลิเคชันที่แทบจะใช้งานไม่ได้เนื่องจากปัญหาด้านประสิทธิภาพในอุปกรณ์รุ่นเก่า (เพียงแค่เน้นย้ำประเด็นนี้อีกครั้ง:“ เก่ากว่า” ในที่นี้หมายความว่าคุณยังสามารถซื้อของใหม่เอี่ยมได้ในร้านค้าเกือบทุกแห่ง) ประเด็นเดียวกัน ส่งผลกระทบต่อแอป YouTube และแอป Twitter (จากประสบการณ์ของฉัน) และอื่น ๆ อีกมากมาย
ดังนั้นใช้เวลาสักครู่ในระหว่างขั้นตอนการวางแผนของคุณเพื่อประเมินคุณค่าของคุณสมบัติหลักที่มีประสิทธิภาพสูงเหนือการแต่งหน้าที่ล้ำสมัย หรืออย่างน้อยก็ปล่อยให้แอป / บริการ / เนื้อหารุ่นสุดท้ายของคุณพร้อมใช้งานในบางรูปแบบสำหรับผู้ใช้เดิม พูดถึงที่ ...
ให้ผู้ใช้เลือกไม่ใช้ Bleeding Edge
คุณเคยพบว่าตัวเองพยายามใช้ Gmail จากอุปกรณ์เครื่องเก่าหรือผ่านการเชื่อมต่อที่ไม่ดีหรือไม่? ที่ ลิงก์ 'โหลด HTML พื้นฐาน' มีประโยชน์อย่างแน่นอน
เหตุใดหน้าร้านออนไลน์ที่ทันสมัยตอบสนองเคลื่อนไหวและสัมผัสได้ถึงไม่มีฟังก์ชันดังกล่าว
ลองคิดดู: คุณขอให้ตอบสนองเพื่อให้คุณสามารถเข้าถึงผู้มีโอกาสเป็นลูกค้าได้มากขึ้น คุณทำให้มันล้ำยุคเพื่อทิ้งความประทับใจแรกที่ดีที่สุดไว้ และด้วยเหตุนี้ผู้มีโอกาสเป็นลูกค้าจะเข้าถึงข้อมูลพื้นฐานเกี่ยวกับคุณและบริการของคุณได้น้อยลง หากการปรับปรุงที่ดีงามเป็นแนวคิดที่มีค่าใช้จ่ายสูงเกินไปสำหรับคุณทำไมอย่างน้อยคุณจึงไม่เสนอตัวเลือกให้ผู้เข้าชมเข้าถึงเนื้อหาในเวอร์ชันข้อความเท่านั้นหาก เวอร์ชัน“ WOW” มากเกินไปสำหรับอุปกรณ์ของพวกเขา
คุณต้องการห้องสมุดทั้งหมดจริงหรือ?
สุดท้ายแนวทางปฏิบัติที่ดีที่สุดสุดท้ายที่ฉันอยากเห็นว่ามีการผลักดันเกินมาตรฐานไปเล็กน้อยคือ“ ใช้หรือทำหาย” การติดตามว่าไลบรารีและโมดูลใดที่มีการใช้งานจริงและการรวมเฉพาะไลบรารีนั้นบางครั้งก็น่าเบื่อ แต่การทำให้ชุดเครื่องมือทั้งหมดของคุณในทุกหน้าเป็นเพียงแค่ความชุ่ย
เมื่อเร็ว ๆ นี้ฉันได้ติดตามฟังก์ชั่นที่ใช้งานจริงเมื่อรวมไลบรารี และเครื่องมือที่ฉันใช้บ่อยที่สุดคือ jQuery . บ่อยครั้งที่ฉันพบว่าฉันใช้ฟังก์ชันเพียงหนึ่งหรือสองฟังก์ชัน (เช่น $ .extend หรือ $ .ready) หรือที่แย่กว่านั้นคือฉันได้ใช้มันเพื่อรับองค์ประกอบตามคลาสหรือ ID บางครั้งฉันก็ปล่อยไว้แบบนั้นบางครั้งฉันก็ย้อนกลับไปใช้รหัสเพื่อลบหรือแยกการอ้างอิง
จะไม่เป็นการดีหากคุณสามารถวิเคราะห์ได้โดยอัตโนมัติว่ามีการใช้ไลบรารีและลดน้ำหนักไปเท่าใดตามผลลัพธ์
ไลบรารีและแอปพลิเคชันจำนวนมากเสนอตัวเลือกในการปรับแต่งการโหลดก่อนที่คุณจะเริ่มใช้งาน แต่ฉันมีความรู้สึกนี้อยู่เสมอว่าไม่ควรไกลเกินเอื้อมในการสร้างมาตรฐานสถาปัตยกรรมการสร้าง 'ใช้หรือสูญเสีย' แบบอัตโนมัติในห้องสมุดของเรา
ฉันมีอาการแพ้สำหรับวิธี“ รวมทุกอย่าง” แต่การใช้ร่วมกับฟังก์ชันดังกล่าวอาจเปลี่ยนแนวทางไปสู่สิ่งที่คล้ายกับบอร์ดการสร้างต้นแบบซึ่งเป็นเครื่องมือการพัฒนาที่ยืดหยุ่นมากเกินไปซึ่งได้รับการย่อขนาดไม่เพียง แต่ในรูปแบบไวยากรณ์เท่านั้น แต่ยังรวมถึงฟังก์ชันการทำงานจริงด้วย
สิ่งที่ต้องการคือไลบรารีเวอร์ชันพัฒนาเท่านั้นที่จะเปิดใช้งานการติดตามคุณลักษณะที่ใช้โดยผ่านการทดสอบหน่วยของฟังก์ชันที่ใช้และการส่งออกการอ้างอิงน้อยที่สุดหรืออย่างน้อยขนาดของการใช้ประโยชน์ (เช่นขอให้ฉันรวม jQuery ไว้ 8% ฟังก์ชันการทำงานหรือ 80%) จากนั้นสามารถใช้เอาท์พุตการพึ่งพาเพื่อเลือกเชอร์รี่รวมและลดผลผลิตสำหรับการผลิต
แต่ฉันจะทำอย่างไรกับมัน?
ก่อนอื่น มีส่วนร่วมกับปัญหา . คิดเกี่ยวกับเรื่องนี้พูดคุยกับเพื่อนของคุณและพยายามระบุปัญหาในสถานการณ์จริง
ลองใช้งาน ขุดโทรศัพท์รุ่นล่าสุดที่คุณเก็บไว้ในลิ้นชักที่ไหนสักแห่ง ลองใช้บนเว็บไซต์ของคุณเองและตรวจสอบว่าเนื้อหานั้นสามารถใช้งานได้จากระยะไกลหรือไม่ ไปเยี่ยมญาติที่อยู่เบื้องหลังในประเทศและลองเป็นผู้เผยแพร่ศาสนาให้กับพวกเขา ดูว่าความล่าช้าในการนำเทคโนโลยีมาใช้นั้นช่วยอำนวยความสะดวกได้จริงหรือไม่จากปัญหาด้านความสามารถในการเข้าถึง
หากคุณเป็นผู้ซื้อ การว่าจ้างเว็บไซต์อย่าลืมขอ (อย่างน้อย) การสนับสนุนระดับต่ำสำหรับปัญหานี้ ข้อควรจำ: เป้าหมายไม่ใช่การสร้างพอร์ตคุณสมบัติทั้งหมดของคุณไปยังอุปกรณ์ระดับต่ำ สิ่งที่ถูกถามก็คือผู้ใช้เหล่านั้นจะได้รับข้อมูลติดต่อของคุณแทนที่จะเกิดปัญหาอุปกรณ์ขัดข้อง
จัดเตรียมแหล่งข้อมูลที่แท้จริงไว้สำหรับสิ่งนี้: วิธีแก้ปัญหาที่ง่ายที่สุดไม่ควรใช้เวลาเกินหนึ่งหรือสองวันและคิดไปข้างหน้า อย่าลืมเหตุผลพื้นฐานที่สุดในการสร้างเว็บไซต์ตั้งแต่แรก (นับประสาอะไรกับการสร้างเว็บไซต์ที่ตอบสนองได้)
คุณสนใจที่จะระบุแหล่งที่มาของการโจมตีที่อาจเกิดขึ้นเมื่อเร็ว ๆ นี้
หากคุณเป็นนักพัฒนาแพ็กเกจ ทำงานกับไลบรารีเฟรมเวิร์กบันเดิลหรือซอฟต์แวร์ที่ฝังได้อื่น ๆ คุณคือคนที่สร้างความแตกต่างได้มากที่สุดที่นี่ หากคุณสามารถอำนวยความสะดวกหรือรวมแนวคิดเหล่านี้ลงในแพลตฟอร์มของคุณได้คุณจะส่งผลต่อภาพรวมของการพัฒนาเว็บทั้งหมด หากคุณรวมไว้ในการออกแบบบรรจุภัณฑ์ของคุณโปรดแจ้งให้เราทราบแล้วฉันจะประกาศให้คุณทราบ
และสุดท้าย ** ถ้าคุณเป็น ผู้พัฒนา หรือก นักออกแบบ ** อย่าหยุดอยู่แค่แนวทางปฏิบัติที่ดีที่สุด พยายามมองข้ามขอบฟ้านั้นเพียงเล็กน้อย ความพยายามอย่างหนักอยู่ที่คุณในการผลักดันแนวคิดเหล่านี้ที่ยังไม่มีใครขอซึ่งไม่ได้รับการสนับสนุนและไม่มีเอกสารประกอบเพื่อประโยชน์ของลูกค้าและผู้ใช้ของคุณ
ท้ายที่สุดถ้าคุณอยากได้ยินใครพูดถึงเรื่องนี้เป็นเวลาหลายชั่วโมงและพบว่าตัวเองอยู่ใกล้ ๆ ซาเกร็บ แจ้งให้เราทราบ เราสามารถไปคว้ากาแฟสักแก้ว
