Smashing Podcast ตอนที่ 34 กับ Harry Roberts: ประสิทธิภาพของเว็บเป็นอย่างไร?

ในตอนนี้ เรากำลังพูดถึงประสิทธิภาพของเว็บ ภาพรวมประสิทธิภาพในปี 2564 เป็นอย่างไร? ฉันได้พูดคุยกับผู้เชี่ยวชาญ Harry Roberts เพื่อหาคำตอบ

แสดงหมายเหตุ

Harry กำลังจัดเวิร์กช็อป Web Performance Masterclass กับ Smashing ในเดือนพฤษภาคม 2021 ในขณะที่เผยแพร่ ส่วนลด Earlybird จำนวนมากยังคงมีอยู่

• แฮรี่ในทวิตเตอร์
• เว็บไซต์ที่ปรึกษาของแฮร์รี่ CSS Wizardry
• หลักสูตรวิดีโอ ทุกสิ่งที่ฉันทำเพื่อทำให้ CSS Wizardry รวดเร็ว พร้อม ส่วนลด 15%
• คำถามสำหรับที่ปรึกษา eBook พร้อม ส่วนลด 15%
• คู่มือ Web.dev สำหรับ Web Vitals
• เครื่องตีไข่ OXO GoodGrips สุดโปรดของดรูว์

อัพเดทประจำสัปดาห์

• แนวโน้มการออกแบบเว็บปี 2021: รายงานที่เขียนโดย Suzanne Scacca
• การใช้ Grommet ในแอปพลิเคชัน React เขียนโดย Fortune Ikechi
• วิธีสร้าง Node.js API สำหรับ Ethereum Blockchain เขียนโดย John Agbanusi
• เราปรับปรุงประสิทธิภาพ SmashingMag อย่างไรที่เขียนโดย Vitaly Friedman
• เมื่อจะปฏิเสธโปรเจ็กต์อิสระ เขียนโดย Becca Kennedy

การถอดเสียง

Drew McLellan: เขาเป็นที่ปรึกษาอิสระด้าน Web Performance Engineer จากลีดส์ในสหราชอาณาจักร ในบทบาทของเขา เขาช่วยองค์กรที่ใหญ่ที่สุดและเป็นที่ยอมรับมากที่สุดในโลกบางแห่งมอบประสบการณ์ที่รวดเร็วและเชื่อถือได้ให้กับลูกค้าของพวกเขา เขาเป็นผู้เชี่ยวชาญด้านนักพัฒนาซอฟต์แวร์ของ Google ที่ได้รับเชิญ ผู้เชี่ยวชาญด้านนักพัฒนาสื่อ Cloudinary นักพัฒนาที่ได้รับรางวัล และวิทยากรระดับนานาชาติ เรารู้ว่าเขารู้เรื่องของเขาเมื่อพูดถึงการแสดงบนเว็บ แต่คุณรู้หรือไม่ว่าเขามี 14 แขนและเจ็ดขา? เพื่อนยอดเยี่ยมของฉัน ยินดีต้อนรับแฮร์รี่ โรเบิร์ตส์ สวัสดีแฮร์รี่ สบายดีไหม

Harry Roberts: เฮ้ ฉันยอดเยี่ยมมาก ขอบคุณมาก เห็นได้ชัดว่าแขน 14 เจ็ดขา… ยังคงมีปัญหาตามปกติ เป็นไปไม่ได้ที่จะซื้อกางเกง

Drew: และจักรยาน

แฮร์รี่: ครับ ฉันมีสามและครึ่งจักรยาน

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

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

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

Drew: คุณบอกว่าพื้นฐานไม่เปลี่ยนแปลง และสิ่งต่าง ๆ เช่น TCP/IP จะไม่เปลี่ยนแปลง สิ่งหนึ่งที่เปลี่ยนแปลงไปใน... ฉันพูดว่า "ปีที่ผ่านมา" ที่จริงแล้วอาจจะย้อนกลับไปเล็กน้อยในตอนนี้ แต่คือ HTTP ที่เรามีโปรโตคอล HTTP ที่สร้างขึ้นสำหรับการสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ และนั่นก็เปลี่ยนไปแล้ว เราได้ H2 ซึ่งเป็นเลขฐานสองและต่างกันทั้งหมด และนั่นก็เปลี่ยนหลายอย่าง… ด้วยเหตุผลด้านประสิทธิภาพ มันคือการนำข้อจำกัดที่มีอยู่ออกไปบางส่วน แต่นั่นเป็นการเปลี่ยนแปลงและวิธีที่เราต้องปรับให้เหมาะสมสำหรับโปรโตคอลนั้นก็เปลี่ยนไป ตอนนี้มีเสถียรภาพหรือไม่? หรือมันกำลังจะเปลี่ยนไปอีกครั้ง หรือ...

แฮร์รี่: สิ่งหนึ่งที่ฉันอยากเรียนรู้เพิ่มเติมคือคำถามครึ่งหลัง การเปลี่ยนแปลงอีกครั้ง ฉันต้องค้นหา QUIC และ H3 ให้มากขึ้น แต่ก็ไกลเกินกว่าที่จะเป็นประโยชน์กับลูกค้าของฉัน เมื่อพูดถึง H2 สิ่งต่างๆ ได้เปลี่ยนไปค่อนข้างมาก แต่ฉันคิดว่า H2 เป็นคำสัญญาที่ผิดๆ มากมาย และฉันเชื่อว่ามันถูกมองข้ามไป ซึ่งน่าทึ่งมากเมื่อพิจารณาว่า H1 ถูกเปิดตัว… และฉันหมายถึง 1.1 คือปี 1997 ดังนั้นเราจึงมีเวลามากในการทำงาน H2

แฮร์รี่: ฉันเดาว่าประโยชน์หลักคือนักพัฒนาเว็บที่เข้าใจหรือรับรู้ว่ามันไม่จำกัดในคำขอเที่ยวบินในขณะนี้ ดังนั้น แทนที่จะส่งคำขอหกครั้งและ/หรือคำขอบนเครื่องบินหกคำขอในแต่ละครั้ง ซึ่งอาจไม่จำกัดและไม่มีที่สิ้นสุด ทำให้เกิดปัญหาที่น่าสนใจจริงๆ เพราะ... มันค่อนข้างยากที่จะอธิบายโดยไม่มีสื่อช่วย แต่คุณยังมีแบนด์วิดท์จำนวนเท่าเดิม ไม่ว่าคุณจะใช้งาน H1 หรือ H2 โปรโตคอลไม่ได้ทำให้การเชื่อมต่อของคุณเร็วขึ้น ดังนั้นจึงค่อนข้างเป็นไปได้ที่คุณจะท่วมเครือข่ายโดยขอ 24 ไฟล์ในครั้งเดียว แต่คุณไม่มีแบนด์วิดท์เพียงพอสำหรับสิ่งนั้น ดังนั้นคุณจึงไม่ได้เร็วขึ้นเพราะคุณสามารถจัดการได้เพียงเศษเสี้ยวของเวลาเท่านั้น

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

แฮร์รี่: อีกอย่างก็คือ ถ้าคุณต้องตอบสนองทุกข้อพร้อมกัน คุณก็จะเป็นคำตอบที่สลับซับซ้อน คืนนั้นคุณจะได้รับ 10% แรกของแต่ละไฟล์และอีก 20% ถัดไป… 20% ของไฟล์ JavaScript นั้นไร้ประโยชน์ JavaScript ไม่สามารถใช้งานได้จนกว่าจะถึง 100% สิ่งที่คุณจะเห็นคือ ที่จริงแล้ว วิธีที่น้ำตก H2 ปรากฏขึ้นเมื่อคุณดูการตอบสนอง... ยังไงก็ตาม มันดูคล้าย H1 มากกว่า มันเซมากกว่ามาก ดังนั้น H2 ฉันคิดว่ามันถูกขายมากเกินไป หรือบางทีวิศวกรก็ไม่ได้ถูกชักจูงให้เชื่อว่ามีข้อ จำกัด ว่ามันจะมีประสิทธิภาพเพียงใด เนื่องจากคุณจะเห็นผู้คนแบ่งส่วนข้อมูลเนื้อหาของตนมากเกินไป และพวกเขาอาจมียี่สิบ… ให้รักษาจำนวน 24 ไว้ แทนที่จะมีไฟล์ JS ขนาดใหญ่สองไฟล์ คุณอาจมีชุดรวมเล็กๆ 24 ชุด พวกเขายังคงกลับมาค่อนข้างตามลำดับ สิ่งเหล่านี้จะไม่มาถึงในเวลาเดียวกันเพราะคุณไม่ได้เพิ่มแบนด์วิดท์ให้ตัวเองมากขึ้น

