A public Plurk profile hands a plain HTTP client 118 words in 32,781 bytes from a Taiwanese residential exit: the display name, the description, the friend, fan and karma counters and the profile chrome, all in the HTML. Rendering the same URL in a browser returns 196 words for 765,843 bytes and 6.8 seconds, 78 more words for 23 times the traffic. A single plurk page is server-rendered at 17,858 bytes and 119 words. The API returns 68 bytes and an error to any request without an OAuth signature, public profiles included. On Plurk the setting is plain HTTP for profiles and posts, a Taiwanese exit, and an app key for timelines.
Plurk is a Taiwanese microblog that has run since 2008, and nobody in the proxy trade writes about it: the Taiwanese search results for this keyword are the platform's own pages, a thesis on user behaviour and a mirror of the API documentation. That is exactly why it is worth measuring. Here is what a proxied client gets, from the home market and from two others.
The profile header is server-rendered; the timeline is not
We audited www.plurk.com/plurk, the platform's system account, through residential exits in three countries, once without JavaScript and once rendered.
| Exit country | Plain HTTP | Rendered in a browser |
|---|---|---|
| Taiwan | 118 words, title Plurk [plurk] - Plurk, description, robots: INDEX,FOLLOW | 196 words, 765,843 bytes, 6.8 s |
| Japan | 103 words, same title and description | 137 words |
| United States | 118 words, same as Taiwan | 196 words, same as Taiwan |
Over plain HTTP the page contains the profile: nickname, display name, the description, the counters (friends, fans, karma, plurks, responses), the avatar and two headings, plus one HTML table, all inside 32,781 bytes. What it does not contain is the timeline. The plurks themselves are loaded by script after the page, which is why the rendered pass adds 78 words: a handful of recent posts and their response counts.
That makes the render a poor trade on this target. The browser moves 765,843 bytes and takes 6.8 seconds to add 78 words; the plain fetch moves 32,781 bytes in 1.6 seconds and already answers "who is this account and how big is it". For the timeline itself there are two better routes, below, and neither is a browser.
A single plurk page is full HTML at 17,858 bytes
Every plurk has a permalink under /p/. We fetched one over plain HTTP from Taiwan: HTTP 200, 17,858 bytes, 119 extractable words, with the plurk's text in the title tag, the author's nickname, and the response count in the meta description (Plurk by <user> - 1 response(s)). The post text, the author and the count are in the HTML before any script runs.
So the honest instruction for monitoring known posts is: read the permalink over plain HTTP, 17,858 bytes each, and parse the title and description. For discovering posts you need either the rendered profile, which gave us a handful, or the API, which is where the platform wants you.
The API refuses unsigned requests, even for public data
Plurk API 2.0 is built on OAuth 1.0a. The documentation lists /APP/Profile/getPublicProfile as the method that "fetches public information such as a user's public plurks and basic information" and says it supports two-legged OAuth, meaning a request signed with an application's consumer key and secret, with no user token. We called it without a signature from a Taiwanese exit and received HTTP 400 in 68 bytes: 40003: we only support HMAC-SHA1 as signature method.
Read that as the rule it is: public timelines are available programmatically, but only to a registered application signing its requests. An app key is issued at /PlurkApp/create to a Plurk account. Proxies do not change this. What proxies change is the pacing of page reads, which carry no key, and the exit country, which changes the page.
The Japanese exit gets a different interface, and 15 fewer words
The Japanese rows above are the geographic finding. Same URL, same minute: 103 words plain and 137 rendered from Japan, against 118 and 196 from Taiwan and the United States. The title and description did not change. What changed is the interface language around the profile, which Plurk selects from the client's location, and the way word counting treats it: a Japanese label is one token where an English one is two or three.
The practical consequence is the one we documented on Facebook and on TikTok: a parser keyed on English labels breaks silently from a Japanese exit, and a word-count assertion tuned on Taiwan fails on Japan for the same content. Pin the exit for the duration of a job. Taiwan is the platform's home market and its counts matched the United States exactly, so it is the exit to pin.
What it costs, counting a gigabyte as one billion bytes
| How you fetch it | On-wire bytes | What you get | Per GB | Cost at $0.80/GB |
|---|---|---|---|---|
| Profile, plain HTTP, Taiwanese exit | 32,781 | 118 words: name, description, counters | ~30,500 profiles | $0.000026 |
| Profile, rendered, Taiwanese exit | 765,843 | 196 words: the same plus a few recent plurks, 6.8 s | ~1,306 profiles | $0.00061 |
| One plurk permalink, plain HTTP | 17,858 | Post text, author, response count | ~56,000 posts | $0.000014 |
| API getPublicProfile, unsigned | 68 | An error until you sign with an app key | n/a | n/a |
Refresh 50,000 profiles a day for a month over plain HTTP: about 49 GB, about $39 at the residential Basic rate. Rendered, the same job moves about 1,149 GB and costs about $919 for 78 extra words per profile. Reading 100,000 plurk permalinks costs about $1.43. The cheapest route on Plurk is also the most stable one, because the server-rendered HTML is what the platform has served to search engines since 2008.
If you would rather not run the fetch layer, our web scraping API returns the profile or the permalink as Markdown for $0.0002 per page with no browser, pinned to Taiwan. On Plurk do not pay for the $0.001 rendered mode; the measurement above is the proof.
What Plurk's own files permit, in one line each
The robots.txt is 304 bytes and starts with Allow: /, then disallows eleven paths for every user agent: friend invitations, notifications, settings, cliques, affiliate and admin pages, two redeem paths, /Users/, /API/ and /IM/. Profiles, plurk permalinks, the portal and search are not excluded, and the file is cached for 31 days. No AI crawler is named.
The Terms of Service, section 4, say the rest in three lines: do not access the services by any means other than the interfaces publicly provided and authorized by Plurk, adhere to robots.txt, and do not disrupt the service by overloading, flooding, spamming or crafting scripts. That is the plain line: reading public profile and plurk pages at a human pace, within robots.txt, is what the published interface provides; a timeline at volume is what the signed API provides; anything that floods the site is out. Accounts are personal, and nothing here helps with running several.
What this is properly for: monitoring a known list of public accounts and posts, checking how your own profile renders from Taiwan and from Japan, social listening on public plurks through the API with an app key, and research under the Taiwanese Personal Data Protection Act, which the terms cite and which applies to public posts as much as to private ones.
The setting that works on Plurk
- Network: residential, Basic at $0.80/GB. Residential exits in Taiwan, Japan and the United States read the profile over plain HTTP on the first request; nothing in nine passes needed more than a household address.
- Fetch mode: engine: tls, plain HTTP. 118 words and the counters in 32,781 bytes; the render adds 78 words for 765,843 bytes and 6.8 seconds. Permalinks under /p/ are full HTML at 17,858 bytes.
- Country to pin: Taiwan, the home market. From Japan the same page returns 103 words plain and 137 rendered instead of 118 and 196, because the interface follows the exit.
- For timelines: the API 2.0 with an app key, two-legged OAuth 1.0a signed with HMAC-SHA1; unsigned requests get a 68-byte error.
- When the proxy is not enough: the web scraping API at $0.0002 per page returns profiles and permalinks as Markdown, pinned to Taiwan; for cross-platform listening alongside Plurk, the Reddit collector returns public posts as rows with no fetch layer on your side.
- Free tier: every account gets $2 of free API usage per month, which covers 10,000 profile or permalink pages at the plain-HTTP rate.