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
Related
I have a JPG in the header section of a responsive HTML page. I want to use the same site content for multiple domains that will point to my single set of files at my hosted URL. Example : mysite.com will host all files. But a second site - example theirsite.com will point in a forward to my hosted files location.
All the content will be the same, EXCEPT FOR the one image file (logo.png) or can be any name, but I would like to see if I can image-substitute 1 file (logo.png) to render so that, when visitors come to mysite.com, they see my file. When visitors come to theirsite.com they will see the logo file for theirsite.com instead of for mysite.com Sorry if I have not explained this professionally.
There are two real ways to do this. The best way is to handle it server-side.
You would need some sort of dynamic site generation, such as PHP. As the site isn't changing on each request, I'd recommend doing this generation ahead of time. Then you can utilize static hosting on CDNs and such. The specifics of how you do this depend on your technology choice. And, it matters little what you pick.
Doing the switch server-side is better, as crawlers will be able to see the right version of the site. Most crawlers don't run client-side code.
The second option is to handle it client-side. In this case, I'd recommend including a site definition file for each domain and writing some JavaScript to check the hostname the site was loaded on, and load the right site definition file. That file could contain elements and attributes to replace. Again, this is less desirable of an option, but still possible.
I've been playing around with Filament's Critical CSS (https://github.com/filamentgroup/grunt-criticalcss) and have a question about it's usage.
As I've been using the tool, it generates a "critical" sheet for every page I point it at so that I can inline those files into my HTML via a <style> tag in the <head>. This all makes sense.
However, once the user visits any of my sites pages, they'll have the main sheet fully cached. At this point does it make sense to stop inlining the CSS, as the user already has the CSS loaded, and instead link to it via a traditional tag?
If you're certain that the user has the stylesheet cached this would be a valid approach, assuming that parsing a cached stylesheet or inline styling of critical css will take the same amount of time.
You however can't be certain that it exists in the users cache. As the critical css also exists in the stylesheet this isn't a problem, but it will make rendering the page slower.
The only way to know when it might be useful is to parse your access logs, try to find how often the stylesheet is also requested when a specific page is requested by a specific user. Using that you can create a probabilistic model on when it's useful to inline critical css. This seems like too much work for a small gain. I'm guessing that using inline critical css is most useful for landing pages or pages that go viral.
Yes, Inline CSS usually now is only needed when you want it to take complete precedence over an external style-sheet you do not control of a .JS file that makes unwanted changes which overwrites your style-sheet as well. Doing this also helps with performance, band-width, etc., etc.
I am going to answer here as it is best to do so instead of in comments.
The problem that you're having is strange in the matter that you are wanting to cover all possible bases with two separate, but tied issues.
Firstly, your performance gains. Since you want to have higher performance doing inline styles is the technically correct answer. There are some minor gains because you are not doing a request. All requests that go out take time and depending on the time it takes for the server to communicate each request you will see a possible performance drop. This is why some requests that are much larger are considered excessive and Google generally informs you to sprite the image or some other form of connection.
The other part is you want ease of accessibility and want to be able to update quickly which is what would be provided by an actual CSS file. You would need to at some point call this CSS file so that it can be cached into the browser as you expect. You can do some cookie checks and depending if the user has been to the site or not they will have a specific call, but here is the major issue:
At some point you HAVE to actually load it. You will have to make the call. Whether it be on the first load or the last at some point for it to be cached it actually has to be retrieved. You will spend a ton of time checking each variable if they don't have it they will need to have the style sheet loaded. If you are already required to load it at some point then it comes down to never really needing to do inline styles. And if you have inline styles you never really need to load it.
You could potentially do a PHP include of the file and have it pull in that way. You would just include the file between a style declaration and it would populate the CSS that way. I wouldn't say that is the best way to do it, but it is possible. It can be done. I still stand by saying inline is not the right way to go. Technically yes it can help. Reality... no. I have not seen it be beneficial ever in my time. If someone wants to show me one that is fine, but I doubt I will use this practice unless it is last resort.
Keep in mind this final thought. Most cases inline styles are styles that are meant to be final styles; ones that end overwrite original external style sheets that we as developers can not edit ourselves (or do not want to change for other reasons).
Google is great and they provide great research, but research is meant to be considered and not always used exactly as they write. It is to provide insight. Not usually a guide into the way.
We are in the process of redesigning our company's web site, and we have been told by consultants that it is important that we either:
1.) Always link to a specific page i.e. foo.com/buy/default.aspx
or -
2.) Always link to a directory and allow the default document to load i.e. foo.com/buy/ where "default.aspx" is the default document
Is there any practical benefit to either approach? Does being 100% consistent in doing one or the other really gain us anything?
In your first example, always linking to a specific page helps prevent ambiguity in your URLs. Prefer a canonical URL (can be with or without a file extension). If you have to have multiple URLs for a single resource, for example /products/product1.aspx and products?productID=product1, then take advantage of the Canonical URL property in your code to specify which is the proper one.
Using extensionless URLs allows you to change technologies later. For example, /blog/post1.aspx is different than /blog/post1.php, say if you ever switched to WordPress (not common, of course, but it happens). It's just an easy way to make the links work no matter the technology. Plus, in my opinion it's always better to, as much as possible, mask the technology stack that you're using where possible. Extensionless URLs are becoming the norm (in my opinion) as people seem to be moving more toward an API-based approach to URIs as resources, and mixed technology stacks.
The second method you mentioned is good because it helps you make clean URLs
(don't click these urls they are just examples)
okay URL
http://www.example.com/example/example.php
clean URL
http://www.example.com/example/ (so much easier to remember, and shorter to write out)
here is a good tutorial I found that shows you how to accomplish this: http://www.desiquintans.com/cleanurls (htaccess)
I've just added a subdomain to my website, but can I point it to files in the main website with relative links? Like in the way that ../ goes back a folder, can you tell it to remove the first part of the url?
Also, I've just seen perhaps it's better putting the image folder as a subdomain too, is it worth doing this?
It's not possible to link to another domain using relative links, even if it is a subdomain. If you really want to do this you could make some kind of scripting helper to do that, but it would need to run on every page. With this you could run into problems on clients that have scripting disabled.
Putting images in a different subdomain is usually done to optimise loading speed. Browsers usually have a limited number of simultaneous requests to a single (sub)domain. By putting images on a separate (sub)domain you allow the browser to make more simultaneous requests and (in theory) allow your site to be loaded faster.
You can't use relative links, but you can use mod_rewrite to help you make a 'pseudo relative' link.
If your desired relative link were: href='folder/filename.typ'
then make it: href='root/folder/filename.typ'
in .htaccess enter: Rewriterule ^root/(.+)$ http://yourdomain.com/$1
You don't have to use 'root' of course, any word will do so long as it's unique in this context (i.e. not an actual folder name).
CAUTION: I found this thread looking for a solution myself. I've only just worked out this method. It does work on my site but I've not tested exhaustively yet.
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.