แฮร์รี่: และอีกปัญหาหนึ่งคือคำขอแต่ละรายการมีเวลาแฝงคงที่ สมมติว่าคุณกำลังขอไฟล์ขนาดใหญ่สองไฟล์ และเป็นการไปกลับหนึ่งร้อยมิลลิวินาที และดาวน์โหลด 250 มิลลิวินาที นั่นคือสองครั้งที่ 250 มิลลิวินาที หากคุณคูณด้วย 24 คำขอ คุณยังมีเวลาแฝงคงที่ ซึ่งเราได้กำหนดไว้ที่ 100 มิลลิวินาที ดังนั้นตอนนี้คุณมีเวลาแฝง 2400 มิลลิวินาทีและ 24 ครั้ง… แทนที่จะดาวน์โหลด 250 มิลลิวินาที สมมติว่ามีการดาวน์โหลด 25 มิลลิวินาที มันใช้เวลานานกว่าจริง ๆ เพราะเวลาแฝงคงที่และคุณเพียงแค่คูณเวลาแฝงนั้นกับคำขอที่มากขึ้น ดังนั้นฉันจะเห็นลูกค้าที่จะได้อ่านว่า H2 เป็นกระสุนวิเศษนี้ พวกมันจะแตก… โอ้! พวกเขาไม่สามารถทำให้ขั้นตอนการพัฒนาง่ายขึ้นได้ เราไม่ต้องทำการรวมกลุ่มหรือการต่อกัน และอื่นๆ และท้ายที่สุด มันจะจบลงช้าลงเพราะคุณสามารถกระจายคำขอของคุณออกไปได้ ซึ่งเป็นคำสัญญา แต่เวลาแฝงของคุณคงที่ ดังนั้นคุณจึงมีเวลาแฝงเพิ่มขึ้น n เท่าในเบราว์เซอร์ อย่างที่ฉันพูด ยากจริง ๆ อาจไม่มีประโยชน์เลยที่จะพยายามอธิบายว่าโดยไม่มีภาพจริง แต่มันน่าทึ่งที่ H2 แสดงออกอย่างไรเมื่อเปรียบเทียบกับสิ่งที่ผู้คนหวังว่าจะทำได้

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

แฮร์รี่: โอ้ มนุษย์ อีกคำถามที่ดี ดังนั้น แน่นอน หากสิ่งต่าง ๆ ดำเนินไปอย่างถูกต้อง และมันก็แสดงให้เห็นในการตอบสนองแบบ H1 มากกว่า แนวคิดจะเป็น file one return ก่อน สอง สาม สี่ จากนั้นพวกเขาสามารถดำเนินการตามลำดับที่มาถึง ดังนั้นคุณจึงสามารถย่นระยะเวลาโดยรวมได้จริงโดยรับประกันว่าสิ่งต่าง ๆ จะมาถึงในเวลาเดียวกัน หากเราดูที่หน้าเว็บแทนที่จะเป็น Waterfall และคุณสังเกตเห็นว่าคำขอถูกแทรกเข้ามา นั่นเป็นข่าวร้าย เพราะอย่างที่ฉันพูด 10% ของไฟล์ JavaScript นั้นไร้ประโยชน์

แฮร์รี่: ถ้าเซิร์ฟเวอร์ทำงานอย่างถูกต้องแล้วส่ง ส่ง ส่ง ส่ง ส่ง มันก็จะเร็วขึ้น แล้วคุณจะได้รับประโยชน์จากกลยุทธ์การแคชที่ละเอียดยิ่งขึ้น น่ารำคาญมากถ้าคุณอัปเดตขนาดตัวอักษรในวิดเจ็ตตัวเลือกวันที่ของคุณ ในโลก H1 คุณต้องแคช CSS แบบกว้างของไซต์ของคุณประมาณ 200 กิโลวัตต์ ในขณะที่ตอนนี้คุณเพียงแค่แคช datepicker.css ที่เสียหาย เราจึงได้ประโยชน์จากหน่อนั้น ซึ่งมีค่ามากอย่างแน่นอน

Drew: ฉันเดาว่าในสถานการณ์ที่คุณได้รับคำขอทั้งหมดของคุณกลับมาในคราวเดียวอย่างน่าอัศจรรย์นั่นจะทำให้ลูกค้าชะงักงันอย่างแน่นอนใช่ไหม

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

Drew: โดยพื้นฐานแล้วคุณกำลังมองหาน้ำตกตอบสนองที่ดูเหมือนว่าคุณสามารถเล่นสกีได้

แฮร์รี่ : ใช่ แน่นอน

Drew: แต่คุณไม่จำเป็นต้องมีร่มชูชีพ

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

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

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

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

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

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

แฮร์รี่: ยุบเป็นพอยน์เตอร์เดียว

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

แฮร์รี่ : ครับ ครับ

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

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

Drew: นั่นเกือบจะจ่ายค่าธรรมเนียมให้คุณ

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

แฮร์รี่: ประเด็นคือ มีค่าใช้จ่ายในการไปที่นั่น ฉันคิดว่า Scott Jehl น่าจะพูดได้มากที่สุดอย่างหนึ่ง… และตอนแรกฉันได้ยินเรื่องนี้จากเขา เลยคิดว่าเขาคิดขึ้นมาเอง แต่คำพูดที่ว่า “มันง่ายที่จะสร้างเว็บไซต์ที่รวดเร็ว แต่สร้างเว็บไซต์ยาก เร็ว". และนั่นเป็นเพียงรวบรัดดังนั้น เพราะเหตุผลที่ Web Perf อาจถูกผลักในรายการสิ่งที่ต้องทำก็เพราะคุณอาจจะสามารถพูดกับลูกค้าว่า “ถ้าฉันทำให้เว็บไซต์ของคุณเร็วขึ้นเป็นวินาที คุณจะทำเงินเพิ่มอีก 1.8 ล้านต่อปี” หรืออาจเป็นได้ “หากคุณเพิ่งเพิ่ม Apple Pay ลงในการชำระเงิน คุณจะมีรายได้เพิ่มอีกห้าล้าน” ดังนั้น มันไม่ได้เกี่ยวกับความสมบูรณ์แบบของเว็บทั้งหมด และไม่ใช่ปัจจัยในการตัดสินใจ มันเป็นส่วนหนึ่งของกลยุทธ์ที่ใหญ่กว่ามาก โดยเฉพาะอย่างยิ่งสำหรับ E-Com ออนไลน์ แต่หลักฐานคือฉันได้วัดผลกับลูกค้ารายย่อย ลูกค้า E-Com ของฉันโดยตรง กรณีสำหรับมันอยู่ที่นั่นคุณพูดถูกอย่างแน่นอน เป็นข้อได้เปรียบทางการแข่งขัน มันจะทำให้คุณมีเงินมากขึ้น

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

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

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

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

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

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

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

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

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

