I use https protocol for my login, registration, admin pages of my web app.
If I don't write some htaccess rule, all my static files images, css, js, ect. are loaded through https too.
Does this decrease the performance of my app and is it better to use http for all static resources of my app?
If you attempt to include a static file over HTTP while the original dynamic page was served through HTTPS the browser might emit a warning that this webpage is trying to server non secure content over a secure channel. So you should avoid doing that. There's of course a penalty from serving a resource over HTTPS but static files are usually cached by browsers so that shouldn't be that much of a problem. Also you might consider minifying and combining your scripts into a single one in order to reduce the number of HTTP(S) requests made to the server. That's where you will gain most.
For your images you might also consider using a technique called CSS sprites.
Related
We have an existing web product that uses a lot of static images, css files, js libs and other static content. Whenever a page is loaded, browser usually has to make dozens of additional HTTP requests to retrieve all that content which almost doubles load time. We wanted to put the content to Amazon's CloudFront to improve the load times and I am trying to choose between the two possible ways of implementing this.
1). Going through every single reference to such content and replacing it with a request to CloudFront. E.g. images/image.jpg would become qwerty.cloudfront.net/images/image.jpg. This will result in a "true" integration but it would be practically impossible for me to implement this. Especially for different JS libs which come with their own images that they choose dynamically.
2). Leave images/image.jpg as it is and tell server to do 301 to CloudFront for such requests. The problem with this implementation is that the requests will actually have to be routed all the way to the server before server can redirect them to CloudFront.
So basically I am not sure if 301 is a good idea. This will work only if the time to route request to our server is negligible compared to the time it takes server to send this image back to the client. Additionally I don't know how easily server will handle load spikes - will it survive if a traffic spike happens and it will have to serve a lot of 301 redirects (although I assume it will, since doing this should be much easier than retrieving the files from file system and outputting them). Please let me know if you have any experience with this or thoughts on the matter (including other potential ways of implementing this integration).
I'm interested in using a CDN for storing some assets in my web application. However, instead of hardcoding the CDN url into each of my assets (Javascript and CSS), I'd like to use a simple RewriteRule to redirect requests for assets to a CDN.
However, I'm wondering if there are some disadvantages to this method. For one, the server is still processing requests for assets since it needs to identify and redirect such requests. And another, I'm concerned that the CDN will look at the location of my server as opposed to the location of my client.
Has anyone ever dealt with this kind of strategy, and what was your solution? Thanks!
That's not a great strategy, as it completely nullifies any benefits or using a CDN. For every request for a static asset, your server has to process a request, which is exactly what you're trying to avoid.
Bite the bullet, and set up your application to be configurable (you do use basic configuration, correct?) enough so that you change base URLs for all your static assets.
Using IIS6 on win2003, if I have an image server is it more efficient to serve up images as http than https? Also is it possible to serve up images as http on a webpage than is https.
Like if this html file: Secure.html is on a server that forces https to be used, but inside https://www.myultrahighsecurewebsite.com/Secure.html/
and I have a image like so:
<img src="http://www.notsosecureatall.com/imagecode/serveupanimage.aspx?id=1&auth=1" />
Is this a good way to serve up images? Is there a better way? Also I wanted to have a defacto site to serve up images so I don't have to push images as well as code and markup between development and live. Should the images or certain type of images like tiff, png, svg, etc... be on https vs http or does it matter?
If I do implement an image server or a page dedicated to keeping track of images, I just want an easy system to push images from development to my production environment without getting snagged on installation problems. But also not having to worry about customers having access to images until a version has been properly approved.
It will be more efficient from a CPU (client & server) and network point of view to use plain old HTTP. You'll avoid the overhead of TLS traffic and encryption/decryption of data.
The scenario (mixed HTTP/HTTPS) you present will often annoy a user though. You'll get a warning similar to "This page has unsecured content" (this is getting at the HTTP-only images).
See Loading http content on https website for more info (and additional gotchas) on the previous paragraph.
Are you sure that you need to worry about efficient loading of images? Don't overengineer this. Please share some more details if you've noticed that this is a problem.
I have an application built with codeigniter and am running tests for rendering time etc, i have noticed that some certain static files have cookies attached to them which are adding unnecessary loading times.
I was wondering if it was possible to prevent requests to the folder from attaching cookies to the headers.
my site structure looks like this;
application
system
assets
assets/js
assets/css
assets/img
profiles
I dont want requests to the assets and profiles folder to have cookies in their headers
If you're setting cookies at the root, you'll need a separate hostname to do this.
I wouldn't serve the CSS from a separate hostname though...
After HTML, CSS is the next most important resource on a webpage as browser can't start rendering the page until it has the CSS.
If you serve the CSS from a separate domain then there's the overhear of resolving that domain and in some browsers the overhead of TCP connection set up (Chrome, IE9 and possibly other browsers speculatively open a second TCP connection to the host the HTML came from before they know they need it)
The CSS will still have the cookie set on it but if you set a long cache time for it, the CSS should only be requested once per session.
I'm designing a web application to support use of a CDN in the future.
Two options I've considered:
Use domain aliasing for static content on the site, including CSS, JS, and some images.
Use "edge side includes" to designate static content regions.
(1) is simpler and I've implemented it before. For example, we would prefix each IMG src with http://images1.mysite.com/, and then later update the corresponding DNS to use the CDN. The drawback I've heard from users of our internal "pre-production" site is that they would have to push the images to images1.mysite.com to preview their changes internally -- ideally, files would not get pushed to images1.mysite.com until they're ready for production. (NOTE - hosts file changes and DNS tricks are not an option here.)
Instead, they would like to simply use relative or absolute paths for static content. e.g. /images/myimage.gif
(2) is not as familiar to me and I would like more info. Would this allow our "pre-production" team to reference static content with a relative path in "pre-production environment" and yet have it work with the CDN in production without HTML modifications?
Could someone compare the two options, in terms of ease of development, flexibility, and cost?
Here's a variation on the second option to consider.
Leave relative image URLs alone in your HTML. On your production server, have image requests return a server-side redirect to the image location on the CDN. This generates marginally more traffic than the other techniques, but it generates an access log entry for each image hit, keeps your HTML and site structure simple, factors specific CDN dependencies out of your site source, and lets you enable, disable or switch CDN-based image service on the fly.
If you are using a demand-pulled CDN such as Coral, you also need to ensure that requests either issued by or declined by the CDN are served directly from your production server. See Using CoralCDN as a server operator for more information on this technique.