@catch well that sounds great I am following the issue you have created.
even if it might not solve the issue but at lease it will be aggregated with other core/theme .js files and this will reduce queuing time.
Thank you.
@catch ok noted, @cilefen lets close this issue since demonstrating what is technically happing is beyond my skills and ability.
thank you all.
Dear @cilefen can you please wait till we have the last comment from @catch?
This is core assets, s3fs has nothing to do with it and the file is requested during execution time and not initiated earlier like images and other files from s3.
Thank you🤍
Dear maintainer @catch now it is not possible to reproduce on only clean installation without s3fs installed to handle public files.
and agree it is not s3fs fault if it copies all public folder and then core modules and handler will ignore locally stored assets and search for this file externally without explicit configuration.
To reproduce attached errors last post:
1-Clean installation.
2- s3fs to handle public files
3- Delete language folder from s3 and keep the folder stored locally.
4- Two errors from translated page that belongs to the language deleted from s3.
@catch I have the performance issue on all ui settings for language detection and what found is even if (Customize Content language detection to differ from Interface text language detection settings) is disabled, system still detects all checked options inside it and behave accordingly.
-/admin/config/media/file-system(Interface translations directory) this setting is useless for the languages folder and its js file and will respect only translations folder regardless where the language folder is located.
-The s3fs S3 File System is enabled for public files: now all assets will remain on local file system like css/js etc even assets injector module will use its files locally like others except /sites/default/files/languages/file.js this file will be served from s3 bucket and will be requested from other js local file during execution time and maybe this is causing redirect and blocking in the main thread and making performance issue.
-with use of s3fs public files if languages folder is removed from local sites/default/files/languages/ no error will be thrown and system will not create new folder etc.
if the same folder ( sites/default/files/languages) is removed from s3 bucket, system will create new empty folder and will throw error from the page requesting this language and translation will show even with errors. (errors attached error1/2).
maybe this logic is causing issues with translated pages and I don't know why languages/file.js needs be requested and served from s3 bucket like a very external file or an image to be lazy loaded.
ps. I used s3fs for private files only and translation performance was much better than s3fs public files.
https://lawyers-dubai.com/
this website is english and Arabic if could please have a look to the home page and click on Arabic from language selector block on the top,
the website has lite-speed server images served from cloudfront it has only 4 webp images and it take time to open translated home page even every time you visit the page and redirect sometimes shows on the network.
-other websites editing and saving translated pages takes 1 min and more posting comments on them takes more and more time.
server support they confirmed all works well from their end.
I am trying to find what makes this behavior.
@cilefen
the latency issue not yet able to reproduce it on simplytest.me but the language detection error was on clean installation on the same site.
the issue is not all translated nodes have the performance issue even on the same site which makes reproduce more difficult but I am still trying to get there.
I just wanted to prove that the language detection system has bugs even on default installation which will make later performance issue on some translated pages (nodes).
to reproduce what is in the last post video.
1- fresh installation.
2-add english as a second language for example.
3-add 1 translated article.
4- /admin/config/regional/language/detection and enable (Customize Content language detection to differ from Interface text language detection settings) uncheck all possible options then save.
5- now not possible to edit translation.
6- disable (Customize Content language detection to differ from Interface text language detection settings) with all its option unchecked.
7- and still system will not be able to show or edit translated content and error logged ( /en-gb/admin/content/files. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException...)
* many scenarios are there for the same error but this is straight to the point.
*attached is happening only on some translated article node with small size.
maybe yes but I checked different server installations and the same performance issue is replicated and caused mainly by the settings of */admin/config/regional/language/detection (Detection and selection).
fresh installation comes with only one setting enabled Language from the URL (Path prefix or domain). with Customize Content language detection to differ from Interface text language detection settings disabled.
so later if the second option is altered there will be maybe 2 separate translation files/requests which causing server to make 3 types of redirect(301/307/202) before sending the response to the browser and this option is not possible to revert back to first default detection settings otherwise only Interface gets translated and the body and title will remain the default language and even access to to content will not be possible and performance issue will disappear as the body and title translation fields will not show.
the only solution now is to keep detection settings as default and to touch them.
I did the same following your steps and the the translated document requested from the server taking time more than the default language node time.
attached is how long took to response from server and the node is only text document.