แฮร์รี่: ดังนั้นฉันคิดว่ามีจุดหนึ่งที่การย้ายไปยังลูกค้ามากขึ้นจะช่วยได้ และนั่นคือเมื่อคุณมีความไวต่อการเปลี่ยนแปลงน้อยลง ตัวอย่างเช่น คอมประเภทใดก็ตาม ฉันกำลังทำการตรวจสอบสักครู่สำหรับไซต์ที่... ฉันคิดว่าเป็นไซต์ E-Com แต่ไซต์นั้นเป็น 100% สำหรับลูกค้า คุณปิดการใช้งาน JavaScript และไม่เห็นอะไรเลย มีเพียง div id=“app” ที่ว่างเปล่า E-Com คือ... คุณอ่อนไหวต่อทุกประเด็นมาก ขั้นตอนการชำระเงินของคุณผิดพลาดอย่างยิ่ง ฉันไปอยู่ที่อื่น มันช้าเกินไป ฉันไปอยู่ที่อื่น คุณไม่มีบริบทที่ใครจะเข้านอนในแอปนั้นชั่วขณะหนึ่ง

แฮร์รี่: โฟโต้ชอป. ฉันเปิด Photoshop ขึ้นมาและรู้สึกดีใจมากที่รู้ว่าจะใช้เวลา 45 วินาทีของ splash screen เพราะฉันจะอยู่ในนั้น… โดยทั่วไป 45 วินาทีนั้นมีค่าเท่ากับ 45 นาที และมันยากมากที่จะให้คำจำกัดความ ซึ่งเป็นเหตุผลว่าทำไมฉันจึงพยายามโน้มน้าวลูกค้าว่า "ได้โปรดอย่าทำเช่นนี้" เพราะฉันไม่สามารถพูดได้เพียงว่า "คุณคิดว่าผู้ใช้ของคุณจะอยู่ที่นั่นนานแค่ไหน" และคุณสามารถพร็อกซี่ได้จาก... หากอัตราตีกลับของคุณ 89% ไม่ปรับให้เหมาะสมสำหรับการดูหน้าเว็บครั้งที่สอง รับอัตราตีกลับนั้นลงก่อน ฉันคิดว่ามีการแบ่งแยกอย่างแน่นอน แต่สิ่งที่ฉันจะพูดก็คือคนส่วนใหญ่ผิดด้านของบรรทัดนั้น คนส่วนใหญ่ใส่สิ่งของในไคลเอนต์ที่ไม่ควรมี ตัวอย่างเช่น CNN คุณไม่สามารถอ่านพาดหัวเดียวบนเว็บไซต์ CNN ได้จนกว่าจะมีการบูทแอปพลิเคชัน JavaScript โดยสมบูรณ์ สิ่งเดียวที่เซิร์ฟเวอร์แสดงผลคือส่วนหัวและส่วนท้ายซึ่งเป็นสิ่งเดียวที่ผู้คนไม่สนใจ

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

แฮร์รี่: และไม่ใช่ความผิดของใคร ฉันคิดว่ามันเป็นช่วงเริ่มต้นของระบบนิเวศ JavaScript ประเภทนี้ การโฆษณารอบ ๆ ตัวมัน และสิ่งนี้จะฟังดูรุนแรงมาก แต่... มันเป็นการใช้งานที่ไร้เดียงสามาก แน่นอนว่า Facebook ได้คิดค้น React และอะไรก็ตามก็ใช้ได้กับพวกเขา เก้าในสิบครั้ง คุณไม่ได้ทำงานในระดับ Facebook 95 ครั้งจาก 100 ครั้ง คุณอาจไม่ใช่วิศวกร Facebook ที่ฉลาดที่สุด และนั่นช่างโหดร้ายจริงๆ และฟังดูน่ากลัวที่จะพูด แต่คุณทำได้แค่... ไม่มี สิ่งเหล่านี้รวดเร็วโดยค่าเริ่มต้น คุณต้องใช้สิ่งเหล่านี้อย่างหรูหราและสง่างามมากเพื่อแก้ไขให้ถูกต้อง

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

Drew: คุณคิดว่าเรามีแนวโน้มในฐานะอุตสาหกรรมที่จะมุ่งเน้นที่ประสบการณ์ของนักพัฒนาซอฟต์แวร์มากกว่าประสบการณ์ของผู้ใช้ในบางครั้งหรือไม่?

แฮร์รี่: ไม่ทั้งหมด แต่ฉันคิดว่าปัญหาเกิดขึ้นในสถานที่ที่คุณคาดหวัง ถ้าคุณดูที่ความเหลื่อมล้ำ… ฉันไม่รู้ว่าคุณเคยเห็นสิ่งนี้หรือเปล่า แต่ฉันคิดว่าคุณมี ดูเหมือนว่าคุณจะจับชีพจรได้มาก ความแตกต่างระหว่างข้อมูลของไฟล์เก็บถาวร HTTP เกี่ยวกับเฟรมเวิร์กและ ไลบรารี JavaScript ถูกใช้ใน wild เทียบกับสถานะของการสำรวจ JavaScript หากคุณทำตามสถานะของแบบสำรวจ JavaScript มันจะบอกว่า "ใช่แล้ว 75% ของนักพัฒนาใช้ React" ในขณะที่ไซต์น้อยกว่า 5% กำลังใช้ React ดังนั้น ฉันรู้สึกว่าโดยรวมแล้ว ฉันไม่คิดว่ามันเป็นปัญหา แต่ฉันคิดว่าในพื้นที่ที่คุณคาดหวัง ความจงรักภักดีอย่างมากต่อเฟรมเวิร์กเดียว เช่น ประสบการณ์ของนักพัฒนา… การประกาศอาจมาก่อนผู้ใช้ ฉันไม่คิดว่าควรมองข้ามประสบการณ์ของนักพัฒนา ฉันหมายความว่าทุกอย่างมีค่าบำรุงรักษา รถของคุณ. มีการตัดสินใจเมื่อได้รับการออกแบบว่า "ถ้าเราซ่อนคีย์นี้ ฟังก์ชันนั้น จากกลไก มันจะใช้เวลานานกว่ามากในการแก้ไขกลไกนั้น ดังนั้นเราจึงไม่ทำอย่างนั้น" ดังนั้นจึงจำเป็นต้องมีความสมดุลระหว่างการยศาสตร์และการใช้งาน ฉันคิดว่านั่นเป็นสิ่งสำคัญ ฉันคิดว่าการเน้นไปที่ประสบการณ์ของนักพัฒนาเป็นหลักทำให้ฉันสับสน อย่าเพิ่มประสิทธิภาพเพื่อคุณ เพิ่มประสิทธิภาพให้กับลูกค้าของคุณ ลูกค้าของคุณจ่ายเงินให้คุณ ซึ่งไม่ใช่วิธีอื่น

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

แฮร์รี่: ถูกต้อง นั่นเป็นสิ่งที่ดี ที่ทำให้มั่นใจ ห้องสะท้อนเสียง… การมีวัฒนธรรมเชิงเดี่ยวแบบนั้นอาจไม่ดีนัก ถ้าคุณต้องการเรียกแบบนั้น แต่ฉันรู้สึกเหมือน… และฉันเห็นมันในงานของตัวเองมามาก นักพัฒนาหลายคน… ในฐานะที่ปรึกษา ฉันทำงานกับบริษัทต่างๆ มากมาย หลายคนกำลังทำงานที่ยอดเยี่ยมใน WordPress และ WordPress มีอำนาจ 24% ของเว็บ และฉันรู้สึกว่ามันค่อนข้างง่ายสำหรับนักพัฒนาเช่นที่ทำงานในบางอย่างเช่น WordPress หรือ PHP บนแบ็กเอนด์, โค้ดที่กำหนดเอง, อะไรก็ได้, ที่จะรู้สึกเหมือน "โอ้ ฉันเดาว่าทุกคนคงใช้ React แต่เราไม่ ” แต่จริงๆ แล้ว ไม่ ทุกคนพูดถึง React แต่คุณยังคงดำเนินไปตามกระแส คุณยังคงเป็นคนส่วนใหญ่ ค่อนข้างมั่นใจที่จะหาเสียงส่วนใหญ่ที่เงียบ

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

แฮร์รี่: ฉันรักสิ่งนั้นอย่างแน่นอน คุณจำเมื่อเราเคยเรียก SSG ว่า "flap file" ใช่ไหม?

