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

ใน SPA การรีเฟรชหน้าเว็บจะไม่เกิดขึ้น แต่ โค้ด HTML , JavaScriptและCSS ที่จำเป็นทั้งหมด จะถูกดึงมาจากเบราว์เซอร์ในการโหลดหน้าเว็บเพียงครั้งเดียว^{[ 1 ]}หรือทรัพยากรที่เหมาะสมจะถูกโหลดและเพิ่มลงในหน้าเว็บแบบไดนามิกตามความจำเป็น ซึ่งโดยปกติจะเป็นการตอบสนองต่อการกระทำของผู้ใช้

ที่มาของคำว่าแอปพลิเคชันหน้าเดียวไม่ชัดเจน แม้ว่าแนวคิดนี้จะถูกกล่าวถึงอย่างน้อยที่สุดในปี 2003 โดยนักเผยแพร่เทคโนโลยีจาก Netscape ^{[ 2 ]} Stuart Morris นักศึกษาด้านการเขียนโปรแกรมที่มหาวิทยาลัยคาร์ดิฟฟ์ ประเทศเวลส์ ได้เขียน เว็บไซต์ แบบครบวงในตัวเองที่ slashdotslash.com โดยมีเป้าหมายและฟังก์ชันเดียวกันในเดือนเมษายน 2002 ^{[ 3 ]}และต่อมาในปีเดียวกัน Lucas Birdeau, Kevin Hakman, Michael Peachey และ Clifford Yeh ได้อธิบายการใช้งานแอปพลิเคชันหน้าเดียวในสิทธิบัตรของสหรัฐอเมริกาหมายเลข 8,136,109 ^{[ 4 ]}รูปแบบก่อนหน้านี้เรียกว่าแอ ปพลิเคชันเว็บแบบสมบูรณ์

JavaScript สามารถใช้ในเว็บเบราว์เซอร์เพื่อแสดงส่วนติดต่อผู้ใช้ (UI) รันตรรกะของแอปพลิเคชัน และสื่อสารกับเว็บเซิร์ฟเวอร์ มีไลบรารี ฟรี ที่พัฒนาแล้วมากมาย ที่สนับสนุนการสร้าง SPA (Single Page Application) ซึ่งช่วยลดปริมาณโค้ด JavaScript ที่นักพัฒนาต้องเขียน

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

ผู้เขียน HTML สามารถใช้ ID ขององค์ประกอบเพื่อแสดงหรือซ่อนส่วนต่างๆ ของเอกสาร HTML จากนั้นใช้ CSS โดยใช้:targetตัวเลือกคลาสเสมือนเพื่อแสดงเฉพาะส่วนของหน้าเว็บที่เบราว์เซอร์นำทางไปเท่านั้น

เฟรมเวิร์กและไลบรารี JavaScript สำหรับเว็บเบราว์เซอร์ เช่นAngular , Ember.js , ExtJS , Knockout.js , Meteor.js , React , Vue.jsและSvelteได้นำหลักการ SPA (Single Page Application) มาใช้ ยกเว้น ExtJS แล้ว เฟรมเวิร์กเหล่านี้ทั้งหมดใช้งานได้ฟรี

