CSS可以帮助我们让表格出现滚动条,特别是当表格非常长并且所有列不适合在一页上显示。下面是一些CSS代码可以让表格出现滚动条。

/* 添加以下样式,即可让表格出现水平和垂直滚动条 */
table {
overflow: auto;
display: block;
/* 为表格添加一些间距和边框 */
padding: 20px;
border: 1px solid #ddd;
}
/* 添加以下样式,即可让表格的表头固定在顶部 */
thead {
position: sticky;
top: 0;
background-color: #fff;
}
/* 添加以下样式,即可让表格的行固定在左侧 */
tbody {
position: sticky;
left: 0;
background-color: #fff;
box-shadow: inset -10px 0 10px -10px rgba(0,0,0,0.5);
}
/* 如果对于表格的垂直滚动条不想出现的话,可以添加以下样式 */
tbody::-webkit-scrollbar {
display: none;
}

来源:前端老白

Posted in CSS.

开启国内外分流

现在虽然实现了科学上网,但无论访问国内外网站,所有上网流量都会通过代理,因此会很浪费节点流量,并且访问国内网站的速度也比原来慢,所以我们要配置一个分流策略,来自行决定流量是否经过代理。

可访问 http://ip111.cn 查看当前分流情况,下图可以看出当前模式下所有流量都经过代理,即默认『全局代理』。

配置 PAC 模式

上面这个『国内外分流』模式有个明显不足之处,那就是国外的网站不管有没有被墙,全部经过代理,这样还是会造成部分不必要的流量浪费,因此还有另外一种受欢迎的分流模式,也就是新版本 v2rayN 砍掉的 PAC 模式,即只有被 GFW 墙掉的网站才走代理,其余网站直连。下面就来配置一个效果近似与 PAC 模式的路由规则。
打开刚才的路由设置界面,在规则集列表右键 - 添加规则集,取一个名字比如 『PAC模式』

[ { "outboundTag": "proxy", "domain": [ "domain:example.com", "domain:example2.com" ] }, { "type": "field", "outboundTag": "block", "domain": [ "geosite:category-ads-all" ] }, { "type": "field", "outboundTag": "proxy", "domain": [ "geosite:gfw", "geosite:greatfire", "geosite:tld-!cn", "geosite:geolocation-!cn" ] }, { "type": "field", "port": "0-65535", "outboundTag": "direct" } ]

再访问 http://ip111.cn 查看,国外没有被墙的网站也实现了直连,只有被墙的网站才走代理,成功达到了原来PAC模式的效果。

L/C:信用证(letter of credit)
MPQ:最小包装量(minimum pack quantity)
MOQ:最小订单量(minimum order quantity)ETD:预计开航时间,也就是预计船期(Estimated Time of Departure )

平台信息断层

我觉得平台的许多工作人员在信息层面上是和很多其它行业从业者断层的。平台,也俗称官方,我在接触的过程中我发现,他们并没有真正意义上学习过自己的平台是做什么的。
举个例子,一个沃尔玛的招商经理会很熟悉平台的开店政策和注册流程,但是由于专注在开店流程,就会没有办法了解自己平台的广告系统,无法了解这个平台到底有哪些相关服务商,有哪些相关的KOL,有哪些新的玩法。
这带来了一个必然的结果,由于招商是对接卖家的第1人,而卖家和招商之间能进行的对话范围会很局限,其它行业从业者和招商的对话内容范围也会很局限,最终就会导致卖家嘴里说出一句:“找招商没用,解决不了”。
这个问题,不仅仅只是招商这个角色会存在,同时也会存在在平台方/官方其他人身上。平台官方在行业内经常都会和卖家所关心的问题产生严重的断层。

运营过度缺乏技术感

我觉得运营这个岗位已经越来越缺乏技术感,就像之前的《新媒体运营》一样。很多运营做到30岁,就会开始面临就职困难的问题。
我不是说没有好的运营,我只是说一个壁垒和稀缺性的问题而已,很多运营都无法构建自己的壁垒,在30岁以前。
我在自己的公众号上写过,我觉得javascript算是一项特别好补充运营的技术,
当然,如果一个运营希望能够从“更了解平台,更懂平台规则,更xxx平台”来构建自己的壁垒的话,在我看来是不安全的,因为只要平台规则变动1次,这运营的壁垒就会在一夜之间倒塌。
另外一个更好的壁垒就是发展产品相关技能,例如产品设计或者采购等工作。这些方面的技能都可以让运营懂得更多,懂得更深。
总而言之,不构建壁垒的运营都会被市场规律所抛弃。

运营过度缺乏技术感
倒不如说是缺乏某一领域的复合性能力。