ดริว : ครับ

แฮร์รี่: ดังนั้นฉันจึงสร้าง CSS Wizardry บน Jekyll เมื่อ Jekyll ถูกเรียกว่าเว็บไซต์ไฟล์พนัง But now we service our generator, huge, huge fan of that. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

ดริว : ครับ

Harry: … diminishing returns, that's exactly it. Yeah, exactly.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? นี้เป็นสิ่งที่ดีมาก Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

แฮร์รี่: เขาให้ความเคารพ แต่เขาเป็นหนึ่งในเด็กหนุ่ม เราทุกคนชอบเขามาก แต่เขามีขนาดใหญ่ในทุกมิติ สูงเกินหกฟุต แต่เด็กตัวใหญ่ ใหญ่ ใหญ่ ใหญ่ ใหญ่. และเขาบอกกับเราว่า “ถ้าคุณต้องออกแบบประตู คุณจะออกแบบให้สำหรับคนทั่วไปไหม” และสมองของเด็กอายุ 15 ปีก็พูดว่า “ใช่ ถ้าทุกคนอายุประมาณ 5'9 ก็ใช่” เขาก็แบบว่า “เดี๋ยวนะ แฮร์รี่ใช้ประตูนั้นไม่ได้” คุณไม่ได้ออกแบบเพื่อคนทั่วไป แต่คุณออกแบบเพื่อส่วนปลาย เพราะคุณต้องการให้มันมีประโยชน์กับคนส่วนใหญ่ ถ้าคุณออกแบบเก้าอี้สำหรับคนทั่วไป คุณบร็อคเคิลส์บี้คงไม่เหมาะกับเก้าอี้ตัวนี้ ดังนั้นเขาจึงสอนฉันตั้งแต่อายุมากจริงๆ ในการออกแบบจนถึงส่วนปลายของคุณ

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

แฮร์รี่: และนี่คือเหตุผลที่ฉันบอกลูกค้า พวกเขาจะพูดกับฉันประมาณว่า "โอ้ ผู้ใช้ส่วนใหญ่ของเราใช้ 4G บน iPhone" ก็ได้ โอเค และเราเริ่มทดสอบ 3G บน Android เช่น "ไม่ ไม่ ผู้ใช้ส่วนใหญ่ของเราเป็นไอโฟน” โอเค… นั่นหมายความว่าผู้ใช้ทั่วไปของคุณจะมีประสบการณ์ที่ดีขึ้น แต่ใครก็ตามที่ไม่ได้อยู่ในเปอร์เซ็นไทล์ที่ 50 จะถูกทิ้งไว้ข้างหลัง ดังนั้นตั้งมาตรฐานให้สูงสำหรับตัวคุณเองโดยตั้งความคาดหวังให้ต่ำลง

แฮร์รี่: ขอโทษนะ ฉันมีนิสัยที่แย่มากที่จะตอบคำถามสั้นๆ ยาวๆ แต่มันเป็นคำถามที่ยอดเยี่ยม และเพื่อพยายามสรุป ฉันเห็นด้วยกับคุณ 100% ว่าคุณต้องการดูหางยาวนั้น คุณต้องการดูสิ่งนั้น… เปอร์เซ็นไทล์ที่ 80 ของคุณ เพราะถ้าคุณใช้ประสบการณ์ทั้งหมด ไซต์และดูค่ามัธยฐาน และคุณปรับปรุงค่ามัธยฐาน นั่นหมายความว่าคุณได้ปรับปรุงให้ดียิ่งขึ้นสำหรับผู้ที่ค่อนข้างพอใจอยู่แล้ว 50% ของคนที่ถูกละเลยอย่างมีประสิทธิภาพไม่ใช่แนวทางที่ถูกต้อง และใช่ คุณ Brocklesby กลับมาบอกฉันเสมอว่า "อย่าออกแบบให้เหมาะกับคนทั่วไป เพราะงั้น Harry ก็ใช้ประตูไม่ได้" เผื่อใครฟังอยู่ครับ ผมสูง 193 ซม. ผมค่อนข้างผอม นั่นแหละครับ

Drew: และแขนและขาพวกนั้นด้วย

แฮร์รี่: ครับ นี่ก็อีกอันที่ดีเช่นกัน แฟนของฉันเพิ่งค้นพบการตั้งค่าการช่วยสำหรับการเข้าถึงใน iOS… ดังนั้นทุกคนจึงปิดเสียงโทรศัพท์ใช่ไหม ไม่มีใครมีโทรศัพท์ที่ส่งเสียงจริงๆ หรอก ทุกคนปิดเสียงไว้ เธอพบว่า “คุณรู้ไหม คุณสามารถตั้งค่าให้เมื่อได้รับข้อความ แฟลชจะกะพริบ และถ้าคุณแตะด้านหลังโทรศัพท์ 2 ครั้ง จะเป็นการจับภาพหน้าจอ” และนี่คือการตั้งค่าการช่วยสำหรับการเข้าถึง ซึ่งออกแบบมาสำหรับเปอร์เซ็นไทล์ที่ 95 แต่เธอก็แบบ “โอ้ นี่มันมีประโยชน์จริงๆ”

แฮร์รี่: เหมือนกับ OXO Good Grips OXO Good Grips เครื่องใช้ในครัว ฉันมีของพวกนี้อยู่ในครัว พวกเขาได้รับการออกแบบเนื่องจากภรรยาของผู้ก่อตั้งมีโรคข้ออักเสบและเขาต้องการทำเครื่องใช้ที่สะดวกสบายมากขึ้น เขาออกแบบมาสำหรับเปอร์เซ็นไทล์ที่ 99 คนส่วนใหญ่ไม่มีโรคข้ออักเสบ แต่ด้วยการออกแบบสำหรับเปอร์เซ็นไทล์ที่ 99 โดยไม่ได้ตั้งใจ ทุกคนก็แบบว่า “โอ้ พระเจ้า ทำไมเครื่องปอกมันฝรั่งทุกเครื่องจะสบายขนาดนี้ไม่ได้ล่ะ” และฉันรู้สึกเหมือนมันเป็นเรื่องจริง… ฉันชอบความรู้สึกดีๆ หรือเรื่องเล็ก ๆ น้อย ๆ ที่ฉันชอบที่จะล้อเลียนในสถานการณ์แบบนี้ แต่ใช่ ถ้าคุณปรับให้เหมาะสมสำหรับพวกเขา... กระแสน้ำที่เพิ่มขึ้นจะลอยเรือทุกลำ ดังนั้นจึงปรับส่วนท้ายของผู้คนให้เหมาะสม และคุณจะดึงดูดลูกค้าที่มีความสุขมากกว่านั้นอีกจำนวนมาก

Drew: คุณมีที่ปัดมือ OXO Good Grips หรือไม่?

แฮร์รี่: ฉันไม่ ฉันไม่ มันจะดีเหรอ?

ดริว : ดูนั่นสิ มันดีมาก.

แฮร์รี่: ฉันมีตัวแบ่งส่วนข้อมูลแมนโดลิน OXO Good Grips ซึ่งเอานิ้วออกเมื่อสัปดาห์ที่แล้ว

Drew: ใช่ ฉันจะไม่เข้าใกล้หนึ่งในนั้น

แฮร์รี่: ใช่ มันเป็นความผิดที่โง่เขลาของฉันเอง

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

แฮร์รี่: โอเค

Drew: … เพราะเป็นองค์กรที่ใหญ่ที่สุดที่มีข้อมูลมากที่สุด

แฮร์รี่: ถูกต้อง

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

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