• AngularJSเป็นเฟรมเวิร์กฝั่งไคลเอ็นต์ที่เลิกใช้งานแล้ว การสร้างเทมเพลตของ AngularJS นั้นใช้การผูกข้อมูล UI แบบสองทิศทาง การผูกข้อมูลเป็นวิธีการอัปเดตมุมมองโดยอัตโนมัติเมื่อใดก็ตามที่โมเดลเปลี่ยนแปลง รวมถึงการอัปเดตโมเดลเมื่อใดก็ตามที่มุมมองเปลี่ยนแปลง เทมเพลต HTML จะถูกคอมไพล์ในเบราว์เซอร์ ขั้นตอนการคอมไพล์จะสร้าง HTML บริสุทธิ์ ซึ่งเบราว์เซอร์จะแสดงผลใหม่ในมุมมองจริง ขั้นตอนนี้จะทำซ้ำสำหรับมุมมองหน้าเว็บถัดไป ในการเขียนโปรแกรม HTML ฝั่งเซิร์ฟเวอร์แบบดั้งเดิม แนวคิดต่างๆ เช่น คอนโทรลเลอร์และโมเดลจะโต้ตอบกันภายในกระบวนการของเซิร์ฟเวอร์เพื่อสร้างมุมมอง HTML ใหม่ ในเฟรมเวิร์ก AngularJS สถานะของคอนโทรลเลอร์และโมเดลจะถูกเก็บรักษาไว้ภายในเบราว์เซอร์ไคลเอ็นต์ ดังนั้นจึงสามารถสร้างหน้าเว็บใหม่ได้โดยไม่ต้องมีการโต้ตอบกับเซิร์ฟเวอร์
• Angular 2+เป็นเฟรมเวิร์ก SPA ที่พัฒนาโดย Google ต่อจาก AngularJS เฟรมเวิร์กนี้มีชุมชนนักพัฒนาที่แข็งแกร่ง และมีการอัปเดตปีละสองครั้ง โดยมีการเพิ่มฟีเจอร์ใหม่และแก้ไขข้อบกพร่องอยู่บ่อยครั้ง
• Ember.jsเป็นเฟรมเวิร์กสำหรับการพัฒนาเว็บแอปพลิเคชันฝั่งไคลเอ็นต์ด้วย JavaScript โดยอิงตาม รูปแบบสถาปัตยกรรมซอฟต์แวร์ Model-View-Controller (MVC) ช่วยให้นักพัฒนาสามารถสร้างแอปพลิเคชันแบบหน้าเดียวที่ปรับขนาดได้ โดยการนำเอาสำนวนและแนวปฏิบัติที่ดีที่สุดมาใช้ในเฟรมเวิร์กที่มีโมเดลอ็อบเจ็กต์ที่ครบครัน การผูกข้อมูลแบบสองทางเชิงประกาศ คุณสมบัติที่คำนวณได้ เทมเพลตที่อัปเดตอัตโนมัติโดยใช้ Handlebars.js และเราเตอร์สำหรับการจัดการสถานะของแอปพลิเคชัน
• ExtJSเป็นเฟรมเวิร์กฝั่งไคลเอ็นต์ที่ช่วยให้สร้างแอปพลิเคชัน MVC ได้ มีระบบเหตุการณ์ การจัดการหน้าต่างและเลย์เอาต์ การจัดการสถานะ (store) และส่วนประกอบ UI ต่างๆ (ตาราง, หน้าต่างโต้ตอบ, ฟอร์ม ฯลฯ) มีระบบคลาสของตัวเองพร้อมตัวโหลดแบบไดนามิกหรือแบบคงที่ แอปพลิเคชันที่สร้างด้วย ExtJS สามารถทำงานได้ด้วยตัวเอง (โดยมีสถานะอยู่ในเบราว์เซอร์) หรือทำงานร่วมกับเซิร์ฟเวอร์ (เช่น ผ่านREST API ที่ใช้ในการเติมข้อมูลลงใน store ภายใน) ExtJS มีความสามารถในการใช้งาน localStorage เพียงอย่างเดียว ดังนั้นแอปพลิเคชันขนาดใหญ่จึงจำเป็นต้องมีเซิร์ฟเวอร์เพื่อจัดเก็บสถานะ
• Knockout.jsเป็นเฟรมเวิร์กฝั่งไคลเอ็นต์ที่ใช้เทมเพลตตาม รูปแบบ Model-View-ViewModel (MVVM)
• Meteor.jsเป็นเฟรมเวิร์ก JavaScript แบบฟูลสแต็ก (ไคลเอ็นต์-เซิร์ฟเวอร์) ที่ออกแบบมาสำหรับ SPA โดยเฉพาะ มีคุณสมบัติการผูกข้อมูลที่ง่ายกว่า Angular, Ember หรือ ReactJS ^{[ 5 ]}และใช้โปรโตคอลข้อมูลแบบกระจาย^{[ 6 ]}และรูปแบบการเผยแพร่-สมัครรับข้อมูลเพื่อเผยแพร่การเปลี่ยนแปลงข้อมูลไปยังไคลเอ็นต์แบบเรียลไทม์โดยอัตโนมัติโดยไม่ต้องให้ผู้พัฒนาเขียนโค้ดการซิงโครไนซ์ใดๆ การตอบสนองแบบฟูลสแต็กทำให้มั่นใจได้ว่าทุกเลเยอร์ ตั้งแต่ฐานข้อมูลไปจนถึงเทมเพลต จะอัปเดตตัวเองโดยอัตโนมัติเมื่อจำเป็น แพ็กเกจระบบนิเวศ เช่นการเรนเดอร์ฝั่งเซิร์ฟเวอร์^{[ 7 ] [ 8 ]}ช่วยแก้ปัญหาการเพิ่มประสิทธิภาพเครื่องมือค้นหา
• Reactเป็นไลบรารี JavaScriptสำหรับสร้างอินเทอร์เฟซผู้ใช้ ได้รับการดูแลโดยFacebook , Instagramและชุมชนของนักพัฒนารายบุคคลและบริษัทต่างๆ React ใช้ส่วนขยายไวยากรณ์สำหรับ JavaScript ที่ชื่อว่าJSXซึ่งเป็นการผสมผสานระหว่าง JS และ HTML (ส่วนย่อยของ HTML) หลายบริษัทใช้ React ร่วมกับRedux (ไลบรารี JavaScript)ซึ่งเพิ่มความสามารถในการจัดการสถานะ ซึ่ง (ร่วมกับไลบรารีอื่นๆ อีกหลายตัว) ช่วยให้นักพัฒนาสามารถสร้างแอปพลิเคชันที่ซับซ้อนได้^{[ 9 ]}
• Vue.jsเป็นเฟรมเวิร์ก JavaScript สำหรับสร้างส่วนติดต่อผู้ใช้ นักพัฒนา Vue ยังได้จัดเตรียม Pinia สำหรับการจัดการสถานะอีกด้วย
• Svelteเป็นเฟรมเวิร์กสำหรับการสร้างส่วนติดต่อผู้ใช้ที่คอมไพล์โค้ด Svelte ไปเป็นการจัดการ DOM (Document Object Model) ด้วย JavaScript ซึ่งช่วยหลีกเลี่ยงการรวมเฟรมเวิร์กเข้ากับฝั่งไคลเอนต์ และช่วยให้ไวยากรณ์ในการพัฒนาแอปพลิเคชันง่ายขึ้น