而复合型运营,首先我觉得它不是“杂合型”运营。
杂合型运营可能类似评论区里说的:运营除了会本职工作,你还得要摄影、美工、.....。我觉得吧,术业有专攻,特别是作为工作者,得有个金刚钻,而不是追求面面俱到。否则任何一个行业里的巨头,也不会把岗位分如此细致。

而复合型运营,我认为是:除了掌握常规的亚马逊平台的运营工作思维和工作内容之外,还可以有纵向拓展的探索能力,比如除了站内CPC广告,我还研究FB、Google等互联网平台的广告投放原理;
比如除了推广、广告层面的内容,我还研究营销方面的内容,因为营销的意义更多是去占领用户的心智,而不是像广告一样,把产品推到用户眼前去看;
比如除了亚马逊平台,我还去研究其他跨境电商平台的核心打法是什么?其他平台相比于Amazon的优势条件是什么?丰富自己在跨境行业的平台认识。
再比如,数据分析层面,可以拓展接触SQL等辅助工具的应用,而不是仅仅依靠Excel。
再比如市场分析除了过去停留在运营层面的内容之外,能否再尝试做产品开发层面的市场分析,因为那所需要的信息量更加细致和庞大,所需要的角度更多,这样可能你不会只站在推广运营的角度去看待问题,而是可以结合从生产商、从消费者的角度去看待这个市场,做出更加全面的决策。 等等...
在一个领域里进行纵向拓展,我觉得这些才是一个跨境电商复合型运营者的融会贯通的体现点。
这样当跨境电商公司部门进行裂变,需要拓展其他平台、需要打通其他渠道、需要调整运营方式等等的时候,你的潜在机会才会更多。

第三方独立站平台的优缺点

优点:上线时间非常短,操作简单,免去程序开发和维护的成本,运营成本低些,模板主题丰富,功能众多,技术成熟,不需要招聘SEO优化专员,对国外其他网络平台接入好,支付多样化,很多设置可以一键式操作等等,非常适合没有专业运维人员和技术人员的小型电商外贸公司。

缺点:缺乏SEO优化自由度,完全依靠程序自身的结构和SEO参数,在同行竞争时很难在短时间内脱颖而出,存在被服务商局部限制和客户信息收集的风险,服务和功能的收费较高,支付手续费不算低,而且用久了会让公司过于依赖服务商平台,很难建立自己的品牌效应,综合运营和使用费用很有可能水涨船高等等。

第三方独立网站平台其实就是提供给商家从电商平台跳转到可以自建独立电商网站的平台,摆脱了电商平台存在的吸收模式的收费项目,但是随着商家用户越多,必然会对各项收费也会逐步提高,但是应该不会高于电商平台。

一,开源建站的优缺点

优点:开发成本低些,但还是需要技术员做运维和修改,可以快速建立独立网站,对SEO优化有自主性和优势,利于和竞争对手区分差距进行弯道超车,对建立品牌效应和用户认可度有利,省了很多服务费和使用费,支付接口已经预设,集成了很多第三方接口,常用的电商功能都有,网站的可控性和发展性更广泛,适合有点经济实力和远瞻性的中小电商外贸公司。

缺点:综合运营成本较高,需要自己维护安全,注册域名,购买服务器和数据库搭建等等,对技术员有专业性的要求,因为需要修改和微二开发。

二,自制开发建站

优点:完全自主产权开发不会受限任何方面和渠道的限制和收费,安全性和扩张性上可以及时解决,随时可以执行最新SEO优化和运营方案的需求进行二次开发和深度改良,可以从程序最底层进行SEO优化和设计,在和同行竞争时更有实力和优势,也更能稳住和打造头部流量的获取,适合中大型电商外贸公司作为长久运营。

缺点:开发制作成本高,团队各项人员的专业和技术要求高,运维成本较高,需要购买服务器和数据库和其他网络辅助产品,需要自行解决支付功能、产品功能等其他购物相关的功能。