แฮร์รี่: และเขากำลังบินชั้นหนึ่ง แน่นอนว่าเขาเป็น แต่มันหมายถึงเวลาส่วนใหญ่ของเขากับ iPhone 12 Pro Max ที่สวยงามและแวววาวของเขา ไม่ว่าจะทำอะไรก็ตาม ผ่าน WiFi บนเครื่องบิน ซึ่งแย่มาก และมันก็เป็นการวางเคียงกันที่น่าทึ่งจริงๆ ที่เขาเป็นเจ้าของไซต์และเขาใช้มันเป็นจำนวนมาก มันคือไซต์ที่เขาใช้ และเขากำลังผลักดันมัน... ฉันหมายความว่าลูกค้าที่ร่ำรวยที่สุดของพวกเขาคือ CEO ของพวกเขาได้อย่างง่ายดาย และเขาอยู่ในตำแหน่งที่มีอภิสิทธิ์แปลกประหลาดนี้ ซึ่งเขามีความสัมพันธ์ที่แย่กว่า Joe Public เพราะเขาอยู่ที่ไหนสักแห่งเหนือสิงคโปร์บนเที่ยวบินของ Quantas และได้รับแชมเปญราดคอของเขา และเขาก็กำลังดิ้นรน และนั่นเป็นข้อมูลเชิงลึกที่น่าสนใจจริงๆ ที่… ใช่แล้ว เพราะคุณมีเปอร์เซ็นไทล์ที่ 95 โดยพื้นฐานแล้วสามารถไปทั้งสองทิศทางได้

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

แฮร์รี่ : ใช่ แน่นอน

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

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

แฮร์รี่: อย่างไรก็ตาม ถ้าลูกค้ามีเวลา ก็มักจะเป็นเวลา เพราะคุณต้องการเก็บข้อมูล แต่คุณต้องใช้เวลาในการบันทึกข้อมูลจริงๆ สิ่งที่ฉันพยายามทำกับลูกค้าก็คือ ไปกันเถอะ "ดูสิ เราไม่สามารถทำงานร่วมกันได้ในอีกสามเดือนข้างหน้าเพราะฉันถูกจองเต็มแล้ว สิ่งที่เราทำได้คือตั้งค่าให้คุณทดลองใช้ Speedcurve ฟรี ตั้งค่าเมตริกที่กำหนดเองอย่างรวดเร็ว” ซึ่งหมายความว่าสำหรับลูกค้าผู้จัดพิมพ์ หนังสือพิมพ์ ฉันจะวัดว่า "พาดหัวข่าวของ บทความที่แสดง? รูปภาพนำของบทความแสดงผลได้เร็วแค่ไหน” สำหรับลูกค้า E-Commerce ฉันต้องการวัด เพราะแน่นอนว่าคุณกำลังวัดสิ่งต่างๆ เช่น เริ่มแสดงผลแบบพาสซีฟ ทันทีที่คุณเริ่มใช้ซอฟต์แวร์ตรวจสอบประสิทธิภาพ คุณกำลังบันทึกตัวชี้วัดประสิทธิภาพจริงของคุณได้ฟรี ดังนั้น First Contentful Paint ของคุณ เนื้อหาที่ใหญ่ที่สุด ฯลฯ สิ่งที่ฉันต้องการจะจับภาพคือสิ่งที่สำคัญสำหรับพวกเขาในฐานะธุรกิจ

แฮร์รี่: ดังนั้น การทำงานกับลูกค้า E-Com ในขณะที่เราสามารถเชื่อมโยง... ยิ่งการเริ่มเรนเดอร์ของคุณเร็วขึ้น ความน่าจะเป็นที่จะเพิ่มในรถเข็นคืออะไร หากคุณสามารถแสดงผลิตภัณฑ์แก่พวกเขาได้เร็วกว่านี้ พวกเขาก็มีแนวโน้มที่จะซื้อผลิตภัณฑ์นั้นมากขึ้น และนี่เป็นความพยายามอย่างมากในการตั้งค่า นี่เป็นเป้าหมายที่ยืดยาวสำหรับลูกค้าที่มีความทะเยอทะยานจริงๆ แต่สิ่งใดก็ตามที่คุณต้องการวัดจริงๆ เพราะอย่างที่ฉันพูด คุณไม่ต้องการวัดอะไรที่ใหญ่ที่สุดของคุณ Contentful Paint คือ คุณต้องการวัดรายได้และได้รับอิทธิพลจาก Large Contentful Paint หรือไม่ ดังนั้นเป้าหมายที่ยืดยาว สิ่งสุดท้าย จะเป็นอะไรก็ได้ที่คุณมองว่าเป็น KPI สำหรับธุรกิจนั้น ในหนังสือพิมพ์อาจมีคนเลื่อนบทความลงไปได้ไกลแค่ไหน? และนั่นสัมพันธ์กับความล่าช้าในการป้อนข้อมูลครั้งแรกหรือไม่? ผู้คนอ่านบทความมากขึ้นหรือไม่ถ้า CLS ต่ำกว่า? แต่ก่อนที่เราจะเริ่มสร้างตัววัดแบบกำหนดเอง ฉันคิดว่า Web Vitals เป็นจุดเริ่มต้นที่ดีจริงๆ และได้รับการทำให้เป็นมาตรฐานด้วยเช่นกัน มันกลายเป็น... ฉันไม่รู้ว่าคำนั้นคืออะไร ฉันเดาว่าตัวหารร่วมที่ต่ำที่สุดที่ทุกคนในอุตสาหกรรมสามารถพูดคุยเกี่ยวกับประสิทธิภาพในสนามแข่งขันระดับนี้ได้

แฮร์รี่: ปัญหาหนึ่งที่ฉันมี และฉันต้องจัดการประชุมกับทีม Vitals จริงๆ ก็คือฉันคิดว่า Lighthouse นั้นยอดเยี่ยมจริงๆ แต่ CLS คิดเป็น 33% ของ Vitals บนเว็บ คุณมี LCP, FID, CLS CLS คือ 33% ของพลังชีวิตของคุณ Vitals คือสิ่งที่มักจะอยู่ต่อหน้าทีมการตลาดของคุณ แผนกวิเคราะห์ของคุณ เนื่องจากมันปรากฏขึ้นในคอนโซลการค้นหา ซึ่งถูกกล่าวถึงในบริบทของหน้าผลการค้นหา ในขณะที่ Vitals นั้นกังวล คุณมีน้ำหนักมาก 33% หนึ่งในสาม ของ Vitals คือ CLS เป็นเพียง 5% ของคะแนน Lighthouse ของเรา สิ่งที่คุณจะได้รับคือนักพัฒนาที่สร้างโดยใช้ Lighthouse เพราะมันสามารถรวมเข้ากับเครื่องมือได้ มันเป็นตัวชี้วัดในห้องปฏิบัติการ ไวทัลคือข้อมูลภาคสนาม มันคือเหล้ารัม

แฮร์รี่: คุณเลยขาดการติดต่อครั้งใหญ่ โดยที่คุณมีทีมการตลาดของคุณพูดว่า "CLS แย่มาก" และนักพัฒนากำลังคิดว่า "ก็ 5% ของคะแนน Lighthouse ที่ DevTools มอบให้ เท่ากับ 5% ของคะแนน ที่ Lighthouse CLI มอบให้เราใน CircleCI” หรืออะไรก็ตามที่คุณใช้ แต่สำหรับทีมการตลาด 33% ของสิ่งที่พวกเขาสนใจ ดังนั้นปัญหาจึงมีการตัดการเชื่อมต่อเล็กน้อยเพราะฉันคิดว่า Lighthouse มีค่ามาก แต่ฉันไม่รู้ว่าพวกเขากระทบยอดความแตกต่างที่ค่อนข้างใหญ่ใน Vitas ได้อย่างไร CLS คือ 33% ของคะแนนของคุณ… ไม่ใช่คะแนนเพราะคุณ ไม่มีจริงๆ และ Lighthouse มีเพียง 5% เท่านั้น และยังคงต้องแก้ไขก่อนที่เราจะสามารถสนทนาได้อย่างราบรื่น

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