เฟรมเวิร์กแอปพลิเคชันเว็บที่ใช้ JavaScript เช่น React และ Vue มีความสามารถมากมาย แต่ก็มีข้อจำกัดอยู่บ้าง เฟรมเวิร์กเหล่านี้มักจะขยายหรือปรับปรุงคุณสมบัติที่มีอยู่ในเทคโนโลยีเว็บดั้งเดิม เช่น การกำหนดเส้นทาง การพัฒนาตามส่วนประกอบ และการจัดการสถานะ แม้ว่ามาตรฐานเว็บดั้งเดิม รวมถึง Web Components, API JavaScript สมัยใหม่ เช่น Fetch และ ES Modules และความสามารถของเบราว์เซอร์ เช่น Shadow DOM จะพัฒนาไปมากแล้ว แต่เฟรมเวิร์กก็ยังคงถูกใช้อย่างแพร่หลายเนื่องจากความสามารถในการเพิ่มประสิทธิภาพการทำงานของนักพัฒนา นำเสนอรูปแบบโครงสร้างสำหรับแอปพลิเคชันขนาดใหญ่ ลดความซับซ้อนในการจัดการกรณีพิเศษ และจัดหาเครื่องมือสำหรับการเพิ่มประสิทธิภาพการทำงาน^{[ 10 ] [ 11 ] [ 12 ]}

เฟรมเวิร์กอาจนำเสนอเลเยอร์นามธรรมที่อาจส่งผลให้เกิดภาระด้านประสิทธิภาพ ขนาดบันเดิลที่ใหญ่ขึ้น และความซับซ้อนที่เพิ่มขึ้น เฟรมเวิร์กสมัยใหม่ เช่น React 18 และ Vue 3 แก้ไขปัญหาเหล่านี้ด้วยคุณสมบัติต่างๆ เช่น การเรนเดอร์พร้อมกัน การตัดต้นไม้ และการไฮเดรชั่นแบบเลือก แม้ว่าความก้าวหน้าเหล่านี้จะช่วยปรับปรุงประสิทธิภาพการเรนเดอร์และการจัดการทรัพยากร แต่ประโยชน์ของมันขึ้นอยู่กับแอปพลิเคชันและบริบทการใช้งานเฉพาะ เฟรมเวิร์กที่มีน้ำหนักเบา เช่น Svelte และ Preact ใช้แนวทางสถาปัตยกรรมที่แตกต่างกัน โดย Svelte กำจัด DOM เสมือนออกไปโดยสิ้นเชิงเพื่อสนับสนุนการคอมไพล์คอมโพเนนต์เป็นโค้ด JavaScript ที่มีประสิทธิภาพ และ Preact นำเสนอทางเลือกที่เรียบง่ายและเข้ากันได้กับ React การเลือกเฟรมเวิร์กขึ้นอยู่กับข้อกำหนดของแอปพลิเคชัน รวมถึงความเชี่ยวชาญของทีม เป้าหมายด้านประสิทธิภาพ และลำดับความสำคัญในการพัฒนา^{[ 10 ] [ 11 ] [ 12 ]}