如果跨境电商公司只是把外贸当做一个风口生意搞几年的,推荐用独立站平台,如果是打算长期发展做下去,推荐用开源建站,除非公司具备很强的团队才考虑自制开发建站。

  1. 第一,我觉得“你不满意”是一个很伪命题的事情。因为目前Top 100的Shopify的PageSpeed Insight的评分普遍都只有20分~40分左右。和大部分其它的Shopify网站是一样的。详情可以看rankly上的榜单。

  2. 追求速度极致的,只能自己写代码开发独立站,这个模式是最优解,但是需要投入的人力成本非常高昂,完全不值得。正如上述所说的,Shopify并不慢,这个已经得到了非常多网站的验证。慢的可能是你所使用的主题。如果真的决定要自己写代码的话,我个人目前仅推荐NextJs和Gatsby。Gatsby有CMS的整合,而NextJS的速度和整体性能比gatsby更快(尤其是nextjs v12)。作为一个使用过各类前端框架的人而言,我能推荐的就是上述二个,尽管我自己用得最多的是nuxt。

  3. 使用Shopify建站的,我是不推荐再使用cloudflare这类proxy增加多一层缓存层的。个人认为必要性不强,甚至可能会伤害性能。而且同时可能会导致过多301重定向的浏览器ERROR(重定向是有阈值的,然后cloudflare这类服务如果开启了proxy模式,则可能会导致这个问题)。很多Top 100的网站有使用cloudflare和cloudfront是因为他们加载了一些其它插件和其它静态文件,所以才有使用的必要性。但是对于一个全新的shopify网站,我并不认为这是必须要做的。但是Cloudflare有一个很好的功能,能够自动压缩和缓存你的css/html和js文件,这个能够极大的增加你的网站速度。但是Shopify的CDN也是会做类似的事情的,不同的在于Shopify CDN可能并没有提供主题文件css的minify压缩。

转自-牛津小马哥

很多人会通过pagespeed.web.dev(一个google的网站测速工具)来判断自己的网站是不是太慢了。

首先,需要说明的是Pagespeed insight的评分是不稳定的,你测试10次,有的时候可能是80分,有的时候可能是20分,这都是很正常的。同时,如果你是Shopify,那么你就已经会面临一定的局限性。因为Shopify本身已经尽力他们自己最大的努力去优化你的网站。说明如下:

Shopify本身已经为网站提供了加速服务

1 - 图片加速:

  1. Shopify会使用懒加载,有lazyload。
  2. 图片全部都会经过Shopify的CDN,可以看到cdn.shopify.com
  3. 图片经过不同宽度的压缩,可以看到链接上的{width}x.png,以及data-widths=[110,160...]

JS文件的加速和异步:

  1. 目前大多数Shopify的JS文件,都是通过自己的cdn的。见下图。
  2. 必要的JS文件则应该是async加载,或者是defer加载

3 - CSS文件压缩和加速

  1. 尽量避免使用inline css。但是Shopify网站的inline css一般不会有很多的。这个是属于可以忽略的问题。如果是自己写代码建站,则需要注意这一点。

  2. 这里其中一个最为影响的,也是Shopify无法干预的,则是你所使用的主题。下述例子中的主题,是Pipeline Theme / Groupthought Theme。这个主题包所生成的css文件抬头如下:可以看到“An unminified version of this CSS ...”,也就是说,目前production中的版本已经是被压缩过的版本。所以该css文件,应该不是“很大,但是仍然有优化空间”。为什么仍然有优化空间呢?因为毕竟不是每个主题的每个css文件你都会在自己的网站内用上。

如何查看哪个文件加载得慢?

  1. 你可以打开自己的网站,然后右键inspect(审查),点击Network(网络),找到你的网站加载数据。这里拿Rankly.cn举例(该网站是NextJs搭建,并非Shopify。所以速度非常快),你可以看到各类文件和请求的加载速度在1ms至209ms。你可以通过这个手段查看自己的网站,找到最影响加载速度的图片/文件,这样子你就可以基本判断出“为什么这么慢”的原因了。

  1. 这里拿Yeti(Shopify Top100榜单榜首),他的网站速度加载得非常慢。至少,在我的网络环境下是如此的。在通过上面的方式去查看的时候,我通过waterfall可以看得到,前面的250万ms前都是在加载clarity.ms,也就是说clarity ms极有可能是导致网络加载速度慢的元凶。

  1. 通过上述方式去查看网站加载速度慢是比较合理的,也是我们程序员一般会使用的方式。但是部分请求速度就是会很慢(例如从后端服务器检索产品数据)。这类请求可能会慢至1~2秒。能够提升这个速度的方式就是使用边缘计算。在Shopify独立站领域,我们不会过多探讨例如边缘计算等这类前沿加速方式。因为这个都远远超出了卖家本身的能力以及资金范围。更不用提,Shopify本身就已经为每个网站使用了边缘加速。

转自-牛津小马哥

LCP(Largest Contentful Paint) 表示的是测量感知加载速度,通常表现为首屏内容出现的时间,这是网站速度感知的最重要指标,一般小于 2.5 秒最佳。

FID(First Input Delay)表示的页面首次可交互的时间,小于 1 毫秒是最佳的。

CLS(Cumulative Layout Shift)表示页面累积布局偏移度,当页面没有加载完全时,某一部分可能会被一些延时加载的脚本给撑开,改变原有的位置。