Drew: ดังนั้น สำหรับนักพัฒนาเว็บที่สนใจ… พวกเขาไม่มีงบประมาณใช้จ่ายกับเครื่องมืออย่าง Speedcurve และสิ่งต่างๆ พวกเขาสามารถเรียกใช้เครื่องมืออย่าง Lighthouse ได้ภายในเบราว์เซอร์ เพื่อให้ได้การวัดผลที่ดี… สิ่งต่างๆ เช่น Google Analytics มีประโยชน์สำหรับระดับนั้นหรือไม่

แฮรี่: พวกนี้มีประโยชน์และมีประโยชน์มากกว่า หลายปีที่ผ่านมา Analytics ได้รวบรวมข้อมูลประสิทธิภาพการทำงานเบื้องต้น และนั่นจะเป็นเวลา DNS, TCP และ TLS, เวลาเป็นไบต์แรก, เวลาในการดาวน์โหลดหน้าเว็บ, ซึ่งเป็นพร็อกซี... อะไรก็ตาม เพียงแค่เวลาในการดาวน์โหลดหน้าเว็บและเวลาในการโหลด ตัวชี้วัดที่ค่อนข้างงุ่มง่าม แต่เป็นจุดกระโดดที่ดีและโดยปกติทุกโครงการที่ฉันเริ่มต้นด้วยลูกค้า หากไม่มี New Relic หรือ Speedcurve หรืออะไรก็ตาม ฉันจะพูดว่า "ให้ฉันดูการวิเคราะห์ของคุณ" เพราะฉันสามารถ อย่างน้อยพร็อกซีสถานการณ์จากที่นั่น และจะไม่มีที่ไหนใกล้เท่า Speedcurve หรือ New Relic หรือ Dynatrace หรืออะไรก็ตาม คุณสามารถส่งเมตริกที่กำหนดเองไปยัง Analytics ได้อย่างง่ายดายจริงๆ ถ้าใครฟังอยากสามารถส่ง… ไซต์ของฉันเป็นต้น. ฉันมีตัวชี้วัดเช่น "คุณอ่านหัวเรื่องของบทความของฉันได้เร็วแค่ไหน? รูปภาพของหน้าเกี่ยวกับแสดงผล ณ จุดใด อะไรคือคำกระตุ้นการตัดสินใจที่ขอให้คุณจ้างฉัน จะแสดงผลหน้าจอได้เร็วแค่ไหน” การเก็บรวบรวมข้อมูลนี้เป็นเรื่องเล็กน้อยจริงๆ และการส่งไปยังการวิเคราะห์นั้นแทบจะไม่สำคัญเลย ดังนั้น หากใครต้องการดูแหล่งที่มาในไซต์ของฉัน ให้เลื่อนลงมาที่แท็กปิดเนื้อหาและค้นหาข้อมูลโค้ดการวิเคราะห์ คุณจะเห็นว่าการบันทึกข้อมูลที่กำหนดเองนั้นง่ายเพียงใดและส่งข้อมูลนั้นไปยัง Analytics และใน UI ของ Analytics คุณไม่จำเป็นต้องดำเนินการใดๆ โดยปกติ คุณจะต้องตั้งค่ารายงานที่กำหนดเองและขุดข้อมูลและทำให้มันเรียบร้อย เหล่านี้เป็นพลเมืองชั้นหนึ่งใน Google Analytics ดังนั้น ทันทีที่คุณเริ่มบันทึกการวิเคราะห์ที่กำหนดเอง จะมีส่วนทั้งหมดของแดชบอร์ดที่ทุ่มเทให้กับมัน ไม่มีการตั้งค่าใด ๆ ไม่มีการยกของหนักใน GA ดังนั้นจึงเป็นเรื่องเล็กน้อยจริงๆ และหากลูกค้ามีงบประมาณจำกัด หรือบางทีฉันอาจต้องการแสดงให้พวกเขาเห็นถึงพลังของการตรวจสอบแบบกำหนดเอง ฉันไม่ต้องการที่จะพูดว่า “ใช่ ฉันสัญญา มันจะดีมาก ขอแค่ 24 แกรนด์สำหรับ Speedcurve?” ฉันสามารถเริ่มต้นด้วยการพูดว่า “ดูสิ นี่เป็นพื้นฐาน มาดูความเป็นไปได้กัน ตอนนี้เราอาจโน้มน้าวให้คุณอัพเกรดเป็น Speedcurve ได้”

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

แฮร์รี่: ไม่เลย ฉันมีตัวอย่างที่เกี่ยวข้องจริงๆ ของเรื่องนี้ พรีโหลด… คำแนะนำสั้นๆ สำหรับทุกคนที่ไม่เคยได้ยินเรื่องพรีโหลดมาก่อน การโหลดเนื้อหาบางอย่างบนเว็บนั้นช้ามากโดยเนื้อแท้ และตัวเลือกหลักสองคนที่นี่คือภาพพื้นหลังใน CSS และแบบอักษรของเว็บ เพราะก่อนที่คุณจะสามารถดาวน์โหลดภาพพื้นหลัง คุณมี เพื่อดาวน์โหลด HTML ซึ่งจะดาวน์โหลด CSS จากนั้น CSS จะพูดว่า "โอ้ div นี้ในหน้าแรกต้องใช้ภาพพื้นหลังนี้" ดังนั้นมันจึงช้ามากโดยเนื้อแท้เพราะคุณมีเวลา CSS ทั้งหมดในระหว่างนั้น ด้วยการโหลดล่วงหน้า คุณสามารถใส่หนึ่งบรรทัดใน HTML ในแท็ก head ที่ระบุว่า "คุณยังไม่รู้ แต่เชื่อฉันเถอะ คุณจะต้องการภาพนี้จริงๆ เร็วๆ นี้จริงๆ" ดังนั้น คุณสามารถใส่การโหลดล่วงหน้าใน HTML ซึ่งจะทำให้การดาวน์โหลดนี้หยุดทำงานชั่วคราว เมื่อถึงเวลาที่ CSS ต้องการภาพพื้นหลัง มันก็เหมือนกับว่า “เยี่ยมมาก ได้แล้ว เร็วมาก” และสิ่งนี้ถูกขนานนามว่าเป็นเว็บที่สมบูรณ์แบบของพระเมสสิยาห์… นี่คือสิ่งที่และฉันสัญญากับคุณ ฉันทวีตเมื่อสัปดาห์ที่แล้ว และฉันก็ได้รับการพิสูจน์สองครั้งตั้งแต่นั้นเป็นต้นมา ผู้คนได้ยินเกี่ยวกับพรีโหลดและคำสัญญาที่ให้ไว้ และในทางทฤษฎีแล้ว Lighthouse ถูกผลักดันอย่างหนักเช่นกัน มันทำให้ไซต์ของคุณเร็วขึ้น ผู้คนต่างแต่งงานกันกับแนวคิดเรื่องพรีโหลด ซึ่งแม้ว่าฉันจะพิสูจน์ได้ว่ามันไม่ได้ผล พวกเขาจะไม่ลบมันออกอีก เพราะ “ไม่ แต่ไลท์เฮาส์พูด” นี่เป็นหนึ่งในสิ่งที่ทฤษฎีมีเสียง หากคุณต้องรอแบบอักษรเว็บของคุณ แทนที่จะดาวน์โหลดก่อนหน้านี้ คุณจะเห็นสิ่งต่างๆ เร็วขึ้น ปัญหาคือ เมื่อคุณคิดว่าเว็บทำงานอย่างไร หน้าเว็บใด ๆ ที่คุณเข้าชมครั้งแรก โดเมนใหม่ที่คุณเข้าชม คุณมีแบนด์วิดท์จำนวนจำกัด และเบราว์เซอร์ใช้แบนด์วิดท์ที่ถูกต้องอย่างชาญฉลาด มันจะตรวจสอบ HTML ของคุณอย่างรวดเร็วและสร้างรายการซื้อของ สิ่งที่สำคัญที่สุดคือ CSS ต่อจากนี้ก็คือ jQuery นี้ แล้วก็คือนี่... และต่อจากนี้ไปก็คือ สิ่งเหล่านี้ สิ่งเหล่านี้ และลำดับความสำคัญน้อยกว่าเหล่านี้ ทันทีที่คุณเริ่มโหลด HTML ด้วยพรีโหลด คุณกำลังบอกเบราว์เซอร์ว่า “ไม่ ไม่ ไม่ นี่ไม่ใช่รายการซื้อของอีกต่อไป บัดดี้ นี่คือของฉัน คุณต้องไปรับสิ่งเหล่านี้” จำนวนแบนด์วิดธ์ที่จำกัดนั้นยังคงมีอยู่อย่างจำกัด แต่จะไม่ถูกใช้ในสินทรัพย์อื่นๆ ดังนั้นทุกอย่างจึงช้าลงเล็กน้อย และฉันต้องโห่สิ่งนี้สองครั้งในสัปดาห์ที่ผ่านมาและผู้คนก็ยังชอบ "ใช่ แต่ไม่ใช่เพราะมันดาวน์โหลดเร็วกว่า" ไม่ มีการขอเร็วกว่านี้ แต่เป็นการขโมยแบนด์วิดท์จาก CSS ของคุณ คุณจะเห็นได้ว่าแบบอักษรเว็บของคุณกำลังขโมยแบนด์วิธจาก CSS ของคุณ ดังนั้นมันจึงเป็นหนึ่งในสิ่งที่คุณต้องทำ ต้องทำ ตามตัวเลข ฉันเคยทำมาแล้วกับลูกค้ารายใหญ่ หากคุณกำลังฟังสิ่งนี้ คุณเคยได้ยินเกี่ยวกับลูกค้ารายนี้และฉันก็ค่อนข้างยืนกรานว่า “ไม่ ไม่ ไม่ ป้ายชื่อของคุณอยู่ในลำดับที่ไม่ถูกต้อง เพราะนี่คือสิ่งที่ควรจะเป็นและคุณจำเป็นต้องมีในนี้ คำสั่งเพราะในทางทฤษฎีมันบอกใบ้ในเรื่องนั้น…” แม้ในสิ่งที่ฉันเป็นลูกค้าฉันก็รู้ว่าฉันกำลังตั้งค่าตัวเองเป็นคนโง่ เนื่องจากเบราว์เซอร์ทำงานอย่างไร จึงต้องเร็วกว่า ฉันกำลังใช้วิธีนี้ การเปลี่ยนแปลงนี้… ต่อผู้คนหลายล้านคน และมันช้าลง มันช้าลง และฉันนั่งอยู่ที่นั่น ยืนกรานอย่างขุ่นเคืองว่า "ไม่ แต่เบราว์เซอร์ทำงานแบบนี้" ก็ไม่มีประโยชน์เพราะมันไม่ทำงาน และเราเปลี่ยนกลับและฉันก็แบบ "ขออภัย! ยังคงออกใบแจ้งหนี้ให้คุณสำหรับสิ่งนั้น!” ดังนั้นมันไม่ใช่คุณเลย

