பயனர்கள் உலாவியில் உள்ள மற்ற கட்டுப்பாடுகளை விட பின்புறப் பொத்தானை (back button) அடிக்கடி அழுத்துகிறார்கள். அவர்கள் முந்தைய திரை, அவர்கள் விட்ட இடத்திலேயே உடனடியாகத் தோன்றுவதை எதிர்பார்க்கிறார்கள். நவீன உலாவிகள் back/forward cache அல்லது bfcache மூலம் அந்த எதிர்பார்ப்பைப் பூர்த்தி செய்கின்றன. நீங்கள் ஒரு பக்கத்திலிருந்து வெளியேறும்போது, அந்தப் பக்கத்தை அழிப்பதற்குப் பதிலாக, உலாவி அதை நினைவகத்தில் (memory) உறைய வைக்கிறது (freeze). நீங்கள் மீண்டும் வரும்போது, அது ஒரு ஸ்னாப்ஷாட்டினை (snapshot) மீட்டெடுக்கிறது. உலாவி HTML-ஐப் பகுப்பாய்வு செய்வதையும் (parsing), JavaScript-ஐ மீண்டும் இயக்குவதையும், லேஅவுட்டை (layout) மீண்டும் கணக்கிடுவதையும் தவிர்க்கிறது. பக்கம் முழுமையாக அழியாததால், அதன் முடிவு உடனடியாக நடப்பது போன்ற உணர்வைத் தருகிறது.
bfcache உண்மையில் என்ன செய்கிறது
ஒரு சாதாரணப் பக்கத்தை ஏற்றுவது (page load) அதிக வளங்களைச் செலவழிக்கும் செயலாகும். உலாவி வளங்களைச் சேகரிக்க வேண்டும், HTML-ஐ டோக்கனைஸ் (tokenize) செய்ய வேண்டும், DOM-ஐ உருவாக்க வேண்டும், ஸ்கிரிப்ட்களை இயக்க வேண்டும், ஸ்டைல்களைத் தீர்மானிக்க வேண்டும், லேஅவுட்டைச் செய்ய வேண்டும், பிக்சல்களைப் பெயிண்ட் (paint) செய்ய வேண்டும் மற்றும் லேயர்களை இணைக்க வேண்டும் (composite layers). bfcache அந்தப் பக்கத்தை RAM-இல் உறைய வைக்கப்பட்ட நிலையில் வைத்திருப்பதன் மூலம் இவை அனைத்தையும் தவிர்க்கிறது. இது ஒரு டிஸ்க் கேச் (disk cache) அல்ல. பயனர் அடுத்தப் பக்கத்தைப் படிக்கும்போது, JavaScript heap, ஸ்க்ரோல் நிலை (scroll position) மற்றும் ஃபார்ம் நிலை (form state) உள்ளிட்ட ரெண்டர் செய்யப்பட்ட பக்கம் நினைவகத்தில் இருக்கும். பயனர் 'back' பொத்தானைக் கிளிக் செய்யும்போது, உலாவி அந்த ஸ்னாப்ஷாட்டினை மீண்டும் செயல்படச் செய்து (thaw), ஒரு pageshow நிகழ்வை (event) உருவாக்குகிறது. நெட்வொர்க்கைத் தொடாமலோ அல்லது லேஅவுட்டை மீண்டும் முதலிலிருந்து செய்யாமலோ பக்கம் தொடர்கிறது. மெதுவான சாதனங்கள் அல்லது நிலையற்ற இணையத் தொடர்பைப் பயன்படுத்தும் பயனர்களுக்கு, bfcache மூலம் மீட்டெடுப்பதற்கும் புதிய பக்கத்தை ஏற்றுவதற்கும் இடையிலான வித்தியாசம் நூற்றுக்கணக்கான மில்லிசெகண்டுகள் அல்லது அதற்கு மேலாக இருக்கலாம்.
எவை இதைத் தடுக்கின்றன
bfcache-ஐத் தடுப்பது எது என்பதைத் துல்லியமாகக் கண்டறிய ஒரு டெவலப்பர் சமீபத்தில் ஒரு சோதனையைச் செய்தார். அவர் சந்தேகத்திற்குரிய தடுப்பான்களை ஒவ்வொன்றையும் சோதிக்கும் வகையில் ஆறு எளிய பக்கங்களை உருவாக்கினார், பின்னர் ஒரு பக்கத்திலிருந்து வெளியேறி 'back' பொத்தானை அழுத்திப் பார்த்தார். முடிவுகள் தெளிவாக இருந்தன.
விசித்திரமான ஹெடர்கள் (headers) அல்லது ஸ்கிரிப்ட்கள் இல்லாத ஒரு அடிப்படைப் பக்கம் (baseline page) வெற்றிகரமாக மீட்டெடுக்கப்பட்டது. a beforeunload listener கொண்ட ஒரு பக்கமும் எந்தப் பிரச்சினையும் இன்றி மீட்டெடுக்கப்பட்டது. ஆச்சரியப்படும் விதமாக, Cache-Control: no-store மூலம் வழங்கப்பட்ட ஒரு பக்கமும் bfcache-க்குள் நுழைந்தது, இது பழைய வழிகாட்டுதல்களுக்கு முரணாக உள்ளது. உறைய வைக்கத் தேவையில்லாத அளவுக்கு மிகவும் டைனமிக் (dynamic) ஆகத் தோன்றும் ஒரு நேரலை வலைப்பதிவு (live blog) கட்டுரை கூட வெற்றிகரமாக மீட்டெடுக்கப்பட்டது.
இரண்டு பக்கங்கள் தோல்வியடைந்தன. an unload event listener கொண்ட ஒரு பக்கத்தை மீட்டெடுக்க முடியவில்லை. an open WebSocket connection கொண்ட ஒரு பக்கமும் தடுக்கப்பட்டது. இந்த இரண்டு தோல்விகளும் நிஜமான உற்பத்தித் தளங்களில் (production sites) தினசரி ஏற்படும் சிக்கல்களைக் காட்டுகின்றன.
unload நிகழ்வு எனும் பொறி
கடைசி நேரச் சுத்திகரிப்புப் பணிகளுக்காக (cleanup) unload நிகழ்வு நீண்டகாலமாகப் பயன்படுத்தப்பட்டு வருகிறது. டெவலப்பர்கள் இதனை அனலிட்டிக்ஸ் பீக்கன்களை (analytics beacons) அனுப்பவும், டைமர்களை நிறுத்தவும் அல்லது தற்காலிக நிலையை அழிக்கவும் பயன்படுத்துகின்றனர். பிரச்சனை என்னவென்றால், பக்கம் மீண்டும் உயிர் பெறக்கூடும் என்ற கருத்தின் அடிப்படையிலேயே bfcache உருவாக்கப்பட்டுள்ளது. உலாவி ஒரு unload listener-ஐக் கண்டால், அந்தப் பக்கம் முழுமையாக அழிக்கப்பட வேண்டும் என்று எதிர்பார்க்கிறது எனக் கருதி, அதை உறைய வைக்க மறுத்துவிடும். இணைக்கப்பட்ட செயல்பாடு (function) காலியாக இருந்தாலும் அது பொருட்டல்ல. அந்த லிசனர் (listener) இருப்பது மட்டுமே அனைத்து நவீன உலாவிகளிலும் கேச்சிங் செய்வதைத் தடுக்க போதுமானதாகும்.
இதற்கு மாற்றாக pagehide உள்ளது. இந்தப் பக்கம் bfcache-க்காக உறைய வைக்கப்படும் போதும் மற்றும் அது உண்மையில் நீக்கப்படும் போதும் இந்த நிகழ்வு நிகழ்கிறது. இரண்டிற்கும் இடையே வேறுபடுத்துவது உங்களுக்குத் தேவைப்பட்டால், பக்கம் bfcache-க்குள் நுழையும் போது event.persisted property 'true' என்று இருக்கும். இருப்பினும், பெரும்பாலான teardown பணிகளுக்கு, pagehide இரண்டு வழிகளுக்கும் பொருந்தும். ஒவ்வொரு சுத்திகரிப்பு தர்க்கத்தையும் (cleanup logic) unload-லிருந்து pagehide-க்கு மாற்றவும். பின்னர், மூன்றாம் தரப்பு அனலிட்டிக்ஸ் ஸ்னிப்பெட்டுகள் (analytics snippets) அல்லது பழைய பிளகின்களில் மறைந்துள்ளவை உட்பட அனைத்து unload listener-களையும் முழுமையாக நீக்கவும்.
செயல்பாட்டில் உள்ள இணைப்புகள் எனும் பொறிகள்
திறந்த நிலையில் உள்ள நெட்வொர்க் அல்லது சேமிப்பு இணைப்பு, உங்கள் பக்கம் இன்னும் உண்மையான வேலைகளைச் செய்து கொண்டிருக்கிறது என்பதைக் குறிக்கிறது. உலாவி வழிசெலுத்தலின் (navigation) தருணத்தில் செயல்பாட்டில் உள்ள வளங்களைச் சரிபார்க்கிறது. ஒரு திறந்த WebSocket, ஒரு செயல்பாட்டில் உள்ள WebRTC peer connection அல்லது ஒரு நீடித்த IndexedDB இணைப்பு ஆகியவற்றைக் கண்டால், அது உறைய வைப்பதைத் தடுத்து பக்கத்தை இயல்பாகவே நீக்கிவிடும். தரவுகள் (bytes) இன்னும் பரிமாறப்பட்டுக் கொண்டிருக்கும்போது அந்த ஸ்னாப்ஷாட்டினை நம்ப முடியாது.
இந்த வளங்களை நீங்கள் ஒரு pagehide listener-க்குள் மூட வேண்டும். உங்கள் WebSocket-ன் close முறையை (method) அழைக்கவும். WebRTC peer இணைப்புகளை நிறுத்தவும். நிலுவையில் உள்ள எந்தவொரு IndexedDB பரிவர்த்தனைகளையும் (transactions) ரத்து செய்யவும் அல்லது உறுதிப்படுத்தவும். பயனர் திரும்ப வரும்போது உங்கள் ஆப்பிற்கு (app) அந்த சேனல்கள் தேவைப்பட்டால், அவற்றை pageshow-க்குள் மீண்டும் திறக்கவும். இந்த close-on-pagehide, restore-on-pageshow முறை, செயல்பாடுகளை இழக்காமல் பக்கத்தை உடனடியாகப் பின்புற வழிசெலுத்தலுக்கு (back navigation) தகுதியுடையதாக வைத்திருக்கும்.
no-store எனும் ஆச்சரியம்
பல ஆண்டுகளாக, Cache-Control: no-store என்பது bfcache-ஐத் தடுக்கும் என்று பொதுவான கருத்து இருந்தது. Chrome 2025-ல் அந்த நடத்தையை மாற்றியது. no-store மூலம் வழங்கப்பட்ட ஒரு பக்கம் இப்போது bfcache-க்குள் நுழைய முடியும். சேமிக்கப்பட்ட நிலை (saved state) செல்லாததாக மாறும் வகையில் அங்கீகார நிலைகள் (authentication states) அல்லது குக்கீகள் (cookies) மாறினால் மட்டுமே உலாவி அந்த உறைய வைக்கப்பட்ட ஸ்னாப்ஷாட்டினைப் பின்னர் நீக்கும். நீங்கள் no-store-ஐப் பயன்படுத்தி வந்தால்