เฟรมเวิร์กเว็บประเภทใหม่กว่า ได้แก่ enhance.dev, Astro และ Fresh ใช้ประโยชน์จากมาตรฐานเว็บดั้งเดิมในขณะที่ลดนามธรรมและเครื่องมือพัฒนาให้น้อยที่สุด^{[ 13 ] [ 14 ] [ 15 ]}โซลูชันเหล่านี้เน้นการปรับปรุงแบบก้าวหน้าการเรนเดอร์ฝั่งเซิร์ฟเวอร์และการเพิ่มประสิทธิภาพ Astro เรนเดอร์ HTML แบบคงที่โดยค่าเริ่มต้น ในขณะที่ไฮเดรตเฉพาะส่วนที่โต้ตอบได้ Fresh เน้นการเรนเดอร์ฝั่งเซิร์ฟเวอร์โดยไม่มีค่าใช้จ่ายรันไทม์ Enhance.dev ให้ความสำคัญกับรูปแบบการปรับปรุงแบบก้าวหน้าโดยใช้ Web Components แม้ว่าเครื่องมือเหล่านี้จะลดการพึ่งพา JavaScript ฝั่งไคลเอ็นต์โดยการเปลี่ยนตรรกะไปที่เวลาสร้างหรือการดำเนินการฝั่งเซิร์ฟเวอร์ แต่ก็ยังคงใช้ JavaScript เมื่อจำเป็นสำหรับการโต้ตอบ แนวทางนี้ทำให้เหมาะอย่างยิ่งสำหรับแอปพลิเคชันที่สำคัญต่อประสิทธิภาพและเน้นเนื้อหา^{[ 10 ] [ 11 ] [ 12 ]}

เฟรมเวิร์กต่อไปนี้ใช้WebAssemblyหรือสามารถสร้างแอปพลิเคชันหน้าเดียว (SPA) โดยใช้ WebAssembly เป็นเทคโนโลยีหลักหรือกลไกสนับสนุน เฟรมเวิร์กเหล่านี้ช่วยให้การพัฒนาฝั่งไคลเอ็นต์มีประสิทธิภาพสูงและมีการโต้ตอบที่ดี ขยายแนวคิด SPA ไปสู่ภาษาและระบบนิเวศต่างๆ

• Avalonia เป็นเฟรมเวิร์ก UIสำหรับเดสก์ท็อปแบบข้ามแพลตฟอร์มเป็นหลักแต่การรองรับWebAssembly แบบทดลอง ทำให้สามารถนำไปใช้ในการพัฒนา SPA ได้ มีการออกแบบ UI ที่ใช้ XAML และคุณสมบัติของแอปพลิเคชันสไตล์เนทีฟ
• Blazor WebAssemblyเป็นเฟรมเวิร์กที่ใช้ .NET ซึ่งช่วยให้นักพัฒนาสามารถสร้าง SPA (Single Page Application) โดยใช้ไวยากรณ์C#และRazor ได้ มันรันโค้ด . NETในเบราว์เซอร์ผ่าน WebAssembly ทำให้สามารถพัฒนาแอปพลิเคชัน .NET แบบครบวงจรได้โดยไม่ต้องพึ่งพา JavaScript
• Flutter บนเว็บขยายขีดความสามารถในการพัฒนาแอปพลิเคชันข้ามแพลตฟอร์มของ Flutter ไปสู่แอปพลิเคชัน Single Page Application (SPA) บนเว็บ โดยใช้ภาษา Dart และเอนจินกราฟิก Skia ทำให้ Flutter ช่วยให้นักพัฒนาสามารถสร้าง SPA ที่มีภาพสวยงามและทำงานในเบราว์เซอร์ได้
• OpenSilverเป็นการนำ Silverlight มาพัฒนาใหม่ในรูปแบบโอเพนซอร์สอีกตัวหนึ่ง โดยมุ่งเน้นไปที่แอปพลิเคชัน Single Page Application (SPA) ที่พัฒนาด้วย C# และXAMLมันใช้ WebAssembly ในการรันโค้ด .NET ในเบราว์เซอร์ ดังนั้นจึงเหมาะสำหรับแอปพลิเคชันฝั่งไคลเอ็นต์ที่มีการโต้ตอบสูง
• Uno Platformเป็นเฟรมเวิร์กข้ามแพลตฟอร์มที่รองรับการพัฒนา SPA (Single Page Application) ผ่าน WebAssembly ช่วยให้นักพัฒนาสามารถใช้ XAML และ C# ในการสร้างแอปพลิเคชันที่ทำงานบนเว็บ มือถือ และเดสก์ท็อป โดยส่วนประกอบ UI จะแสดงผลโดยตรงในเบราว์เซอร์

ในปี 2549 เทคนิคที่โดดเด่นที่สุดคือAjax [ ^{1 ] Ajax}เกี่ยวข้องกับการใช้คำขอแบบอะซิงโครนัสไปยังเซิร์ฟเวอร์สำหรับ ข้อมูล XMLหรือJSONเช่นXMLHttpRequest ของ JavaScript หรือที่ทันสมัยกว่าfetch()(ตั้งแต่ปี 2560) หรือActiveX Object ที่เลิกใช้แล้ว ในทางตรงกันข้ามกับ วิธี การประกาศของเฟรมเวิร์ก SPA ส่วนใหญ่ ด้วย Ajax เว็บไซต์จะใช้ JavaScript หรือไลบรารี JavaScript เช่นjQuery โดยตรง เพื่อจัดการDOMและแก้ไของค์ประกอบ HTML Ajax ได้รับความนิยมมากขึ้นจากไลบรารีเช่นjQueryซึ่งมีไวยากรณ์ที่ง่ายกว่าและทำให้พฤติกรรมของ Ajax เป็นมาตรฐานในเบราว์เซอร์ต่างๆ ซึ่งในอดีตมีพฤติกรรมที่แตกต่างกัน

