I checked the source of a few WAP sites,
but doesn't find anything different from a normal HTML page.
Can you name a few detailed points?
Well, WAP/WML is very strict when it comes to markup because the page needs to be compiled before delivery to the client device.
As for specifics,
WAP "pages" can have more than one "card". (Confusing? I know...)
Although not markup related, accepted image formats are more limited
Do not forget a DOCTYPE!
Content must be served with the text/vnd.wap.wml MIME type
WAP 1 has almost nothing in common with the HTML/CSS/JS/server-side-scripting stack. The only connection it has with the larger web is that telco gateways use HTTP to request WML content from a normal web server. WML is an old-fashioned and ugly ‘card’-based hypertext system which everyone hated, largely failed in the market and is long gone (thank goodness).
The misleadingly-named “WAP 2”, on the other hand is just XHTML Mobile Profile (a somewhat limited subset of HTML); everything else about it is the same as the normal web stack. This makes it much easier to work with: it's possible to generate content for desktop and phones from the same templates. You may also see ‘i-XHTML’, which is a similar HTML-subset used by Docomo phones.
Either way, modern smartphones are happy rendering normal desktop-style [X]HTML, so you're not going to have to worry about any of this in the future. (Sure, there are compatibility issues, but that's nothing new, right?)
Here is a table with some information about the differences : http://csc.colstate.edu/summers/Research/Wireless/WAPvsWeb.html
Another difference being WAP is almost if not totally dead, and HTML is kicking ##S :-)
Related
Suppose I have a website and it has the option to choose a language, then all the content (text) changes, where is it better in terms of performance to store this content?
I would build a translation file on the client side, is that right? (Also for sites where the content is huge)
Storing on the client-side all huge content translation list would be fine as long as you get this context from API and only 2 languages allowed. The client browser can handle that.
Hoverwer if you were having more than 3 languages translated texts, I would advise you to get these translated contents for each language from API.
From personal experience, We recently developed an app with 2 language options, and all the texts are on the client-side, but we face some issues on pages where we have texts more than 25 pages long. For us, it's just one page where users hardly visit. So we don't care, but if this issue were mostly for all pages, I would be using the server-side.
So I'm grappling with brutal ranking degradation due to external services used in client sites. I've pretty much done everything I feel I have control over, including resolving render-blocking problems.
But one thing that runs like a red thread through all sites is that YSlow and PageSpeed get stuck at rankings in the D range at best because of browser caching and redirect advisories for external resources, including googles own analytics.js.
Now I know that some of these resources might be able to be moved locally, but often, especially in the case of redirect-chains - it seems like a daunting task.
Here's an example for an insane redirect chain:
https://d.adroll.com/cm/b/out
https://x.bidswitch.net/sync?dsp_id=44&user_id=NWY2MDZmY2M1NGUxZGVhZTE1NmZmNjgzYjI2ZjlmMGM
https://x.bidswitch.net/ul_cb/sync?dsp_id=44&user_id=NWY2MDZmY2M1NGUxZGVhZTE1NmZmNjgzYjI2ZjlmMGM
https://t.brand-server.com/match_back?bidder_id=4&external_user_id=da20ac56-bf05-4acc-8df2-2e92ceb9f4da
https://t.brand-server.com/ul_cb/match_back?bidder_id=4&external_user_id=da20ac56-bf05-4acc-8df2-2e92ceb9f4da
https://match.adsrvr.org/track/cmf/generic?ttd_pid=centro&ttd_tpi=1
https://match.adsrvr.org/track/cmb/generic?ttd_pid=centro&ttd_tpi=1
https://t.brand-server.com/match_back?bidder_id=1&external_user_id=09d385a1-bd5e-4dc0-84fb-1afdf83f1892
https://secure.adnxs.com/getuid?https://t.brand-server.com/match_back?bidder_id=3&external_user_id=$UID
https://t.brand-server.com/match_back?bidder_id=3&external_user_id=8261031581142479988
https://pixel-a.sitescout.com/dmp/pixelSync?nid=35
https://bcp.crwdcntrl.net/map/c=1389/tp=STSC/tpid=8157edd8-d80d-432e-bf0b-47234df4942c?https%3A%2F%2Fsu.addthis.com%2Fred%2Fusync%3Fpid%3D11185%26puid%3D8157edd8-d80d-432e-bf0b-47234df4942c%26url%3Dhttps%253A%252F%252Ft.brand-server.com%252Fmatch_back%253Fbidder_id%253D5%2526external_user_id%253D8157edd8-d80d-432e-bf0b-47234df4942c
https://bcp.crwdcntrl.net/map/ct=y/c=1389/tp=STSC/tpid=8157edd8-d80d-432e-bf0b-47234df4942c?https%3A%2F%2Fsu.addthis.com%2Fred%2Fusync%3Fpid%3D11185%26puid%3D8157edd8-d80d-432e-bf0b-47234df4942c%26url%3Dhttps%253A%252F%252Ft.brand-server.com%252Fmatch_back%253Fbidder_id%253D5%2526external_user_id%253D8157edd8-d80d-432e-bf0b-47234df4942c
https://su.addthis.com/red/usync?pid=11185&puid=8157edd8-d80d-432e-bf0b-47234df4942c&url=https%3A%2F%2Ft.brand-server.com%2Fmatch_back%3Fbidder_id%3D5%26external_user_id%3D8157edd8-d80d-432e-bf0b-47234df4942c
https://t.brand-server.com/match_back?bidder_id=5&external_user_id=8157edd8-d80d-432e-bf0b-47234df4942c
Here's some caching/expires headers warnings:
https://fonts.googleapis.com/css?family=Oswald:400,700
http://cdn.searchspring.net/ajax_search/sites/742gv8/js/742gv8.js
http://cdn.searchspring.net/ajax_search/js/searchspring-catalog.min.js
http://cdn.searchspring.net/autocomplete/searchspring-autocomplete.min.js
http://www.googleadservices.com/pagead/conversion.js
https://seal-stlouis.bbb.org/seals/blue-seal-200-42-miniaturemarketllc-310240951.png
https://fonts.googleapis.com/css?family=Open+Sans:600,700,400,300
https://trustlogo.com/trustlogo/javascript/trustlogo.js
https://connect.facebook.net/en_US/fbevents.js
http://www.googletagmanager.com/gtm.js?id=GTM-5RMBM2
http://tag.perfectaudience.com/serve/51dc7c34a84900f9d3000002.js
http://a.adroll.com/j/roundtrip.js
https://www.facebook.com/tr/?id=1860590510836052&ev=PageView&dl=http%3A%2F%2Fwww.miniaturemarket.com%2F&rl=&if=false&ts=1480458368216&v=2.5.0
https://www.facebook.com/tr/?id=1610476729247227&ev=PageView&dl=http%3A%2F%2Fwww.miniaturemarket.com%2F&rl=&if=false&ts=1480458368220&v=2.5.0
https://trustlogo.com/trustlogo/images/popup/seal_bg.gif
https://trustlogo.com/trustlogo/images/popup/warranty_level.gif
https://www.google-analytics.com/analytics.js
https://pixel-geo.prfct.co/tagjs?check_cookie=1&a_id=3045&source=js_tag
https://www.google-analytics.com/plugins/ua/ec.js
https://s.adroll.com/pixel/P3MVZ4FMVNG67LVRKHALEV/CSFUSWFLCFBNTBB2REH2EP/V42TOE4T75HOHDQUCEXVPV.js
http://pixel-geo.prfct.co/seg/?add=842026,3277058&source=js_tag&a_id=3045
https://www.facebook.com/tr?id=1610476729247227&ev=ViewContent&cd[rtb_id]=3277058&noscript=1
https://www.facebook.com/tr?id=1610476729247227&ev=ViewContent&cd[rtb_id]=842026&noscript=1
https://www.facebook.com/tr/?id=1638890983076166&ev=PageView&dl=http%3A%2F%2Fwww.miniaturemarket.com%2F&rl=&if=false&ts=1480458369206&cd[segment_eid]=%5B%22V42TOE4T75HOHDQUCEXVPV%22%5D&v=2.5.0
https://analytics.twitter.com/i/adsct?p_id=48571&p_user_id=pa_HjjM3Ntt5wLVRxjwi
https://image2.pubmatic.com/AdServer/Pug?vcode=bz0yJnR5cGU9MSZjb2RlPTMyNDMmdGw9MTI5NjAw&piggybackCookie=uid:pa_HjjM3Ntt5wLVRxjwi
https://www.facebook.com/fr/u.php?p=292157157590619&m=pa_HjjM3Ntt5wLVRxjwi
https://www.facebook.com/fr/u.php?t=2592000&p=443937282305007&m=NWY2MDZmY2M1NGUxZGVhZTE1NmZmNjgzYjI2ZjlmMGM
https://analytics.twitter.com/i/adsct?p_user_id=NWY2MDZmY2M1NGUxZGVhZTE1NmZmNjgzYjI2ZjlmMGM&p_id=823423
https://pixel-geo.prfct.co/cb?partnerId=goo
https://d.adroll.com/cm/g/in?google_ula=1535926,0
https://pixel.rubiconproject.com/tap.php?cookie_redirect=1&v=194538&nid=3644&put=NWY2MDZmY2M1NGUxZGVhZTE1NmZmNjgzYjI2ZjlmMGM&expires=365
https://us-u.openx.net/w/1.0/sd?cc=1&id=537114372&val=pa_HjjM3Ntt5wLVRxjwi
https://dsum-sec.casalemedia.com/rum?cm_dsp_id=105&external_user_id=NWY2MDZmY2M1NGUxZGVhZTE1NmZmNjgzYjI2ZjlmMGM&expiration=1511994369&C=1
https://us-u.openx.net/w/1.0/sd?cc=1&id=537103138&val=5f606fcc54e1deae156ff683b26f9f0c
https://pixel.rubiconproject.com/tap.php?cookie_redirect=1&v=189868&nid=4106&expires=30&put=pa_HjjM3Ntt5wLVRxjwi
https://idsync.rlcdn.com/377928.gif?partner_uid=5f606fcc54e1deae156ff683b26f9f0c&redirect=1
https://pixel.prfct.co/seg/?add=695885
https://pixel.prfct.co/cb?partnerId=mrin
http://ib.adnxs.com/mapuid?member=364&user=11465672070136222257
https://t.brand-server.com/match_back?bidder_id=5&external_user_id=8157edd8-d80d-432e-bf0b-47234df4942c
It would seem that being able to do something about this would drastically improve the score as it's about the only thing left to fix. So my question is - what can be done about it?
Has anyone tried solutions like rewriting the urls after source generate through a proxy that covers the redirect chain or fetches the resources and passes them through with modified headers?
Is it at all worth it or are these page scores just to be ignored?
What are plausible alterntives?
Apologies for a loaded question...
I've tried dealing with the same issue in the past, and although I couldn't find a good solution for the redirect chains and caching issue, there are few guidelines I follow:
Think carefully on every external resource - do you really need it? Do you really have to load it before any user interactions? If so - can it be fetched from your server instead? In your example, I would copy the Google fonts to my server.
Never #import stuff in CSS. It's slow by definition as it requires at least two sequential HTTP requests. Try importing as many resources as possible in the or just before , or precompile using LESS or SCSS.
Ignore widely used resources such as Google Analytics. It's improbable that Google will lower your site's ranking just because you use them. In any case, always look for the "async" implementation of the services you are using.
Hope this helps.
So a lot of ssl/trust/site scanner providers like comodo, geotrust, symantec, thawte and more always give their clients some code that they usually place in the footer of their websites. This code usually is an image with alt text and sometimes a bit of text that says "Secured by so and so, or powered by so and so".
I have noticed they never have the nofollow tag.
I am about to launch a service which will also allow clients to place a seal on their website. They will most likely be placed in the footer on every page.
I have read that it is best to place a nofollow on footer sitewide links. But most recently i am reading that it is okay to not have the nofollow as long as you only use your brandname and no keywords.
So i am having to decide on what to do. Do i give my clients the code for the image/link with a nofollow or a dofollow?
I can't get a confirmed answered anywhere on which i should do. I would prefer a dofollow, but only if i will not get penalised by google.
Can anyone make any recommendations or information on a good/firm answer?
No Follow, You stated no reason not to, and every reason to do, Google is a 50-50 kind thing, depends whos behind what desk. Stick the safe road.
I'm developing a RESTful API. Currently I'm considering the use of resource-specific vendor MIME-types to convey semantics and meaning as well as well as serve as the "contract" between client and server.
So for example application/vnd.mycompany.person+xml would mean that the data in question is xml that represents a person.
I have a requirement to make this API "private-labeled" meaning a reseller could in turn provide the API to his customer without his customer knowing that it is my company's service. The way this would work is that my company would host the main api at a sort of generic url, i.e www.example.com/api then my company would use a CNAME to point our domain name to that url, and our resellers could do the same.
Internally all resource links would be relative from the API root, and so would respect the actual url that is being used.
HOWEVER, I don't want to have to understand/support arbitrary vendor specific MIME-types, so what should the "mycompany" part of the example MIME-type above be?
The HTTP spec says:
Use of non-registered media types is discouraged.
I used to use “custom” media types in my platform, but it caused issues with user agents (browsers, cURL, wget, etc.) not recognizing the content.
You could try to get your custom media type registered, but (A) that takes a while; (B) it’d take a real long while before user-agents would recognize the type, if ever; (C) you’ve indicated that you don’t want the company name always present anyway.
As an alternative to “custom” media types, I recommend utilizing media type parameters instead; they’re a blessed way to add supplementary information about content to media types.
Using parameters, your media type could be application/xml; mycompany-schema=person or maybe just application/xml; schema=person.
I have seen a couple of frameworks and tutorials that recommend vendor specific mime-type to "solve" issues with making your REST interface "truly RESTful" simply because it can be done and somehow that makes it kosher for a REST service.
One issue with this approach is that by its nature is a hack or cheat to "make it work" the way you want when the whole point of shifting to a hypermedia-driven REST service is to change the model of your API and service and change how you approach the problem. Sneaking a "valid" or allowed but not recommended HTTP value for the Content-Type is like telling the starving Venezuelans that rats are fish so they could eat them without sin during Lent. Is there anything wrong with eating a rat if that's all you have? Probably not. But does pretending its a fish make it a fish? Of course not. If you need an interface that's contract driven, use RPC or SOAP or even a custom vendor mime-type. But don't point to the spec and say it's Rest, because in the end your eating a rat and everyone knows it and you're only lying to yourself.
The second issue is that you are losing the actual rewards of the hypermedia-driven interface when you cut corners. Right away you have run into issues with user agents and your own server having to jump through hoops or simply give up because the mime-type was unfamiliar. All because you thought you could have it both ways when the point isn't to impress your clients with claims of a true Rest service or to lighten the load a bit by shedding the (obviously valuable for some contexts) extra weight of a contract-driven interaction, it was to change how your service actually interacted with external clients.
Finally, I'm really unclear on how a vendor specific mime-type actually enforces a contract any better than a defined endpoint? All of the sites that mention this technique seem to just be glowing with relief that this option exists and, quite frankly, a bit smug and pleased that they are using it, like they know it's technically "naughty" but it's just so easy and fixes everything. What does it fix? In your case, why wouldn't you simply have your inbound person request/content go to:
POST /myRestService/people
and if they have some other request, have that go to a different endpoint intended for that other data type? If you need a method does_something, wouldn't you either go with:
GET /myRestService/people/personID_123/does_something
or
GET /myRestService/people/does_something/personID_123
depending on the exact context?
And just so I don't sound mean on top of loony, any frustration or anger is not at all directed at you or your question, but at the "solution" of the vendor mime-type and the obsession everyone has developed for the "Roy Fielding officially-approved and stamped
as valid REST service" that apparently no one is even able to provide a working public example of, leaving only a sense of urgency to adopt it right away taking whatever shortcuts needed and we can deal with the shame and finger pointing later when we actually fix the problems the shortcuts made.
I have a php web site under apache (at enginehosting.com). I rewrote it in asp.net MVC and installed it at discountasp.net. I am comparing response times with firebug.
Here is the old time profile:
Here is the new one:
Basically, I get longer response times with the new site (not obvious on the pictures I posted here but in average yes with sometimes a big difference like 2s for the old site and 9s for the new one) and images appear more progressively (as opposed to almost instantly with the old site). Moreover, the time profile is completely different. As you can see on the second picture, there is a long time passed in DNS search and this happens for images only (the raw html is even faster on the new site). I thought that once a url has been resolved, then it would be applied for all subsequent requests...
Also note that since I still want to keep my domain pointed on the old location while I'm testing, my new site is under a weird URL like myname.web436.discountasp.net. Could it be the reason? Otherwise, what else?
If this is more a serverfault question, feel free to move it.
Thanks
Unfortunately you're comparing apples and oranges here. The test results shown are of little use because you're trying to compare the performance of an application written using a different technology AND on a different hosting company's shared platform.
We could speculate any number of reasons why there may be a difference:
ASP.NET MVC first hit and lag due to warmup and compilation
The server that you're hosting on at DiscountASP may be under heavy load
The server at EngineHosting may be under utilised
The bandwidth available at DiscountASP may be under contention
You perhaps need to profile and optimise your code
...and so on.
But until you benchmark both applications on the same machine you're not making a proper scientific comparison and are going to be pulling a straws.
Finally, ignore the myname.web436.discountasp.net url, that's just a host name/header DiscountASP and many other hosters add so you can test your site if you're waiting for a domain to be transferred/registered, or for a DNS propagation of the real domain name to complete. You usually can't use the IP addresse of your site because most shared hosters share a single IP address across multiple sites on the same server and use HTTP Host Headers.