Drew: ทำตามตัวเลขเหล่านี้

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

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

แฮร์รี่: หากต้องการพูดถึง "การสร้างโดย Google" ทั้งหมดอย่างรวดเร็ว… ฉันรู้ดีว่ามันอาจดูไม่ค่อยเข้าหูแต่ฉันจะเน้นเรื่องนี้ ฉันเดาว่าน่าจะเริ่มต้น เดิมพันบนเบราว์เซอร์ อย่างเช่น AMP เป็นต้น เป็นการดีที่สุดที่จะคิดหาวิธีแก้ปัญหา ไม่มีทางแทนที่การสร้างเว็บไซต์ที่รวดเร็ว และเมื่อคุณเริ่มใช้สิ่งต่างๆ เช่น AMP คุณจะต้องยึดมั่นในมาตรฐานที่ไม่ได้มาตรฐานเหล่านั้น นั่นคือความเมตตาของทีม AMP ที่เปลี่ยนใจ ฉันมีลูกค้ารายหนึ่งเสียสิทธิ์ใช้งานฟอนต์จากผู้ให้บริการฟอนต์ในรายการที่อนุญาตของ AMP จากนั้นในบางครั้ง AMP ก็ตัดสินใจว่า “ไม่นะ ฟอนต์นั้นที่เราให้มา เราจะบล็อกลิสต์พวกมันเดี๋ยวนี้” ฉันก็เลยมีลูกค้า ที่ลงทุนมหาศาลใน AMP และผู้ให้บริการฟอนต์รายนี้ และต้องเลือก “เราจะเลิกทำงาน AMP ทั้งหมดหรือว่าเราแค่เสียตัวเลขจำนวนมากต่อปีไปกับฟอนต์เว็บ” บลา บลา บลา ดังนั้นฉันจะระวังตัวให้มาก… ฉันเป็นผู้เชี่ยวชาญ Google Developer แต่ฉันไม่รู้ว่ามีคำสั่งปิดปากอะไร… ฉันวิจารณ์ได้ และฉันจะบอกว่า… หลีกเลี่ยงสิ่งที่เรียกว่าขนาดเดียว -เหมาะกับทุกโซลูชัน เช่น AMP

แฮร์รี่: และเพื่อทิ้งคนอื่นไว้สักครู่ Cloudflare มีสิ่งที่เรียกว่า Rocket Loader ซึ่งเป็น AMP-esque ในความพยายาม ได้รับการออกแบบมาเช่น "โอ้ แค่เปิดสิ่งนี้ใน CDN ของคุณ มันจะทำให้ไซต์ของคุณเร็วขึ้น" และที่จริงแล้วมันเป็นเพียงสิ่งทดแทนการสร้างไซต์ของคุณอย่างถูกต้องตั้งแต่แรก ดังนั้น… เพื่อจัดการกับประเด็นนั้น พยายามและคงความเป็นอิสระให้มากที่สุด รู้ว่าเบราว์เซอร์ทำงานอย่างไร ซึ่งหมายความว่าในทันทีว่า Chrome monoculture คุณกลับมาอยู่บนตักของ Google แล้ว แต่รู้ว่าเบราว์เซอร์ทำงานอย่างไร ยึดมั่นในอุดมการณ์พื้นฐานบางอย่าง เมื่อคุณสร้างไซต์ ให้ดูที่หน้า ไม่ว่าจะอยู่ใน Figma หรือ Sketch หรือที่ไหนก็ตาม ดูที่การออกแบบแล้วพูดว่า “นั่นคือสิ่งที่ผู้ใช้ต้องการเห็นเป็นอันดับแรก ดังนั้นฉันจะไม่ใส่อะไรมาขวางเลย ฉันจะไม่ขี้เกียจโหลดภาพหลักนี้เพราะมันงี่เง่า ทำไมฉันถึงทำอย่างนั้น” ลองคิดดูว่า “คุณต้องการให้ผู้ใช้เป็นอะไรเป็นอันดับแรก” ในไซต์ E-Com จะเป็นรูปภาพผลิตภัณฑ์นั้น อาจเป็นการนำทางพร้อมกัน แต่การรีวิวผลิตภัณฑ์ ถามและตอบของผลิตภัณฑ์ โหลดแบบเกียจคร้าน เหน็บที่อยู่เบื้องหลัง JavaScript

แฮร์รี่: วิธีการทำงานพื้นฐานบางอย่างที่จะให้บริการคุณอย่างถูกต้อง ไม่ว่าคุณจะกำลังอ่านเทคโนโลยีอะไรอยู่ก็ตาม นั่นคือ "จัดลำดับความสำคัญว่าลูกค้าของคุณให้ความสำคัญกับอะไร" การทำงานมากกว่านี้จะเร็วขึ้น ดังนั้นอย่าใส่สิ่งต่าง ๆ ให้กีดขวาง แต่จากนั้นก็ให้เพิ่มยุทธวิธีให้ผู้คนทราบ ให้ทัน... และอีกครั้ง ตรงกลับมาที่ Google แต่ web.dev กำลังพิสูจน์ให้เห็นว่าเป็นทรัพยากรที่มหัศจรรย์สำหรับ framework ที่ไม่เชื่อเรื่องพระเจ้า, สแต็คข้อมูลเชิงลึกที่ไม่เชื่อเรื่องพระเจ้า... ดังนั้น หากคุณต้องการเรียนรู้เกี่ยวกับ Vitals คุณต้องการเรียนรู้เกี่ยวกับ PWA ดังนั้น web.dev นั้นยอดเยี่ยมมาก

