It's my first deploying a real application to production, and we are having some problems with speed on the website. The main problem right now is the time it takes to load the index page, so I know it's really a thing about queries or anything like that.
We are using Heroku + Puma + CloudFront as a CDN to server our static assets. Thing is, I'm not really that sure this should be happening:
As you can see, application.js and application.css is being loaded twice, one from cloudfront and one from /assets. Should this be happening? This is only an example but is happening too with some images and .svgs that I have, they are 'being loaded' twice.
Important to notice that the call for including both js and css is only being made once in the head tag
Thanks
The assets are being loaded once, but via two HTTP calls, the first being a redirect to the second. You can see that the first application.js results in a redirect (see below the URL in the third column) to the second application.js, and the same goes for application.css
To avoid the redirect, you need to configure Rails to load assets from a different domain. To do so, set config.action_controller.asset_host in the relevant environment config file, like so:
config.action_controller.asset_host = "http://XXXXXXX.cloudfront.net"
Related
After an automatic WordPress update the plugin forms (Contact Form 7) now display a slash just below them and are no longer firing the wpcf7mailsent listener event, so it is no longer being redirected to the thanks page after submitting the form.
This error: “the server responded with a status of 409 or also known as net :: ERR_ABORTED 409” from what I see is a problem loading styles.css and scripts.js files.
This must be the reason why it is not issuing the wpcf7mailsent listener event and a slash just below the forms.
Strangely if on the same page I manually click and open the styles.css file via URL, the file starts to load on the page and it stops showing that bar just below the form.
For this reason I am saying that you are not loading the styles.css and scripts.js files, as they do not even appear in the uploaded files folder, just after I open them by URL.
Here’s the test I did to show it:
The error happening:
https://ibb.co/Vvm8jwG
Did not load CSS file and JS file:
https://ibb.co/kHszgW9
After I open the CSS style link that says it didn’t load:
https://ibb.co/FXcLRXQ
https://ibb.co/997nMgK
You no longer see the error that you did not upload the CSS file and now the file has been uploaded to the folder showing the contents. The same will happen with the JS file if I manually load it as the CSS file.
https://ibb.co/jGPQ2MH
https://ibb.co/chVjRTQ
What I already tried to do to fix, but it didn’t work:
– I disabled several plugins
– I updated the plugin
– I reinstalled the plugin
– I tested in other browsers, the error persists
Other sites with Contact Form 7 are also experiencing the same.
Environment Settings:
Theme: Javelin
WordPress: 5.2.4
PHP: 7.1.24
Hosting: Hostgator
The page I need help with: https://verdecia.com.br/central-de-atendimento/
For anyone who is facing this issue, this is a known issue in bluehost and hostgator hosting. Basically the root reason for this seems to be that they are blocking image/js/css or other assets in any path with contact string.
The reason that contact form 7 assets are randomly blocked is probably also due to this same reason.
I had html websites running on my server where contact (or any other) page with assets in for example /images/contact/ folder also did not load with 409 conflict error, due to the contact path in the assets folder.
Unfortunately I found no solution to this just like many many users out there. Check out these links:
Link 1
Link 2
What is the solution?
Well wasting time with hosting provider support is of no use. I just use
hostgator/bluehost for development purpose. There are many hosting providers out there,
so next time you can choose some other one, especially for live websites.
For custom websites, avoid naming your assets folder to anything that has contact in it.
For CF7 in wordpress stop loading the assets in wp-config file using define( 'WPCF7_LOAD_JS', false ); define( 'WPCF7_LOAD_CSS', false ); and manually load the files in the header by separately downloading the files and importing them.
EDIT:
I have been using a simpler fix recently when using CF7, just rename the plugin folder from contact-form-7 to anything without contact keyword, like cf7. This will start loading all assets without the conflict.
I am using swPrecache, for loading my static assets of my PWA, to support offline mode. It working great. My setup is something like:
https://www.myexampledomain.com/myapp/ loads static index.html and which in turn loads uses swPrecache to load static assets like JS, Images, CSS,etc. Mind you these all are loaded from the same domain e.g www.myexampledomain.com/myapp/js/file1.js
But my swprecache list has decent number of files and takes some time to download on slower internet connection. FYI, I am already delaying the service worker registration to something like "load" event.
So here is what I am trying now. I need someone to validate if this is possible:
https://www.myexampledomain.com/myapp/ loads the static html files as before.
Have swPrecache intercept the static requests that go to app domain (e.g https://www.myexampledomain.com/myapp/js/file1.js) and instead fetch these to a CDN endpoint? (e.g https://some.cloudfront.com/myapp/js/file1.js).
Once downloaded the swPrecache continues to work as usual.
So essentially I am hoping to have swPrecache proxy the static asset requests, to a CDN to make it faster to download during the initial load.
Any comments/pointers on this will help.
You can use the stripPrefixMulti option in sw-precache to change the URLs that are written to your service worker file. It's fairly brute-force, though, so it helps if there's a common prefix that is shared by all the assets that will be served from the CDN.
For example, if everything that will be served off of the CDN is stored in a local assets/ directory, and their paths on the CDN will start with https://my-cdn.com/assets/, you can use
{
stripPrefixMulti: {'assets/': 'https://my-cdn.com/assets/'},
// ... other sw-precache options...
}
You'll want to make sure that whenever a local file changes as part of your build process the copy of the file on the CDN also changes immediately, or you'll run the risk of the versioning info generated for the local files being out of sync with what's on the CDN.
yes, you can use
{
stripPrefixMulti: {'assets/': 'https://my-cdn.com/assets/'},
// ... other sw-precache options...
}
but I'm sure you will face new CORS problem. I'm working on it too
I need to include a plugin javascript stored in folder app/assets/plugins/
In application.html.erb:
<script> var plugin_path = "<%= Rails.root.join("app", "assets", "plugins") %>";</script>
<%= javascript_include_tag 'script' %>
In script.js:
loadScript(plugin_path + '/pluginA/js/pluginA.js', function() {
Init(false);
});
When I start my server and load my homepage, terminal displays a message like
[GET] cannot find route
'/home/myapp/app/assets/plugins/pluginA/js/pluginA.js'
This url is correct (I suppose). So what is the problem here and how to load this plugin in a correct way?
The heart of this issue is that /home/myapp/app/assets/plugins/pluginA/js/pluginA.js is not a URL. It's a filesystem path. Your web browser currently believes that's a route in your Rails app (you should be able to verify a 404 in your development.log for your Rails app for that path.
The easiest fix may be to use file:///home/myapp/app/assets/plugins/pluginA/js/pluginA.js which is a URL. You may wish to try that during development.
There is no chance this will work as you move this work to staging or production, where the site will be accessed by other web browsers. You will need to learn how to integrate this plugin into the Rails asset pipeline. (It looks like requiring your script in application.js, and initializing it near the bottom of that file may be appropriate, but this is difficult to say without more knowledge.)
just about to upload my first site and have just been doing some research into how to do this whilst I await my package to be upgraded to include mysql databases.
Quick question - do I need to name my homepage 'index.html'?, and therefore change every 'home.html' link on every page of my site to 'index.html'? I've also heard 'index.htm', what is the difference between html and htm?
From what I have read, this is good practice (well, even better practice would have been to call it that from the start!) but also that you can change the default page in the htaccess file. Is this correct, and if so, is there a downside?
I am not relishing the task of changing every homepage link, but if it is considered a better option, I will.
Thanks
Yes you can change the default index file and even the ordering. Some options are:
a) You are using server side scripting - php for example
Add this into a .htaccess file
DirectoryIndex index.php index.html
b) You are not using any server side scrpting
DirectoryIndex index.html
This way you do not have to deal with default values such as home.htm or index.htm
Browser will automatically open the "index" file. Though its true - you can redirect the browser to your home.html but it is always a better option to name your start-site index.html
about the difference between HTML and HTM... There is none.
Years ago, in DOS times, extensions were only 3 characters long 'htm'.
Now, we got longer extensions, like 'html' with 4 characters.
It's preferred to make it as index.html as index.html is a better practise than home.html.
Yes, you can change the index file via .htaccess and .html and .htm has no difference, it's just different extensions for the same HTML.
Yes you can have home.html, however, you will have to set your default site preferences in your web server to serve that instead of the default "index.html".
Whilst there is no difference it would be beneficial to have index.html, as it is the default and it will help you reduce web server config time if you are using clean-urls e.g. domain.com/contactus, domain.com/aboutus, etc instead of domain.com/contactus/home.html and domain.com/aboutus/home.html, etc.
Lastly, there is no difference between .html and .htm it is just a preference thing.
I'm developing an extjs application which boots in two steps. At the start it pops up a login& password window, loading only the necessary js resources. If login successfully then it starts the viewport by loading all the remaing js files.
at the login time it loads ext-all.js and couple of app js file.
after the login, it loads the controllers that load the required js files.
the problem is that I want to minify and compress the js files, but when using the sencha cmd tool
>sencha create jsb -a index.html -p app.jsb3
>sencha build -p app.jsb3 -d .
>java -jar ycompressor.jar --type js -o app-all-compressed.js app-all.js
the resulting app-all.js and app-all-compressed.js contain only the resources needed at the login phase only.
Then I tried to build manually a jsb3 file that generates a minified and compressed post-all.js including by hands the required js by the viewport (second phase boot), then loaded this file after successfully passed login this way:
onLoginSuccess(){
Ext.Loader.loadScript({
url: 'post-all.js',
scope: me,
onLoad: function() {
//controllers loading
...
problem was that even if post-all.js is loaded, the resuorce are still loaded unminified.
Resources are minified and compressed correctly in post-all.js but it seems that requires[" ..."] loads the unminified copy of the resources, so I have each reasource loaded 2 times
Any idea?
thanks
It is a lot easier to load everything at once. There is no reason to load in two times.
Visual : Even if you load all javascript, you show only the login dialog. All the rest, you show only after successful login.
Security : If you secure the access to all server resource with the session, a malicious user might be able to display some parts of the user interface, but he could never get to view any data nor do anything else.
Loading time : Considering the size of the ExtJs library, the gain in loading time will be minimal.
Like this you've worked around your problem, and you can enjoy the simplicity of the regular ExtJs deployment with Sencha cmd.