WebSocketsเป็นเทคโนโลยีการสื่อสารแบบสองทิศทางแบบเรียลไทม์ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ซึ่งเป็นส่วนหนึ่งของข้อกำหนด HTML สำหรับการสื่อสารแบบเรียลไทม์ การใช้งาน WebSockets มีประสิทธิภาพเหนือกว่า Ajax ในแง่ของประสิทธิภาพ^{[ 16 ]}และความเรียบง่าย

เหตุการณ์ที่ส่งจากเซิร์ฟเวอร์ (SSEs) เป็นเทคนิคที่เซิร์ฟเวอร์สามารถเริ่มต้นการส่งข้อมูลไปยังไคลเอนต์เบราว์เซอร์ได้ เมื่อมีการสร้างการเชื่อมต่อเริ่มต้นแล้ว สตรีมเหตุการณ์จะยังคงเปิดอยู่จนกว่าไคลเอนต์จะปิด SSEs จะถูกส่งผ่าน HTTP แบบดั้งเดิมและมีคุณสมบัติหลากหลายที่ WebSockets ขาดไปโดยธรรมชาติ เช่น การเชื่อมต่อใหม่โดยอัตโนมัติ รหัสเหตุการณ์ และความสามารถในการส่งเหตุการณ์ตามอำเภอใจ^{[ 17 ]}

แม้ว่าวิธีการนี้จะล้าสมัยแล้ว แต่การเรียกใช้เซิร์ฟเวอร์แบบอะซิงโครนัสก็สามารถทำได้โดยใช้เทคโนโลยีปลั๊กอินของเบราว์เซอร์ เช่นSilverlight , FlashหรือJava applets

โดยทั่วไปแล้ว การส่งคำขอไปยังเซิร์ฟเวอร์จะส่งผลให้ได้รับข้อมูลดิบ (เช่นXMLหรือJSON ) หรือHTML ใหม่ กลับมา ในกรณีที่เซิร์ฟเวอร์ส่ง HTML กลับมา JavaScript บนฝั่งไคลเอนต์จะอัปเดตส่วนหนึ่งของ DOM ( Document Object Model ) เมื่อส่งข้อมูลดิบกลับมา JavaScript บนฝั่งไคลเอนต์จะแปลงข้อมูลดิบนั้นเป็น HTML โดยใช้XSLหรือเทมเพลต JSON ก่อนที่จะอัปเดต DOM

SPA (Single Page Application) ย้ายตรรกะจากเซิร์ฟเวอร์ไปยังไคลเอนต์ โดยบทบาทของเว็บเซิร์ฟเวอร์เปลี่ยนไปเป็น API ข้อมูลหรือเว็บเซอร์วิสโดยสมบูรณ์ การเปลี่ยนแปลงทางสถาปัตยกรรมนี้ ในบางแวดวงเรียกว่า "สถาปัตยกรรมเซิร์ฟเวอร์แบบบาง" (Thin Server Architecture) เพื่อเน้นว่าความซับซ้อนได้ถูกย้ายจากเซิร์ฟเวอร์ไปยังไคลเอนต์ โดยมีเหตุผลว่าในที่สุดแล้วจะช่วยลดความซับซ้อนโดยรวมของระบบลง

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

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

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

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

SPA บางตัวอาจถูกเรียกใช้จากไฟล์ในเครื่องโดยใช้รูปแบบ URI ของไฟล์ซึ่งช่วยให้ผู้ใช้สามารถดาวน์โหลด SPA จากเซิร์ฟเวอร์และเรียกใช้ไฟล์จากอุปกรณ์จัดเก็บข้อมูลในเครื่องได้โดยไม่ต้องพึ่งพาการเชื่อมต่อกับเซิร์ฟเวอร์ หาก SPA ดังกล่าวต้องการจัดเก็บและอัปเดตข้อมูล จะต้องใช้Web Storage บนเบราว์เซอร์ แอปพลิเคชันเหล่านี้ ^ได้รับประโยชน์จากความก้าวหน้าที่มีอยู่ในHTML [ ^{18 ]}

เนื่องจาก SPA เป็นวิวัฒนาการที่แตกต่างจากโมเดลการวาดหน้าเว็บใหม่แบบไร้สถานะที่เบราว์เซอร์ได้รับการออกแบบมาแต่เดิม จึงทำให้เกิดความท้าทายใหม่ๆ ขึ้น วิธีแก้ปัญหาที่เป็นไปได้ (ซึ่งมีความซับซ้อน ครอบคลุม และควบคุมโดยผู้เขียนได้แตกต่างกัน) ได้แก่: ^{[ 19 ]}

