ബ്രൗസറിലെ മറ്റ് നിയന്ത്രണങ്ങളെക്കാൾ കൂടുതൽ തവണ ഉപയോക്താക്കൾ ബാക്ക് ബട്ടൺ അമർത്താറുണ്ട്. അവർ മുൻപത്തെ സ്ക്രീൻ അവർ നിർത്തിയ അതേ സ്ഥാനത്ത് ഉടൻ തന്നെ പ്രത്യക്ഷപ്പെടുമെന്ന് പ്രതീക്ഷിക്കുന്നു. ആധുനിക ബ്രൗസറുകൾ ബാക്ക്/ഫോർവേഡ് ക്യാഷെ (back/forward cache) അല്ലെങ്കിൽ bfcache ഉപയോഗിച്ച് ആ പ്രതീക്ഷ നിറവേറ്റുന്നു. നിങ്ങൾ ഒരു പേജിൽ നിന്ന് മാറിപ്പോകുമ്പോൾ അത് നശിപ്പിക്കുന്നതിന് പകരം, ബ്രൗസർ അതിനെ മെമ്മറിയിൽ ഫ്രീസ് (freeze) ചെയ്യുന്നു. നിങ്ങൾ തിരികെ വരുമ്പോൾ, അത് ഒരു സ്നാപ്പ്ഷോട്ട് (snapshot) പുനഃസ്ഥാപിക്കുന്നു. ബ്രൗസർ HTML പാഴ്സിംഗ്, ജാവാസ്ക്രിപ്റ്റ് വീണ്ടും പ്രവർത്തിപ്പിക്കൽ, ലേഔട്ട് വീണ്ടും കണക്കാക്കൽ എന്നിവ ഒഴിവാക്കുന്നു. പേജ് ഒരിക്കലും പൂർണ്ണമായും ഇല്ലാതാകാത്തതിനാൽ ഫലം വളരെ വേഗത്തിൽ അനുഭവപ്പെടുന്നു.
bfcache യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നത്
ഒരു സാധാരണ പേജ് ലോഡ് ചെയ്യുന്നത് ചിലവേറിയ പ്രക്രിയയാണ്. ബ്രൗസർ റിസോഴ്സുകൾ ശേഖരിക്കണം, HTML ടോക്കണൈസ് ചെയ്യണം, DOM നിർമ്മിക്കണം, സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കണം, സ്റ്റൈലുകൾ പരിഹരിക്കണം, ലേഔട്ട് ചെയ്യണം, പിക്സലുകൾ പെയിന്റ് ചെയ്യണം, ലെയറുകൾ കോമ്പോസിറ്റ് ചെയ്യണം. bfcache പേജിനെ RAM-ൽ ഫ്രീസ് ചെയ്ത അവസ്ഥയിൽ നിലനിർത്തുന്നതിലൂടെ ഇതിൽ മിക്കവയും ഒഴിവാക്കുന്നു. ഇതൊരു ഡിസ്ക് ക്യാഷെ (disk cache) അല്ല. ഉപയോക്താവ് അടുത്ത പേജ് വായിക്കുമ്പോൾ, ജാവാസ്ക്രിപ്റ്റ് ഹീപ്പ് (JavaScript heap), സ്ക്രോൾ പൊസിഷൻ (scroll position), ഫോം സ്റ്റേറ്റ് (form state) എന്നിവയുൾപ്പെടെ റെൻഡർ ചെയ്ത പേജ് മെമ്മറിയിൽ ഇരിക്കുന്നു. ഉപയോക്താവ് ബാക്ക് ബട്ടൺ ക്ലിക്ക് ചെയ്യുമ്പോൾ, ബ്രൗസർ ആ സ്നാപ്പ്ഷോട്ട് അൺഫ്രീസ് ചെയ്യുകയും ഒരു pageshow ഇവന്റ് ഫയർ ചെയ്യുകയും ചെയ്യുന്നു. നെറ്റ്വർക്കിനെ ആശ്രയിക്കാതെയോ ലേഔട്ട് ആദ്യം മുതൽ ചെയ്യുകയോ ചെയ്യാതെ തന്നെ പേജ് വീണ്ടും പ്രവർത്തിക്കുന്നു. സാവധാനത്തിൽ പ്രവർത്തിക്കുന്ന ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്നവർക്കോ മോശം കണക്ഷനുള്ളവർക്കോ, ഒരു bfcache പുനഃസ്ഥാപനവും പുതിയൊരു ലോഡും തമ്മിലുള്ള വ്യത്യാസം നൂറുകണക്കിന് മില്ലിസെക്കൻഡുകളോ അതിലധികമോ ആകാം.
എന്താണ് ഇത് തടസ്സപ്പെടുത്തുന്നത്
എന്താണ് കൃത്യമായി bfcache-നെ തടസ്സപ്പെടുത്തുന്നത് എന്ന് കണ്ടെത്താൻ ഒരു ഡെവലപ്പർ അടുത്തിടെ ഒരു പരീക്ഷണം നടത്തി. സംശയിക്കപ്പെടുന്ന ഓരോ തടസ്സങ്ങളെയും പരിശോധിക്കുന്നതിനായി ആറ് ലളിതമായ പേജുകൾ അദ്ദേഹം നിർമ്മിച്ചു, തുടർന്ന് അവയിൽ നിന്ന് മാറിപ്പോയി ബാക്ക് ബട്ടൺ അമർത്തി. ഫലങ്ങൾ വ്യക്തമായിരുന്നു.
പ്രത്യേക ഹെഡറുകളോ സ്ക്രിപ്റ്റുകളോ ഇല്ലാത്ത ഒരു ബേസ്ലൈൻ പേജ് വിജയകരമായി പുനഃസ്ഥാപിക്കപ്പെട്ടു. beforeunload ലിസണറുള്ള ഒരു പേജും പ്രശ്നമില്ലാതെ പുനഃസ്ഥാപിക്കപ്പെട്ടു. അത്ഭുതകരമെന്നു പറയട്ടെ, Cache-Control: no-store ഉപയോഗിച്ച് നൽകിയ ഒരു പേജും bfcache-ലേക്ക് പ്രവേശിച്ചു, ഇത് പഴയ നിർദ്ദേശങ്ങൾക്ക് വിരുദ്ധമാണ്. ഫ്രീസ് ചെയ്യാൻ കഴിയാത്തത്ര ഡൈനാമിക് ആണെന്ന് തോന്നാവുന്ന ഒരു ലൈവ് ബ്ലോഗ് ലേഖനം പോലും വിജയകരമായി പുനഃസ്ഥാപിക്കപ്പെട്ടു.
രണ്ട് പേജുകൾ പരാജയപ്പെട്ടു. unload ഇവന്റ് ലിസണറുള്ള ഒരു പേജ് പുനഃസ്ഥാപിക്കാൻ കഴിഞ്ഞില്ല. ഒരു ഓപ്പൺ WebSocket കണക്ഷനുള്ള പേജും തടയപ്പെട്ടു. ഈ രണ്ട് പരാജയങ്ങളും യഥാർത്ഥ പ്രൊഡക്ഷൻ സൈറ്റുകളെ ദിവസവും കുടുക്കുന്ന കെണികളെ ചൂണ്ടിക്കാണിക്കുന്നു.
unload ഇവന്റ് കെണി
അവസാന നിമിഷത്തെ ക്ലീനപ്പിനായി (cleanup) unload ഇവന്റ് കാലങ്ങളായി ഉപയോഗിച്ചുവരുന്നു. അനലിറ്റിക്സ് ബീക്കണുകൾ ഫ്ലഷ് ചെയ്യാനോ, ടൈമറുകൾ നിർത്താനോ, താൽക്കാലിക സ്റ്റേറ്റ് മായ്ച്ചുകളയാനോ ഡെവലപ്പർമാർ ഇത് ഉപയോഗിക്കുന്നു. എന്നാൽ പേജ് വീണ്ടും സജീവമാകാൻ സാധ്യതയുണ്ട് എന്ന ആശയത്തിലാണ് bfcache നിർമ്മിച്ചിരിക്കുന്നത് എന്നതാണ് പ്രശ്നം. ബ്രൗസർ ഒരു unload ലിസണർ കാണുകയാണെങ്കിൽ, പേജ് പൂർണ്ണമായും നശിപ്പിക്കപ്പെടാൻ ഉദ്ദേശിക്കുന്നു എന്ന് അത് അനുമാനിക്കുകയും അതിനെ ഫ്രീസ് ചെയ്യാൻ വിസമ്മതിക്കുകയും ചെയ്യുന്നു. അതിൽ ചേർത്തിരിക്കുന്ന ഫംഗ്ഷൻ കാലിയാണെങ്കിലും അത് പ്രശ്നമല്ല. ആ ലിസണറിന്റെ സാന്നിധ്യം തന്നെ എല്ലാ ആധുനിക ബ്രൗസറുകളിലും ക്യാഷിംഗ് തടയാൻ മതിയാകും.
ഇതിന് പകരമായി pagehide ഉപയോഗിക്കാം. പേജ് bfcache-നായി ഫ്രീസ് ചെയ്യപ്പെടുമ്പോഴും അത് യഥാർത്ഥത്തിൽ ഒഴിവാക്കപ്പെടുമ്പോഴും ഈ ഇവന്റ് പ്രവർത്തിക്കുന്നു. ഇവ രണ്ടും തമ്മിൽ വേർതിരിക്കണമെങ്കിൽ, പേജ് bfcache-ലേക്ക് പോകുമ്പോൾ event.persisted പ്രോപ്പർട്ടി true ആയിരിക്കും. മിക്ക ക്ലീനപ്പ് ജോലികൾക്കും pagehide മതിയാകും. അതിനാൽ എല്ലാ ക്ലീനപ്പ് ലോജിക്കും unload-ൽ നിന്ന് മാറ്റി pagehide-ലേക്ക് മാറ്റുക. തുടർന്ന്, തേർഡ് പാർട്ടി അനലിറ്റിക്സ് സ്നിപ്പറ്റുകളിലോ പഴയ പ്ലഗിനുകളിലോ ഉള്ളവ ഉൾപ്പെടെ എല്ലാ unload ലിസണറുകളും പൂർണ്ണമായും നീക്കം ചെയ്യുക.
ആക്റ്റീവ് കണക്ഷൻ കെണികൾ
ഒരു ഓപ്പൺ നെറ്റ്വർക്ക് അല്ലെങ്കിൽ സ്റ്റോറേജ് കണക്ഷൻ നിങ്ങളുടെ പേജ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നുണ്ടെന്ന സൂചന നൽകുന്നു. നാവിഗേഷൻ സമയത്ത് ബ്രൗസർ ആക്റ്റീവ് റിസോഴ്സുകൾ പരിശോധിക്കുന്നു. ഒരു ഓപ്പൺ WebSocket, ആക്റ്റീവ് WebRTC പിയർ കണക്ഷൻ, അല്ലെങ്കിൽ നിലനിൽക്കുന്ന IndexedDB കണക്ഷൻ എന്നിവ കണ്ടെത്തിയാൽ, ബ്രൗസർ ഫ്രീസ് ചെയ്യുന്നത് നിർത്തി പേജിനെ സാധാരണ രീതിയിൽ നശിപ്പിക്കുന്നു. ഡാറ്റാ കൈമാറ്റം നടക്കുന്നുണ്ടെങ്കിൽ സ്നാപ്പ്ഷോട്ട് വിശ്വസിക്കാൻ കഴിയില്ല.
ഈ റിസോഴ്സുകൾ ഒരു pagehide ലിസണറിനുള്ളിൽ നിങ്ങൾ ക്ലോസ് ചെയ്യണം. നിങ്ങളുടെ WebSocket-ന്റെ close മെത്തേഡ് വിളിക്കുക. WebRTC പിയർ കണക്ഷനുകൾ നിർത്തുക. നിലവിലുള്ള ഏതെങ്കിലും IndexedDB ഇടപാടുകൾ (transactions) അബോർട്ട് ചെയ്യുകയോ കമിറ്റ് ചെയ്യുകയോ ചെയ്യുക. ഉപയോക്താവ് തിരികെ വരുമ്പോൾ നിങ്ങളുടെ ആപ്പിന് ഈ ചാനലുകൾ ആവശ്യമാണെങ്കിൽ, അവ pageshow-നുള്ളിൽ വീണ്ടും തുറക്കുക. ഈ close-on-pagehide, restore-on-pageshow രീതി ഉപയോഗിക്കുന്നതിലൂടെ ഫംഗ്ഷണാലിറ്റി നഷ്ടപ്പെടാതെ തന്നെ ഇൻസ്റ്റന്റ് ബാക്ക് നാവിഗേഷന് പേജ് അനുയോജ്യമായിരിക്കും.
no-store സർപ്രൈസ്
വർഷങ്ങളായി, Cache-Control: no-store ഉപയോഗിക്കുന്നത് bfcache തടയുമെന്നായിരുന്നു പൊതുവായ ധാരണ. എന്നാൽ 2025-ൽ Chrome ആ രീതി മാറ്റി. no-store ഉപയോഗിച്ച് നൽകുന്ന ഒരു പേജിന് ഇപ്പോൾ bfcache-ലേക്ക് പ്രവേശിക്കാം. ഓതന്റിക്കേഷൻ സ്റ്റേറ്റുകളോ കുക്കികളോ സേവ് ചെയ്ത സ്റ്റേറ്റിനെ അസാധുവാക്കുന്ന രീതിയിൽ മാറുന്നുണ്ടെങ്കിൽ മാത്രമേ ബ്രൗസർ ഫ്രീസ് ചെയ്ത സ്നാപ്പ്ഷോട്ട് പിന്നീട് നീക്കം ചെയ്യുകയുള്ളൂ. നിങ്ങൾ no-store ഉപയോഗിച്ചുവരികയാണെങ്കിൽ...