Harry: จริงๆ แล้วมีสิ่งพิมพ์ที่เน้นประสิทธิภาพน้อยมาก อีเมลของ Calibre ฉันคิดว่าอีเมลรายสัปดาห์ของ Calibre นั้นยอดเยี่ยมมาก เป็นข้อมูลสรุปที่ดีจริงๆ จับตาดูแพลตฟอร์มเว็บโดยทั่วไป ดังนั้นจึงมีคณะทำงานด้านประสิทธิภาพ พวกเขามีข้อมูลมากมายเกี่ยวกับข้อเสนอ GitHub กลับมาที่ Google อีกครั้ง แต่ไม่มีใครรู้เกี่ยวกับเว็บไซต์นี้และความมหัศจรรย์ของมัน: chromestatus.com โดยจะบอกคุณอย่างแน่ชัดว่า Chrome ทำงานอะไรอยู่ สัญญาณอะไรจากเบราว์เซอร์อื่น ดังนั้นหากคุณต้องการดูว่างานนี้เป็นอย่างไรตามคำแนะนำลำดับความสำคัญ คุณสามารถไปและรับลิงก์ไปยังตัวติดตามจุดบกพร่องที่เกี่ยวข้องทั้งหมดได้ สถานะ Chrome จะแสดงให้คุณเห็นถึงเหตุการณ์สำคัญสำหรับแต่ละรายการ… “สิ่งนี้จะออกมาใน MAT8 ซึ่งเปิดตัวในปี '67” หรืออะไรก็ตาม นั่นเป็นสิ่งที่ดีจริงๆ สำหรับข้อมูลเชิงลึกด้านเทคนิคที่ค่อนข้างมาก

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

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

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

Drew: คุณได้รวบรวมหลักสูตรวิดีโอที่เรียกว่า “ทุกสิ่งที่ฉันทำเพื่อทำให้ CSS Wizardry Fast”

แฮร์รี่: ใช่!

Drew: มันแตกต่างจากหลักสูตรวิดีโอออนไลน์ทั่วไปเล็กน้อยใช่ไหม

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

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

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

แฮร์รี่: ฉันคิดว่าฉันพยายามจะเก็บไว้มากกว่านี้… ข้อดีของการไม่ทำหลักสูตรที่เข้มงวดคือคุณไม่จำเป็นต้องดูวิดีโอก่อน ไม่มีอินโทร แค่ “ไปดูรอบๆ แล้วดูสิ่งที่คุณสนใจ” ซึ่งหมายความว่าคนที่ประสบปัญหา LTP พวกเขาชอบ "โอ้ ฉันต้องดำน้ำในโฟลเดอร์นี้ที่นี่" หรือถ้าพวกเขากำลังประสบปัญหาเกี่ยวกับ CSS พวกเขาสามารถดำดิ่งลงในโฟลเดอร์นั้นได้ เห็นได้ชัดว่าฉันไม่มีสถิติ แต่ฉันคิดว่ามีอัตราการละทิ้งหลักสูตรสูง เพียงเพราะคุณต้องเดินผ่านช่วงแนะนำสามชั่วโมงในกรณีที่คุณพลาดบางสิ่งบางอย่างและมันเหมือนกับ "โอ้คุณรู้อะไรฉันทำไม่ได้ ทำอย่างนี้ทุกวัน” และผู้คนอาจละทิ้งหลักสูตรจำนวนมาก ดังนั้น ความคิดของฉันจึงเป็นเพียงการดำดิ่งลงไป คุณไม่จำเป็นต้องดูสามชั่วโมงก่อนหน้านี้ คุณสามารถไปและค้นหาสิ่งที่คุณต้องการได้ และผลตอบรับก็ออกมาจริง ๆ ... อันที่จริงสิ่งที่ฉันจะทำคือมันยังไม่มี แต่ฉันจะทำมันหลังจากการโทรใครก็ตามที่ใช้รหัสส่วนลด SMASHING15 จะได้รับส่วนลด 15% ของมัน

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

แฮร์รี่: ใช่ ไม่ได้ตั้งใจ แต่ฉันจะให้เครดิตกับมัน

Drew: ดังนั้น ฉันได้เรียนรู้เกี่ยวกับประสิทธิภาพของเว็บมาหมดแล้ว แฮรี่ได้เรียนรู้อะไรไปบ้างเมื่อเร็วๆ นี้

แฮร์รี่: เรื่องทางเทคนิค…ไม่เลย ฉันมีรายการ "ต้องเรียนรู้" มากมาย ดังนั้น QUIC, H3 ฉันจึงอยากเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องนั้นอีกเล็กน้อย แต่ฉันเขียน E-Book ระหว่างการปิดเมืองครั้งแรกในสหราชอาณาจักร ดังนั้นฉันจึงได้เรียนรู้ วิธีทำ E-Books ที่สนุกมากเพราะเป็น HTML และ CSS และฉันรู้วิธีแก้ไขของฉัน มันจึงสนุกมาก ฉันได้เรียนรู้การตัดต่อวิดีโอเบื้องต้นสำหรับหลักสูตรนี้ และสิ่งที่ฉันชอบเกี่ยวกับสิ่งเหล่านั้นไม่ใช่งานแนวความคิด แน่นอน การเรียนรู้ภาษาโปรแกรม คุณต้องต่อสู้กับแนวคิด ในขณะที่การเรียนรู้ E-Book เป็นเพียงขั้นตอนการทำงาน และ... สิ่งที่ฉันไม่เคยคิดมาก่อน จึงเป็นที่น่าสนใจที่จะเรียนรู้ แต่ก็ไม่ต้องเปลี่ยนอาชีพ ดังนั้นจึงค่อนข้างดี

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

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

แฮร์รี่ : ใช่ แน่นอน และจำนวนกราฟที่ฉันได้ดูบนจักรยานยนต์… ฉันได้ข้อมูลกำลังจากจักรยานยนต์ ฉันจะออกไปขี่แล้วกลับมาเหมือน “โอ้ ถ้าฉันยังมีวัตต์เพิ่มอีกห้าวัตต์ที่นี่ แต่ประหยัดไปแล้ว 10 วัตต์ที่นั่น ฉันทำได้ นี่ นี่ และนี่เร็วที่สุดเท่าที่เคยมีมา” และ… รู้สึกไม่สบายใจอย่างมากเกี่ยวกับเรื่องนี้ แต่ใช่ คุณพูดถูก คุณรู้อะไรไหม ฉันคิดว่าคุณพบบางสิ่งที่น่าสนใจจริงๆ ฉันคิดว่าสิ่งนั้นเป็นกีฬา/งานอดิเรกที่ดีสำหรับคนที่หมกมุ่นอยู่กับการไล่ตามตัวเลข มีบางอย่างเกิดขึ้น ฉันหมายความว่าคุณจะรู้เรื่องนี้ แต่ Strava คุณมี KOM ของคุณ ปีที่แล้วฉันรวบรวม 19 ตัวซึ่งเป็นจำนวนที่มหัศจรรย์สำหรับฉัน และเกือบทั้งหมดมาจากการหมกมุ่นอยู่กับข้อมูลที่มีอยู่และการดู "ผู้ชายคนนี้ที่ฉันพยายามจะเอาชนะ เขาทำกำลังไฟ 700 วัตต์ ณ จุดนี้ ถ้าฉันทำได้ถึง 1,000 แล้วค่อยปิด" และ บลา บลา บลา … เป็นการหมกมุ่น เนิร์ด แต่คุณพูดถูก ฉันคิดว่ามันคล้ายคลึงกันใช่ไหม If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

แฮร์รี่: ครับ I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.