This seems like a really simple question that I would be able to find the answer to super easily, but apparently not.
On a web page, let's say I'm loading an image. Would it take longer for the page to load if I write the link as <img src="http://www.example.com/img/image.jpg"> than if I put it as <img src="/image.jpg">?
The image would be on the same site as the page. The reason I'm asking is because I have a bunch of files that use the external method, and and wondering if it's worth it to change them.
You are confusing absolute URLs and external URLs.
Using an absolute URL will cause the HTML document to take longer to load (simply because you have added more characters to its source code). It will not, however, be significantly longer.
The image will not take longer to load. The browser would have to resolve a relative URL into an absolute URL before using it anyway.
Related
The question is very simple and even tho I might get downvoted into oblivion for it, I can't find a good search query for this.
If I link images, stylesheets, scripts and other things with the full website url (http://url.tld/css/style.css) instead of path (css/style.css) , are the visitors affected negatively? Is there any difference?
The html page is on the same link as the resource, so we're not talking about external resources.
This only makes a difference if you change your domain name. You cannot simply transfer the scripts over but have to change each line or the include of those files then.
One small thing to keep in mind: Your string will be longer and so your file will be a very bit bigger in size but it doesn't really matter.
Either won't affect visitors. Specifying the protocol might cause problems in the future if your users can switch between http and https. Specifying the folder also means changes when you move the site. So best to use relative
Is there any reason to prefer
<a href="alpha/beta.html">
over
<a href="http://mysite.com/dir/alpha/beta.html">
(assuming that the links refer to the same location)? And similarly for references to scripts and style sheets.
I worry that the former might be slightly slower because the browser might reuse a connection in the former case but open a new connection in the latter.
Or are browsers smart enough to handle this in the optimal way?
Yes, there is a major reason : portability. When something changes, you feel better if it is not hard-written in one thousand places.
Additionnally, the relative form — the first one — is much shorter. So, when you have dozens of internal links in your page, using the relative links saves many bytes. Here is for the performance. This gives shorter transfer times, so it saves energy and it is good for the planet Earth.
Regarding the reuse of connections, the relative or absolute form of the links do not matter. Web browsers don't work that way. Anyway, Web browsers are very good at using relative links and directing them to the good server.
Relative links are definitely the way to go.
HTTP is a state less protocol, therefore everytime a user clicks on a link which links to a new HTML page a HTTP request is sent to the server, so using the full URL is not slower or faster than a relative URL.
No, there isn't any difference in performance in terms of requesting the page to load because they will both resolve to the exact same address, though the page size will be slightly larger with absolute paths by virtue of the src attributes being longer but that is obviously, not worth mentioning unless you have a page with thousands of links on of course.
Relative paths (your first example) are in most cases preferred over absolute as if the domain needs to change, you wont have to go through your entire site updating the image/file paths.
I am trying to display some photos on a page, and it is breaking the styling of the page. Here is an example. See on the right side of the page, the images are broken, and they actually get displayed over other HTML elements like an H2 tag which says "coming soon"
Example here:
http://www.comehike.com/outdoors/parks/park.php?park_id=15
Any idea how to fix this? The problem is worse on Google Chrome
The html markup is a bit confusing, for one they all use http://wwww reference but they are hosted on the same server. Maybe I missed something but you can probably use a local site path relative to the web page, something that would be simplified sort of like the following non working code example:
<span style="margin: 3px;">
<a href="hikes/hike_image.php hike_photo_id=&photo_path=img/hiking_photos/108_2/full_cannon2.jpg">
<img src="img/hiking_photos/108_2/small_cannon2.jpg"
style="border: none;"></a>
</span>
This would make for a faster load time, save bandwith, and just be plain more efficient in my very humble opinion. Usually one uses http:// in image links when they are on a remote site.
There are multiple broken images when I load the page, it seems maybe it is the script that generates the markup that is breaking the layout.
To fix this, I would rip out the whole image-generation thing and simplify the mark-up just to have it work 'statically', ie without scripts to output images and/or markup.
Then, once it works in a static manner I would attack dynamic output, though I rarely use such techniques because I feel most of the time they are overkill for the small projects I maintain.
Happy coding & good day friend.
Update:
Storing the image path in a variable for easy site-wide changes:
One (simple) option is to use good old php for your image paths. IE, in main script:
define('BASE_PATH',realpath('.'));
define('IMG_PATH', BASE_PATH . "/img/);
// to inlude an image::
<img src="<php echo IMG_PATH; ?> pic.jpg" />
This way, changing IMG_PATH would change all the img tags that use the variable, and by using BASE_PATH this would work even if you move or copy the site on a different host.
Look up basename() function the man and related functions for more tips and examples like this.
I want that my html page loads faster as it can. So I'm trying to put all CSS styles into the same .css file and all JavaScript code to the one .js file. How my colleagues told me it makes web page load faster. I want to ask some questions about it.
Just to be sure: Are my colleagues right? On which situations it's better to break CSS or JS code to the separate files?
Question is: If I have a lot of small icons on my page, like "delete, edit, add", should I load image with all icons at once or each icon separately? If I'll load all icons at once, how do I select desired one, if icon's size is 40x40px?
Thank you!
Are my colleagues right?
Single files can be downloaded with single HTTP requests (with single sets of HTTP headers, etc, etc) and can be compressed more efficiently then multiple files. So from a performance perspective, if you need all the content, it is better to place them in a single file.
On which situations it's better to break CSS or JS code to the separate files?
When you need a specific page to load very quickly (e.g. the homepage) or when there are sections of the site which use a large chunk of script that isn't used elsewhere then it can be beneficial to break the files up then.
If I have a lot of small icons on my page, like "delete, edit, add", should I load image with all icons at once or each icon separately?
From a performance standpoint, the same rules apply. However, there is no way to specify that a content image (and icons that don't decorate text are content images) is just part of a larger file. You have to use hacks involving background images. This breaks the separation of concerns around content and style and usually involves using semantically incorrect elements, and then requires further hackery to provide alternative content for users who can't see the image and that hackery rarely does as good a job as an alt attribute.
If I'll load all icons at once, how do I select desired one, if icon's size is 40x40px?
You have an element with specific dimensions and a background image with background-position set so that only the part of the image you want shows through.
Consolidating your CSS and JS code into a shared file will improve load times on all loads after the first so long as the browser uses the version of the file in its cache rather than downloading it again. There are many factors that can affect this, but under normal circumstances it should work.
Also, make sure your image files are stored in the same resolution as they will be displayed. Displaying a 40 x 40 pixel file at 20 x 20 pixels means that you have download four times the necessary image size. If the same icon file is referenced many places in an HTML document, then that icon file will only be downloaded once, so it will have little effect on page loading times.
For putting all the icons into one file and choosing which one, see this:
http://cssglobe.com/post/3028/creating-easy-and-useful-css-sprites
You can use what they call CSS sprite.
The thing is very simple to think of but can be a little tricky to use. Here is the idea.
You merge all your images into on big image, making it a single load.
Wherever these images were used on the site, you replace it by a css class which use the big image as a background and a certain positioning.
Let's say you merge 4 image together : delete.png, add.png, edit.png, share.png.
You create a css class for everyone of these like so :
.delete{ background-image:url('../img/icons.png');
background-position:0px 0px;
}
.add {background-image:url('../img/icons.png');
background-position:0px 40px;
}
.share {background-image:url('../img/icons.png');
background-position:40px 0px;
}
.edit { background-image:url('../img/icons.png');
background-position:40px 40px;
}
This way, you reduce the number of request since you you use a single image to show everywhere.
The code was written on the fly, tell if something is wrong.
Also have a look at performance guru tools : Page Speed
Breaking CSS files is not really a problem, considering browser caching.
Breaking up JS files is okay. You can have one JS that handles things needed for the page to load in the <head> tag. And one js that gives interaction to you, after </body>. By doing this you won't have various effects, but you ensure your users sees your text content.
Regarding your images, there's a practice called CSS Sprites. You can use that to make one big file for your small images and use CSS background-position to show only the part you want. It's like cropping your image file based on the css class.
If speed is most important, then what you've been told is correct.
Less CSS and JS files means less HTTP requests to the server. I would only separate files if you have a specific need as part of a project (eg they need to be maintained in ver separate ways)
For JS I always load JQuery and other libraries from the Google CDN - this has a greater performance boost that merging the library into your code as users are likely to have a cached version of Googles code.
For icons I would use CSS sprites (again this means fewer requests to the server) or if you really want to go as far as possible - look into embeding Data URI in your CSS.
Further reading
Googles Page Speed tool
Data URI in CSS
If you want a better performance report about your page, you can take a look at these tools
YSlow: http://developer.yahoo.com/yslow/
PageSpeed: http://code.google.com/intl/es-ES/speed/page-speed/docs/overview.html
Both can be added into the FireBug plugin (Mozilla Firefox).
From YSlow documentation:
Minify JavaScript and CSS
tag: javascript, css
Minification is the practice of removing unnecessary characters from code to reduce its >size thereby improving load times. When code is minified all comments are removed, as >well as unneeded white space characters (space, newline, and tab). In the case of >JavaScript, this improves response time performance because the size of the downloaded >file is reduced. Two popular tools for minifying JavaScript code are JSMin and YUI >Compressor. The YUI compressor can also minify CSS.
Obfuscation is an alternative optimization that can be applied to source code. It's more >complex than minification and thus more likely to generate bugs as a result of the >obfuscation step itself. In a survey of ten top U.S. web sites, minification achieved a >21% size reduction versus 25% for obfuscation. Although obfuscation has a higher size >reduction, minifying JavaScript is less risky.
In addition to minifying external scripts and styles, inlined and blocks >can and should also be minified. Even if you gzip your scripts and styles, minifying them >will still reduce the size by 5% or more. As the use and size of JavaScript and CSS >increases, so will the savings gained by minifying your code.
Preload Components
tag: content
Preload may look like the opposite of post-load, but it actually has a different goal. By >preloading components you can take advantage of the time the browser is idle and request >components (like images, styles and scripts) you'll need in the future. This way when the >user visits the next page, you could have most of the components already in the cache and >your page will load much faster for the user.
There are actually several types of preloading:
•Unconditional preload - as soon as onload fires, you go ahead and fetch some extra >components. Check google.com for an example of how a sprite image is requested onload. >This sprite image is not needed on the google.com homepage, but it is needed on the >consecutive search result page.
•Conditional preload - based on a user action you make an educated guess where the user >is headed next and preload accordingly. On search.yahoo.com you can see how some extra >components are requested after you start typing in the input box.
•Anticipated preload - preload in advance before launching a redesign. It often happens >after a redesign that you hear: "The new site is cool, but it's slower than before". Part >of the problem could be that the users were visiting your old site with a full cache, but >the new one is always an empty cache experience. You can mitigate this side effect by >preloading some components before you even launched the redesign. Your old site can use >the time the browser is idle and request images and scripts that will be used by the new >site
If you are using JQuery, then you can take a look at this: Preloading images with jQuery
Interesting concepts to improve download speed, perceived speed and actual speed:
7 techniques for faster JavaScript loading without compromising performance…
Make better use of caching
Download external scripts after visible content is loaded &
download multiple JavaScript in batch (asp.net/ajax)
Most principles explained are still generally applicable.
I'm trying to do some HTML layouts, and pretty much my problem comes in here:
<img src = "https://something.com/image.png">
The image can be displayed in a browser when navigating to the URL, but not in Microsoft Visual Studio (or the browser when loading this HTML page), it displays as a broken image instead. This leads me to believe it cannot be linked to in such a way (as I can view other images this way). I'm wondering if it has anything to do with it requiring a secure http connection and if there's any way around this.
Basically, the picture comes up when the url is navigated to. However, when opening this HTML file that has the image displayed on it, it comes up as a broken image. I'm wondering why this is.
Thanks.
You 'll need to establish a secure connection to do that. When the browser comes across the url you have placed as src of the image it sends out a request to that server, which responds by offering different encryption methods it supports. But since you 'll be browsing the page as http data you won't be able to understand the response (which is supposed to be image data if the other side is http and now happens to be a query for encryption method). In short you are missing an SSL layer to make your communication sensible and therefore you see a broken image.
Try making it a background image in your css.
edit I am getting down voted for this question. I should have prefaced that I am not sure and was taking a wild guess, if anything to offer an idea that was not presented by the asker to help solve the problem :)