• ไลบรารี JavaScript ฝั่งไคลเอ็นต์
• เฟรมเวิร์กเว็บฝั่งเซิร์ฟเวอร์ที่เชี่ยวชาญในโมเดล SPA ^{[ 20 ] [ 21 ] [ 22 ]}
• วิวัฒนาการของเบราว์เซอร์และข้อกำหนด HTML ^{[ 23 ]}ออกแบบมาสำหรับโมเดล SPA

เนื่องจากการขาดการทำงานของ JavaScript บนโปรแกรมรวบรวมข้อมูลของเครื่องมือค้นหาเว็บ ยอดนิยมบาง โปรแกรม^{[ 24 ]} SEO ( การเพิ่มประสิทธิภาพเครื่องมือค้นหา ) จึงเป็นปัญหาสำหรับเว็บไซต์สาธารณะที่ต้องการใช้โมเดล SPA มาโดยตลอด^{[ 25 ]}

ระหว่างปี 2009 ถึง 2015 Google Webmaster Centralได้เสนอและแนะนำ "รูปแบบการรวบรวมข้อมูล AJAX" ^{[ 26 ] [ 27 ]}โดยใช้เครื่องหมายอัศเจรีย์เริ่มต้นในตัวระบุส่วนย่อยสำหรับ หน้า AJAX ที่มีสถานะ ( #!) ต้องมีการใช้งานพฤติกรรมพิเศษโดยไซต์ SPA เพื่ออนุญาตให้โปรแกรมรวบรวมข้อมูลของเครื่องมือค้นหาดึงข้อมูลเมตาที่เกี่ยวข้อง สำหรับเครื่องมือค้นหาที่ไม่รองรับ รูปแบบ แฮช URL นี้ URL ที่แฮชของ SPA จะยังคงมองไม่เห็น URI แบบ "hash-bang" เหล่านี้ถูกพิจารณาว่ามีปัญหาโดยนักเขียนหลายคน รวมถึง Jeni Tennison ที่ W3C เนื่องจากทำให้ไม่สามารถเข้าถึงหน้าเว็บได้สำหรับผู้ที่ไม่ได้ เปิดใช้งาน JavaScriptในเบราว์เซอร์ นอกจากนี้ยังทำให้ ส่วนหัว Referer ของ HTTP เสียหาย เนื่องจากเบราว์เซอร์ไม่ได้รับอนุญาตให้ส่งตัวระบุส่วนย่อยในส่วนหัว Referer ^{[ 28 ]}ในปี 2015 Google ได้ยกเลิกข้อเสนอการรวบรวมข้อมูล AJAX แบบ hash-bang ^{[ 29 ]}

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

ในปี 2018 Google ได้แนะนำการเรนเดอร์แบบไดนามิกเป็นอีกทางเลือกหนึ่งสำหรับเว็บไซต์ที่ต้องการนำเสนอเวอร์ชันของหน้าเว็บที่ไม่ต้องใช้ JavaScript มากนักให้กับโปรแกรมรวบรวมข้อมูลเพื่อวัตถุประสงค์ในการจัดทำดัชนี^{[ 30 ]}การเรนเดอร์แบบไดนามิกจะสลับระหว่างเวอร์ชันของหน้าเว็บที่เรนเดอร์ฝั่งไคลเอ็นต์และเวอร์ชันที่เรนเดอร์ไว้ล่วงหน้าสำหรับเอเจนต์ผู้ใช้เฉพาะ วิธีการนี้เกี่ยวข้องกับเว็บเซิร์ฟเวอร์ของคุณที่ตรวจจับโปรแกรมรวบรวมข้อมูล (ผ่านเอเจนต์ผู้ใช้) และกำหนดเส้นทางไปยังตัวเรนเดอร์ จากนั้นจึงให้บริการเนื้อหา HTML เวอร์ชันที่ง่ายกว่าแก่โปรแกรมรวบรวมข้อมูลนั้น ตั้งแต่ปี 2024 Google ไม่แนะนำการเรนเดอร์แบบไดนามิกอีกต่อไป^{[ 31 ]}โดยแนะนำ " การเร น เด อร์ฝั่งเซิร์ฟเวอร์ การเรนเดอร์แบบคงที่หรือไฮเดรชั่น " แทน

เนื่องจากความเข้ากันได้กับ SEO ไม่ใช่เรื่องง่ายใน SPA (Single Page Application) SPA จึงมักไม่ถูกนำไปใช้ในบริบทที่การจัดทำดัชนีของเครื่องมือค้นหาเป็นข้อกำหนดหรือสิ่งที่พึงประสงค์ กรณีการใช้งาน ได้แก่ แอปพลิเคชันที่แสดงข้อมูลส่วนตัวที่ซ่อนอยู่หลัง ระบบ การตรวจสอบสิทธิ์ในกรณีที่แอปพลิเคชันเหล่านี้เป็นผลิตภัณฑ์สำหรับผู้บริโภค มักจะใช้โมเดล "การวาดหน้าเว็บใหม่" แบบคลาสสิกสำหรับหน้า Landing Page และเว็บไซต์การตลาดของแอปพลิเคชัน ซึ่งให้ข้อมูลเมตาเพียงพอสำหรับแอปพลิเคชันที่จะปรากฏเป็นผลลัพธ์ในการค้นหาของเครื่องมือค้นหา บล็อก ฟอรัมสนับสนุน และส่วนประกอบการวาดหน้าเว็บใหม่แบบดั้งเดิมอื่นๆ มักจะอยู่รอบๆ SPA ซึ่งสามารถป้อนคำที่เกี่ยวข้องให้กับเครื่องมือค้นหาได้

ณ ปี 2021 และโดยเฉพาะ Google ความเข้ากันได้ของ SEO สำหรับ SPA ธรรมดานั้นตรงไปตรงมาและต้องการเพียงเงื่อนไขง่ายๆ ไม่กี่ข้อเท่านั้น^{[ 32 ]}

วิธีหนึ่งในการเพิ่มปริมาณโค้ดที่สามารถแชร์ระหว่างเซิร์ฟเวอร์และไคลเอ็นต์ได้คือการใช้ภาษาเทมเพลตที่ไม่มีตรรกะ เช่นMustacheหรือHandlebarsเทมเพลตดังกล่าวสามารถแสดงผลได้จากภาษาโฮสต์ที่แตกต่างกัน เช่นRubyบนเซิร์ฟเวอร์และJavaScriptในไคลเอ็นต์ อย่างไรก็ตาม การแชร์เทมเพลตโดยทั่วไปต้องมีการทำซ้ำตรรกะทางธุรกิจที่ใช้ในการเลือกเทมเพลตที่ถูกต้องและเติมข้อมูลลงในเทมเพลตเหล่านั้น การแสดงผลจากเทมเพลตอาจส่งผลเสียต่อประสิทธิภาพเมื่ออัปเดตเพียงส่วนเล็ก ๆ ของหน้า เช่น ค่าของช่องป้อนข้อความภายในเทมเพลตขนาดใหญ่ การแทนที่เทมเพลตทั้งหมดอาจรบกวนการเลือกหรือตำแหน่งเคอร์เซอร์ของผู้ใช้ ในขณะที่การอัปเดตเฉพาะค่าที่เปลี่ยนแปลงอาจไม่รบกวน เพื่อหลีกเลี่ยงปัญหาเหล่านี้ แอปพลิเคชันสามารถใช้การผูกข้อมูล UIหรือ การจัดการ DOM แบบละเอียด เพื่ออัปเดตเฉพาะส่วนที่เหมาะสมของหน้าแทนที่จะแสดงผลเทมเพลตทั้งหมดใหม่^{[ 33 ]}

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

วิธีแก้ปัญหาแบบดั้งเดิมสำหรับ SPA (Single Page Application) คือการเปลี่ยนตัวระบุส่วน แฮชของ URL ในเบราว์เซอร์ ให้สอดคล้องกับสถานะหน้าจอปัจจุบัน ซึ่งสามารถทำได้ด้วย JavaScript และทำให้เกิดการสร้างเหตุการณ์ประวัติ URL ภายในเบราว์เซอร์ ตราบใดที่ SPA สามารถเรียกคืนสถานะหน้าจอเดิมจากข้อมูลที่มีอยู่ในแฮชของ URL ได้ พฤติกรรมการกดปุ่มย้อนกลับก็จะยังคงอยู่

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

เครื่องมือวิเคราะห์ข้อมูล เช่นGoogle Analyticsอาศัยการโหลดหน้าเว็บใหม่ทั้งหมดในเบราว์เซอร์ ซึ่งเริ่มต้นโดยการโหลดหน้าเว็บใหม่ทุกครั้ง แต่ SPA (Single Page Application) ไม่ทำงานในลักษณะนี้

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

เช่นเดียวกับปัญหาที่พบในโปรแกรมรวบรวมข้อมูลของเครื่องมือค้นหาเครื่องมือ DASTอาจประสบปัญหาในการจัดการกับแอปพลิเคชันที่มี JavaScript จำนวนมาก ปัญหาอาจรวมถึงการขาดลิงก์ไฮเปอร์เท็กซ์ ความกังวลเกี่ยวกับการใช้หน่วยความจำ และทรัพยากรที่โหลดโดย SPA ซึ่งโดยทั่วไปจะพร้อมใช้งานผ่านApplication Programming Interfaceหรือ API แอปพลิเคชันหน้าเดียวยังคงมีความเสี่ยงด้านความปลอดภัยเช่นเดียวกับเว็บเพจแบบดั้งเดิม เช่นCross-Site Scripting (XSS)แต่ยังมีช่องโหว่เฉพาะอื่นๆ อีกมากมาย เช่น การเปิดเผยข้อมูลผ่าน API และตรรกะฝั่งไคลเอ็นต์ และการบังคับใช้ความปลอดภัยฝั่งเซิร์ฟเวอร์ฝั่งไคลเอ็นต์^{[ 34 ]}เพื่อให้สามารถสแกนแอปพลิเคชันหน้าเดียวได้อย่างมีประสิทธิภาพ เครื่องสแกน DAST ต้องสามารถนำทางแอปพลิเคชันฝั่งไคลเอ็นต์ได้อย่างน่าเชื่อถือและทำซ้ำได้ เพื่อให้สามารถค้นพบทุกส่วนของแอปพลิเคชันและดักจับคำขอทั้งหมดที่แอปพลิเคชันส่งไปยังเซิร์ฟเวอร์ระยะไกล (เช่น คำขอ API)

เป็นไปได้ที่จะเพิ่มเหตุการณ์การโหลดหน้าเว็บลงใน SPA โดยใช้ HTML History API ซึ่งจะช่วยในการผสานรวมการวิเคราะห์ ความยากอยู่ที่การจัดการและการรับรองว่าทุกอย่างได้รับการติดตามอย่างถูกต้อง ซึ่งเกี่ยวข้องกับการตรวจสอบรายงานที่หายไปและรายการซ้ำ เฟรมเวิร์กบางตัวมีการผสานรวมการวิเคราะห์ฟรีที่ครอบคลุมผู้ให้บริการการวิเคราะห์รายใหญ่ส่วนใหญ่ นักพัฒนาสามารถผสานรวมเข้ากับแอปพลิเคชันและตรวจสอบให้แน่ใจว่าทุกอย่างทำงานได้อย่างถูกต้อง แต่ไม่จำเป็นต้องทำทุกอย่างตั้งแต่เริ่มต้น^{[ 33 ]}

มีวิธีการบางอย่างในการเร่งความเร็วการโหลดเริ่มต้นของ SPA เช่น การเรนเดอร์ล่วงหน้าแบบเลือกเฉพาะหน้า landing/index ของ SPA การแคช และเทคนิคการแบ่งโค้ดต่างๆ รวมถึงการโหลดโมดูลแบบ lazy-loading เมื่อจำเป็น แต่ก็ไม่สามารถหลีกเลี่ยงความจริงที่ว่าจำเป็นต้องดาวน์โหลดเฟรมเวิร์ก อย่างน้อยก็โค้ดแอปพลิเคชันบางส่วน และจะเรียกใช้ API เพื่อขอข้อมูลหากหน้าเว็บเป็นแบบไดนามิก^{[ 33 ]}นี่คือสถานการณ์การแลกเปลี่ยนแบบ "จ่ายตอนนี้หรือจ่ายทีหลัง" คำถามเกี่ยวกับประสิทธิภาพและเวลารอคอยยังคงเป็นการตัดสินใจที่นักพัฒนาต้องทำ

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

ด้วยวิธีนี้ จึงมีความคล้ายคลึงกันระหว่าง "สถานะ" ใน SPA (Single Page Application) และ "หน้า" ในเว็บไซต์แบบดั้งเดิม เนื่องจากการ "นำทางสถานะ" ในหน้าเดียวกันนั้นคล้ายคลึงกับการนำทางหน้า ดังนั้นในทางทฤษฎี เว็บไซต์ใดๆ ที่ใช้ระบบหลายหน้า สามารถแปลงเป็นเว็บไซต์หน้าเดียวได้ โดยแทนที่เฉพาะส่วนที่เปลี่ยนแปลงในหน้าเดียวกันเท่านั้น

แนวทาง SPA บนเว็บนั้นคล้ายคลึงกับ เทคนิคการนำเสนอ แบบอินเทอร์เฟซเอกสารเดียว (SDI) ซึ่งเป็นที่นิยมในแอปพลิเคชันเดสก์ท็อป แบบเนทีฟ

• แอปพลิเคชันเว็บแบบก้าวหน้า (PWA)
• การเขียนสคริปต์ฝั่งเซิร์ฟเวอร์

• การเปลี่ยนแอปพลิเคชันเว็บแบบหลายหน้าไปเป็นอินเทอร์เฟซ Ajax แบบหน้าเดียว (มหาวิทยาลัยเทคโนโลยีเดลฟท์)
• การเรนเดอร์แบบไดนามิก